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
I've ran into a number of issues with the "Ultra" controls which turn out to be caused by the underlying base control(s) that the Ultra control is built on top of. Personally, I'd MUCH rather see Infragistics build their OWN controls rather than just adding functionality to a base MS control. I mistakenly BELIEVED that's what I was getting when I purchased the NetAdvantage suite. I'm not very pleased to find that that is not the case...
How many of the "issues" would simply go away if Infragistics was using home built controls? How many could be FIXED to match what Infragistics customers want if they weren't based on MS controls? I realize they have to be .net compatible, but they don't have to use the MS controls as their base...
Burkhard,
I could have sworn I originally included the base call in my test code, so I must have accidentally removed it when copy/pasting it. I guess I'm on a roll with flagrant oversights with this thread :-) You should definitely always be calling the base on any of these overrides. The flag simply lets you know if you're within the recursive call or not, but should otherwise not be changing any of the default behavior.
-Matt
Matt.
Thank you.
I already did that, but in comparison to your code I called base.OnEnter in the recursive call as well:
protected override void OnEnter (EventArgs e) { if (boOnEnterActiveC) { base.OnEnter (e); return; } boOnEnterActiveC = true; try { base.OnEnter (e); // Doing my stuff } finally { boOnEnterActiveC = false; } }
May this cause problems?
Burkhard
As an additional note, if you used my code above, you might want to move the block with "if(this.isInOnEnter)" outside of the try/finally block since that will always set the flag back to false, even if you're wihtin the recursive call.
Thank you for the background information. We got our derived control up and running. I hope Infragistics and Microsoft are working hard to never change the sequence of OnXxx-routines called :-).
Burkhard.