Community
Participate
Working Groups
I20091006-0800. FUP of 289752. In order to change the direction for all widgets inside the editor we need to have a listener for direction changes and it should be possible to veto the direction change in the event.
Do you need the event when the direction changes ? Can you just use VerifyKeyListener to stop shift control ? My only problem here is to add an orientation change event to org.eclipse.swt.custom and later on need the same event in org.eclipse.swt.widgets (for Text/Combo).
>Do you need the event when the direction changes ? I think so, as for normal editors which don't hard-code LTR it makes sense to offer the functionality and hence we need a listener.
> Do you need the event when the direction changes ? Yes (but only at the point where there's no way back other than our veto, and we can be sure it's really changed). > Can you just use VerifyKeyListener to stop shift control ? Not really, since StyledText#handleKeyDown(Event) does not copy keyLocation, and VerifyKeyListener#verifyKey(VerifyEvent) also doesn't mention the new field. When I fix that and move the orientation switching code into "if (verifyEvent.doit) { .. }", then "event.doit= false;" could work for vetoing. But it's not nice, since it adds a platform dependency, and we would need more hacks to find out whether the orientation really did change in the KeyUp event in the end. And it would probably be an issue for other key listeners in text editors (like hyperlinking modifiers). > My only problem here is to add an orientation change event to > org.eclipse.swt.custom and later on need the same event in > org.eclipse.swt.widgets (for Text/Combo). A new event on all 3 would definitely be nice, especially if it also helps solving bug 165089.
Okay, I can put the new event type up in SWT and have it working for Text/Combo/StyledText - only one windows with bidi enabled. I verify it can be used to fix bug 165089. The only problem is that Text and Combo can have the orientation changed by the native context menu, in which case the event is not send. Spinner on windows also responds to Ctrl+(L R)Shift SSQ, should we go ahead with this ?
Question: should the event be send when the orientation is changed programatically (via StyledText#setOrientation) ? Keep in mind, event.doit=false stops the operation.
> should the event be send when the orientation is changed programatically? I'd say no, that's a "normal" event as described in http://www.eclipse.org/swt/faq.php#noeventfire
(In reply to comment #3) > Not really, since StyledText#handleKeyDown(Event) does not copy keyLocation, > and VerifyKeyListener#verifyKey(VerifyEvent) also doesn't mention the new > field. We should fix this. I beleive CCombo also have the problem.
(In reply to comment #7) > (In reply to comment #3) > > Not really, since StyledText#handleKeyDown(Event) does not copy keyLocation, > > and VerifyKeyListener#verifyKey(VerifyEvent) also doesn't mention the new > > field. > We should fix this. I beleive CCombo also have the problem. Fix VerifyKey for StyledText, and all events for CCombo too.
Fixed in HEAD > 20091016 See SWT.OrientationChange The event is sent for Text, Combo, StyledText. The event is sent before the change, so the application has the chance to set doit to false to stop the change from happening. The event is only send when the change is caused by keyboard shortcut. Orientation can still be changed programatically -without any event being sent- on Text, Combo, and StyledText (see setOrientation()). For Text, Combo the orietation can also be changed via the native context menu (no event sent either).
