We inherited a control from UltraTextEditor overriding some of the OnXxx... methods. Several methods are beeing called in a very strange way:
OnEnter is beeing called recursive
OnLostFocus is called while OnGotFocus is active
OnGotFocus is only called, when the control looses focus, not when it gets the focus
Entering the control via mouse click triggers OnLostFocus
Moving the mouse over the control triggers OnMouseEnter immediately followed by OnMouseLeave
Moving the mouse away from the control triggers OnMouseEnter followed by OnMouseLeave
We want to offer the user an option to control selection behaviour if the control is entered with the possibility to distinguish if the control receives the focus by mouse click or through use of the Tab key. This does not seem to be possible the way OnXxx... methods are beeing called.
Below the sequence of "events" for the different situations:
OnEnter edt01 - StartOnEnter edt01 - Start (recursive call)OnEnter edt01 - End (recursive call)OnEnter edt01 - End
OnGotFocus edt01 - StartOnLostFocus edt01 - Start (nested call)OnLostFocus edt01 - EndOnGotFocus edt01 - EndOnGotFocus edt01 - StartOnGotFocus edt01 - EndOnLeave edt01 - StartOnLeave edt01 - EndOnLostFocus edt01 - StartOnLostFocus edt01 - End
OnMouseEnter edt01 - StartOnMouseEnter edt01 - EndOnMouseDown edt01 - StartOnEnter edt01 - Start (nested call)OnLostFocus edt01 - Start (nested call)OnLostFocus edt01 - EndOnEnter edt01 - Start (recursive call)OnEnter edt01 - End (recursive call)OnEnter edt01 - EndOnMouseDown edt01 – End
The mouse is still over the control while the following override is beeing calledOnMouseLeave edt01 - StartOnMouseLeave edt01 - End
OnMouseEnter edt01 - StartOnMouseEnter edt01 - EndOnMouseLeave edt01 - StartOnMouseLeave edt01 - End
OnLeave edt01 - StartOnLeave edt01 - End
Could there be anything we are doing wrong to cause this strange sequence of "events"?
RegardsBurkhard Exner
Burkhard,
These seemingly strange order of events are the result of the way that the UltraTextEditor was designed, in that when it is put into edit mode, a .NET TextBox is positioned within the bounds of the UltraTextEditor to handle the editing portion; when you exit edit mode, this control is removed. You can see when this occurs by listening to the ControlAdded and ControlRemoved events. There is also the following KB article:
FAQ:Mouse events such as MouseDown, MouseUp, and DoubleClick do not fire for an UltraWinEditor it is in edit mode.
Because of the way this is implemented, you'll see the various Enter/Leave/etc events fire for the UltraTextEditor when the TextBox is positioned, since the TextBox itself now has focus, and similar when you exit edit mode and the TextBox loses focus to be given to the UltraTextEditor.
-Matt
Matt.
Thank you for the information, it will allow us to achieve our goals.
In case you are interested I logged the events for the embedded control and still find them a bit confusing:
Enter is triggered twice
Leaving the control via TAB leaves, enters and leaves the control
OnEmbeddedEnterOnEmbeddedGotFocusOnEmbeddedEnter
OnEmbeddedLostFocusOnEmbeddedLeaveOnEmbeddedEnterOnEmbeddedGotFocusOnEmbeddedLostFocusOnEmbeddedLeave
OnEmbeddedEnterOnEmbeddedGotFocusOnEmbeddedMouseDownOnEmbeddedEnterOnEmbeddedMouseEnterOnEmbeddedClickOnEmbeddedMouseClick
OnEmbeddedMouseLeave
OnEmbeddedMouseEnter
OnEmbeddedLostFocusOnEmbeddedLeave
As a user of UltraTextEditor I think, the control should completely hide the fact that it works with an embedded TextBox and call OnXxx... methods and send events in a manner UltraNumericEditor and UltraMaskedEdit do. The current situation requires knowledge of UltraTextEditors implementation that might change in the future.
ThanksBurkhard