Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-swt-dev] missing package

HI,
 
Apparently my application Eclipse crashed. I reinstalled it, but now I have problems getting the package org.eclipse.swt.widgets, and I do have the plugins C:\apps\eclipse\plugins\org.eclipse.swt.win32_2.0.2
and C:\apps\eclipse\plugins\org.eclipse.swt_2.0.2
The classes are in C:\apps\eclipse\plugins\org.eclipse.swt.win32_2.0.2\ws\win32\swt.jar
 
I can not see why is it giving me an error.
 
Any clue what is wrong?
 
Thanks,
Aleksandra
 
-----Original Message-----
From: Steve Northover [mailto:Steve_Northover@xxxxxxxxxx]
Sent: Tuesday, June 24, 2003 12:21 PM
To: platform-swt-dev@xxxxxxxxxxx
Cc: platform-swt-dev@xxxxxxxxxxx; platform-swt-dev-admin@xxxxxxxxxxx
Subject: Re: [platform-swt-dev] Support for scrollbar location


You can always file a bug report but the priority will probably be very low as this is an uncommon feature that would need to be implemented, debugged and maintained on every platform.



"Olivier Modica" <omodica@xxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

06/24/2003 11:53 AM
Please respond to platform-swt-dev

       
        To:        <platform-swt-dev@xxxxxxxxxxx>
        cc:        
        Subject:        [platform-swt-dev] Support for scrollbar location



Hi,

This a follow-up for the thread "Allow TVS_NOSCROLL to be set for a
Tree".
Basically what I needed to do is control the scrollbar location for a
LTR
or RTL widget.

After a discussion with Steve Northover, one solution is to wrap a
widget
within a composite that controls the scrollbars and reset the widget
bounds
upon resize events. This does work but has several side effects and
require
much of the scrolling behaviors to be re-implemented.
Since Windows will in any case paint the scrollbar before any listener
(ResizeListener, PaintListener) is invoked, this does cause a visual
defect
directly linked to the computer performance and load. This isn't
acceptable
im my case.

This is on Windows:
The only acceptable way from a visual standpoint I found was to hack
the createWindowExt method (effectively releasing and recreating a
handle in a subclass) and use the WS_EX_LEFTSCROLLBAR style when
creating
the widget handle.

Using WS_EX_LEFTSCROLLBAR and WS_EX_RIGHTSCROLLBAR is effectively the
only way to control the scrollbar location. This also does work nicely
with SWT_RIGHT_TO_LEFT (WS_EX_LAYOUTRTL). My testing didn't reveal any
issue when using the extra bit, and the widget (Tree for example) is
fully functional. From the MS documents, these bits are available across
all Windows versions.

Although this is probably not a very common use (however Windows and
others provide it so it's not absolutely specific), the fact that there
is no way around hacking the createWindowExt method indicates a strong
limitation here. It also appears this is part of the BIDI support, and
could be leveraged by others.
Although I cannot say for sure, the scrollbar location support seems
to be provided by most target platforms.

If implementing an additional style to control the scrollbar location
does make sense for you in SWT, should I file a bug at this and how
could I have a sense of seeing this implemented in a foreseeable future.

Thanks in advance,
Olivier Modica.

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev



Back to the top