Bug 109276 - The method Control.setCapture() is not implemented for GTK
Summary: The method Control.setCapture() is not implemented for GTK
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.7   Edit
Hardware: PC Linux-GTK
: P3 enhancement with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2005-09-12 06:40 EDT by Tibor Jonas CLA
Modified: 2019-08-27 14:35 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tibor Jonas CLA 2005-09-12 06:40:19 EDT
The body of this method contains only checkWidget() call and FIXME commentary.
Comment 1 Billy Biggs CLA 2005-09-17 00:12:44 EDT
Could follow Motif and implement it using gdk_pointer_grab(), although it seems
bug 19430 takes issue with its implementation.  Also note that grabs are scary
and you really want to avoid doing.  Maybe there's a better way to get the
functionality you need without using setCapture()?  If possible, can you give
more motivation (or a snippet)?
Comment 2 Steve Northover CLA 2005-09-22 13:37:39 EDT
We should do the same thing we do for Motif (ie. use gdk_pointer_grab() or the 
equivalent call).
Comment 3 Randy Hudson CLA 2005-09-22 14:12:50 EDT
I'm not sure there is any reason to "fixme" if the contract can't be met.

Perhaps change the API to say something like "causes the receiver to have all 
_future_ mouse events" (as in events that are not currently hanging around in 
the event queue). Or say that it has no effect on pending mouse events that 
haven't been dispatched.
Comment 4 Steve Northover CLA 2005-09-22 16:09:06 EDT
Do you know this to be a fact?
Comment 5 Randy Hudson CLA 2005-09-22 16:50:40 EDT
This seems to be the issue with bug 19430. The snippet there shows at least one 
mouse event that gets dispatched to a non-captured control after capture is 
requested. I'm guessing that this is because it was queued before mouseCapture 
happened.
Comment 6 Tibor Jonas CLA 2005-09-23 02:54:09 EDT
Back to the motivation:
1) We need a consistenet API across all platforms (I think it's enought ;-).
2) In our application we need avoid user to leave text fields with not valid
values. These values should be written back to the model after widget lose the
focus.
Comment 7 Randy Hudson CLA 2005-09-23 09:24:58 EDT
> 2) In our application we need avoid user to leave text fields with not valid
> values. These values should be written back to the model after widget lose the
> focus.

There are lots of other ways to do this without mouse capture. Look at how 
celleditors in the propertysheet work, or how wizards disable the Finish button 
and display an error in the dialog.

To do what you are suggesting would require additional hacking like adding 
Traverse listeners.
Comment 8 Tibor Jonas CLA 2005-09-23 09:56:15 EDT
(In reply to comment #7)
> There are lots of other ways to do this without mouse capture. Look at how 
> celleditors in the propertysheet work, or how wizards disable the Finish button 
> and display an error in the dialog.

There is no finish/apply button or something like this, the value (if valid)
must be written back to the model if:
1) enter is pressed (No problem with check here)
2) Control loses focus. But if the value isn't valid the requirement is to avoid
user to leave this field.
The error message as in the CellEditors is no solution for us.
> 
> To do what you are suggesting would require additional hacking like adding 
> Traverse listeners.
That's what we already did + setCapture()

Comment 9 Eric Williams CLA 2016-08-05 11:06:53 EDT
Checking the source code tells me that this is till an issue. Assigning to platform inbox for more discussion.
Comment 10 Eric Williams CLA 2019-08-27 14:35:31 EDT
This doesn't appear to be implemented on Mac either.