Why is my onlostfocus event handler being invoked…

[Jim Locker]

…when my combo box gets focus? I give it focus programmatically, and the onlostfocus event is instantly called. This is messing things up badly.

[Jim Locker]

Some more information.

When I tab into a wxformcombo, the onlostfocus event handler is invoked.
If I enter the wxformcombo using the mouse and clicking into it, the
onlostfocus event handler is NOT invoked until the control loses focus 9as
it should be).

[Michael]

Jim wrote:
> Some more information.
>
> When I tab into a wxformcombo, the onlostfocus event handler is
> invoked. If I enter the wxformcombo using the mouse and clicking into
> it, the onlostfocus event handler is NOT invoked until the control
> loses focus 9as it should be).

I will have to investigate this. I am not familiar with any situation
where this would normally be happening. The rule is that generally,
programmer-generated events should not cause events to fire, only
user-originated events should make the events fire.

If you have a small reproducible, that would help greatly.

Ciao, Neil

[Jim Locker]

I will see if I can construct one.

[Jim Locker]

I just sent you a test case that does it.

[Michael]

Jim wrote:
> I just sent you a test case that does it.
>

Hi Jim,

I checked this, and you are right, it is happening. I discovered that if
you change the comobo to a droplist, it doesn't happen. I suspect that
the problem is that since it is a dropedit, focus is hitting the combo
part, then ending up in the edit part (which is really a separate
control), causing the onlostfocus to fire. I will see if I can get this
fixed, but as a workaround, if viable, switch to a droplist version.

Ciao, Neil

[Jim Locker]

I have dropedit for a reason. Can't switch to a droplist.

I put a toggle in the ongotfocus routine, toggling a reference variable.
If the toggle is set, the onlostfocus routine does nothing but clear the
toggle. This prevents the infinite loop, and certainly prevents the
routine from doing anything else when invoked on the entry to the combo
box.

It is a kludgy workaround, but it lets me keep moving forward.

[Jim Locker]

This is a huge problem for me. I have a lot of these dropedits in my
forms (as well as some droplists) and I can't change my dropedits to
droplists.

For the moment I am patching with a toggle, but since the behavior is
different between the keyboard and the mouse, the result is that I cannot
make these things behave in a consistent fashion, and it is very
noticeable.

I can patch while I develop, but I can't deploy this way. At that point,
this will be a show stopper.

[Jim Locker]

I have found a patch that appears workable.

I move the onlostfocus event to onselchange.

Upon entry to the function, the first thing I do is test to see if me.text
== me.gettext(). If it does, do nothing.

If they don't match, a selection has been made so process it. At the end
of processing it, if there have been no errors, execute this line:
me.settext(me.gettext()) and the routine won't execute successfully again
until another change is made.

Result is that the routine executes once-only (which is what I want
anyway).

[Jim Locker]

Well…not as workable as I thought.

It keeps the control from going crazy, but keyboard input is being ignored
altogether. *sigh*

[Michael]

Jim wrote:
> Well…not as workable as I thought.
>
> It keeps the control from going crazy, but keyboard input is being
> ignored altogether. *sigh*
>

I have upgraded this one and it is being looked at. It is reproducible
here, so I hope for some proper resolution. Don't keep breaking your
head on it, for now.

Ciao, Neil

[Jim Locker]

Well, I'm glad to hear that.

I have a LOT of these edit combo boxes on my forms, and they are rather
central to the functionality of the entire system – to the point where I
literally cannot avoid them if I want to continue this translation effort.
So, even if they are not working right, I have to patch things enough to
get them working somehow so that I can execute those code branches. If I
can't execute those branches, nothing at all will work.

Presently, that is what I am doing. I can execute the branches that need
to be executed; I just have to deal with the funky functionality that is
coming with the broken control. In-house, I can live with it for now. I
just can't deploy this.

For reference, I am now about 7,000 lines into a 70,000 line conversion
effort. Given the changes in architecture that Simpol permits, I think I
am closer to 15% done than to 10%, but this give an idea of how far I have
to go.

[Author]

Posts