Community
Participate
Working Groups
When inside our modal event loop for drag and drop, we'd like to change the effect of a drop when the user presses a modifier key (like ctrl, shift, etc.) Our drag and drop event loop uses the SWT Tracker class. To make this happen, we need two things: 1. Ability to get the current state of all modifier keys. 2. The ability to determine when the key state changes (even if the user isn't moving the tracker, we need to know that the key state changed so that we can change the drop cursor).
Steve: this is one of the Tracker things we were discussing with Michael.
I forget exactly what we were going to do about this. SSQ to consult with SN and GG.
Are interested only on modifier keys (SHIFT, CTRL, etc) or any key?
To fix bug 74609, we only need modifier keys... but don't let me stop you from solving it for any key. :-)
Fixed > 20040929. It is possible to add key listener to Tracker now.
This is still only half-fixed. We now have access to the state changes, but not the ability to query for the current state of modifier keys. If the user presses and holds ctrl before starting the drag, we have no way of knowing that control is being held down (since we don't have a tracker at the time of the keydown event). This is similar to bug 71538, however we only need to know the state of modifier keys (control, shift, alt) to fix our bug.
Can you query the initial key and mouse state from the event stateMask? It should be set in mouse, key and selection events.
That is a much better solution than the key listener on its own, but it will only work once the first event is received from the tracker. This means that at the very start of the drag loop (until the mouse moves 1 pixel), we will be showing the wrong drop target.
Steve: are you saying that the stateMask now contains valid information? If so, I can proceed with bug 74609.
Use the inital state from the event. It is set in mouse and keyboard and menu selection events. Hopefully, that is enough for you to determine the initial state when you launch the Tracker. SSQ will advise while I am gone.
That workaround may work, but we can't use it. Our drags are started programatically. The SWT event that triggered the start of the drag (if any) may be on the other side of an API boundary from the code that creates the Tracker.
That's a problem because the key state may have changed between the time of the event and the time your API is called. Are you stuck on this?
Yes, this is still blocking bug 74609.
I just tested... the stateMask for the Tracker's SWT.Move event is not being filled in, either.
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. If you have further information on the current state of the bug, please add it. 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.
