Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsRedirecting Scroll Wheel Events
https://www.eclipse.org/forums/index.php/mv/msg/163430/517258/#msg_517258
I'd like to have the mouse wheel events captured by these Text widgets to be processed by the parent ScrolledComposite to allow a more fluid user experience. Thanks for any help you can provide.]]>Terran Gilman2010-02-26T17:17:26-00:00Re: Redirecting Scroll Wheel Events
https://www.eclipse.org/forums/index.php/mv/msg/163430/517637/#msg_517637
I thought that re-posting the event to the ScrolledComposite
(Display.post()) would do this, but this isn't working for me (at least on
Windows 2000). A simpler approach that will handle this case specifically
since the widget underneath is a ScrolledComposite is to add a Listener like
the one below to your Text controls.
t.addListener(SWT.MouseWheel, new Listener() {
public void handleEvent(Event event) {
Point origin = sc.getOrigin();
origin.y -= event.count;
sc.setOrigin(origin);
}
});
Grant
"Trip Gilman" <trip@openmethods.com> wrote in message
news:hm8vn8$hok$1@build.eclipse.org...
> Is there a way to intercept scroll wheel events from either a Text widget
or ScrolledComposite and redirect the events to their parent? I have a
ScrolledComposite that contains several Text widgets. The text widgets are
being resized vertically automatically as the contents change.
>
> I'd like to have the mouse wheel events captured by these Text widgets to
be processed by the parent ScrolledComposite to allow a more fluid user
experience. Thanks for any help you can provide.]]>Grant Gayed2010-03-01T15:05:06-00:00Re: Redirecting Scroll Wheel Events
https://www.eclipse.org/forums/index.php/mv/msg/163430/517686/#msg_517686
I implemented your example and it works well except for a couple of things. First, there appears to be an invisible 1-2 pixel dead zone (just outside the visible border lines) in which events don't seem to be generated.
The second may be related to my development platform of Mac OSX. The text area has the H_SCROLL style to allow horizontal growth of text with wrapping turned off to preserve the visual formatting if any. On Mac, when the text is not long enough to trigger the scroll bar, the space is still reserved for the bar anyways. This area appears to be another dead zone for events. I attempted to add the listener to the bar directly but still don't see the events in that case.
Thanks]]>Terran Gilman2010-03-01T17:28:26-00:00Re: Redirecting Scroll Wheel Events
https://www.eclipse.org/forums/index.php/mv/msg/163430/517970/#msg_517970
physical areas that belong to the text widget but do not trigger events. My
initial idea of post()ing the received events to the parent
ScrolledComposite would have the same problems since it would also rely on
receiving the events. However I think that this approach is the only one to
do what you want since events in swt do not bubble automatically.
I notice on win32 that MouseWheeling over a Table's disabled scrollbar does
send these events, but on gtk they're not set. I'm not sure which behaviour
is correct, but regardless, it currently can't be depended upon. I've
logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=304372 for the
inconsistency, but in the meantime, I don't think there's a way to handle
these cases.
Grant
"Trip Gilman" <trip@openmethods.com> wrote in message
news:hmgtg6$sq4$1@build.eclipse.org...
> Hi Grant,
>
> I implemented your example and it works well except for a couple of
things. First, there appears to be an invisible 1-2 pixel dead zone (just
outside the visible border lines) in which events don't seem to be
generated.
>
> The second may be related to my development platform of Mac OSX. The text
area has the H_SCROLL style to allow horizontal growth of text with wrapping
turned off to preserve the visual formatting if any. On Mac, when the text
is not long enough to trigger the scroll bar, the space is still reserved
for the bar anyways. This area appears to be another dead zone for events.
I attempted to add the listener to the bar directly but still don't see the
events in that case.
>
> Thanks]]>Grant Gayed2010-03-02T15:51:46-00:00Re: Redirecting Scroll Wheel Events
https://www.eclipse.org/forums/index.php/mv/msg/163430/517977/#msg_517977
Thanks for the reply. I completely understand the difficulties of supporting multiple underlying systems. We encounter similar inconsistencies developing the voice tools project. The initial suggestion works pretty well. The scrolling isn't as smooth as i'd like, but it's serviceable. Again, thanks for the help.]]>Terran Gilman2010-03-02T16:15:59-00:00SWT Swing integration respective batik (SVG rendering library)
https://www.eclipse.org/forums/index.php/mv/msg/163430/531350/#msg_531350
Originally posted by: micha.on.the.road.web.de
This is a multi-part message in MIME format.
--------------040806040309010600050001
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I have quite some trouble getting batik (SVG rendering library)
well-running in an embedded SWT composite.
Using Direct3D or openGL (vm argument -Dsun.java2d.opengl=true) as
rendering, different problems arise, from cheesy doubled background
(D3D) to vertical shaking while resizing (openGL). The worst is that
rendering frequently gets stucked. Especially resizing causes this
trouble, in Swing everything works fine with batik.
Anybody has an idea how to improve SWT_AWT integration for this purpose
or for resizing in general?
I attached a code Snippet,
System.setProperty("sun.awt.noerasebackground", "true"),
SWT.NO_REDRAW_RESIZE, SWT.NO_BACKGROUND are not connected to the problem.
SVGGraphics2D svgGraphics = new SVGGraphics2D(svgDocument);
// fill the SVG Document with the Defaults
Element root = svgGraphics
.getRoot(svgDocument.getDocumentElement());
@Override
public void dispose() {
// should be disposed by the AWT thread to avoid deadlocks
EventQueue.invokeLater(new Runnable() {
public void run() {
svgCanvas.dispose();
frame.dispose();
}
});
super.dispose();
}