Bug 109101 - [Widgets] Display.post doesn't seem to handle 'keystate' on mouse events
Summary: [Widgets] Display.post doesn't seem to handle 'keystate' on mouse events
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact: Felipe Heidrich CLA
URL:
Whiteboard: stalebug
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2005-09-08 16:46 EDT by Eric Moffatt CLA
Modified: 2020-06-18 13:49 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Moffatt CLA 2005-09-08 16:46:13 EDT
I'm currently trying to create some automated tests for my Drag and Drop 
extension feature but I'm running into problems when attempting to do my 'copy' 
(i.e. CTRL down while drag) tests. I set the keystate as follows:

		event.stateMask = ctrlDown ? SWT.CTRL : 0;

where 'ctrlDown' is a boolean which is true if I want to fake a ctrl-drag. This 
keystate doesn't seem to make it back into my widget (it always seems to end up 
with '0' for posted events).
Comment 1 Steve Northover CLA 2005-09-08 20:02:11 EDT
Did you try posting a key event to simulate a control key pressed (rather than 
setting the mouse flags)?  This is what the user would do.  Please reopen if 
this doesn't WORKFORYOU.
Comment 2 Steve Northover CLA 2005-09-08 20:02:32 EDT
WPNMTFIX
Comment 3 Eric Moffatt CLA 2005-09-09 09:42:45 EDT
Steve, I've done both...if I'm trying to fake a ctrl-drag then I place the 
mouse events between two calls to (my clone of) the 
AutomatonUtil.performKeyCode method; one for key down and one for key up...

---------
if (ctrlDown)
   performKeyCodeEvent(srcControl.getDisplay(), SWT.KeyDown, SWT.CTRL);
---------

I took a look at the Display.post impl and don't see any place where the 
Event.stateMask is handled. In fact, I don't even see the (x,y) coords being 
placed into the message unless the event is SWT.MouseMove...this might explain 
why I have to make 'setCursorLocation' calls before posting (which I can live 
with so didn't mention). 

The current implementation of the mouse handling (while it does match the 
javadocs) is a fair ways from being capable of simulating a user's actions 
(which is its stated goal). By preference I'd have the code to pass on as much 
of the 'event' context as possible in the posted message. At minimum I need 
the 'keyState' or I have to drop the whole automation exercise...(and I'm 
highly in favor of automated testing...;-).



Comment 4 Felipe Heidrich CLA 2009-08-19 12:27:44 EDT
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
Comment 5 Leo Ufimtsev CLA 2017-08-03 12:33:10 EDT
This is a one-off bulk update. (The last one in the triage migration).

Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process:
https://wiki.eclipse.org/SWT/Devel/Triage

See Bug 518478 for details.

Tag for notification/mail filters:
@TriageBulkUpdate
Comment 6 Eclipse Genie CLA 2020-06-18 13:49:48 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.