ListBox forcing window to front after cell edit

Targets Windows
1

I have been conversing with @Raul here on the forums via PM in Spanish using google translate (tricky but not impossible) to assist him with some ListBox issues he’s encountered. He has asked me to post this issue on his behalf to try and discover if this is a bug that needs to be filed, if anyone has encountered this problem before, if anyone has any alternative methods of working around it and to let people know a possible solution if someone looks for it in the future until/if it is fixed (if it is in fact a bug).

I have linked to a simple example project showing the problem, Window1 and WIndow3 open on the start of the app. If you move these side by side and go to edit a cell in Window1, type in some random data then press ENTER you will notice that another window opens on top (Window2) and is immediately placed behind Window1. This can be confirmed by the DebugLog shows in the app, with the following report:

Window1 Activate Window1 Listbox1 CellClick Window1 Listbox1 CellLostFocus Window1 Deactivate Window2 Activate Window2 Deactivate Window1 Activate

This is highlighting what we both think is a bug where WIndow1 is taking control back from the newly opened Window2 which occurs on the CellLostFocus event of the ListBox. This does not happen when you click the button on Window1, Window2 comes to the front with focus as expected.

I worked around the problem in Window3 by triggering a timer on Window3 when the edit was complete and opening Window4 after a short delay. As you can see this has the desired outcome, WIndow4 with focus showing above Window3 when the edit is complete.

Now I carried out a further test. I edited a cell in Window1 then instead of ending the edit with the ENTER key I simply clicked onto Window3. Window2 was opened above Window1 with correct focus on Window2. However, this is the DebugLog output from that test:

Window1 Activate Window1 Listbox1 CellClick Window1 Listbox1 CellLostFocus Window1 Deactivate ** Window2 Activate Window1 Deactivate **

A keen eye will spot that Window1 has somehow Deactivated twice (shown by **) without being Activated and the focus onto Window3 is nowhere to be seen!

Here’s the link to the project https://www.dropbox.com/s/qkbpan3w34ygy5x/ListBoxFocusGrab.xojo_binary_project?dl=0

Would you be able to test this project on your os/xojo version and post back with your findings?

Thanks in advance,

Julian & @Raul

2

Focus, on any control, is a tricky thing. Any time you find yourself wanting to affect focus from within a LostFocus event, think about using a Timer. The problem is that there is usually an implicit SetFocus that occurs within the framework some time after the LostFocus code runs. You really do need to use a Timer to allow all the framework code to complete before you do anything that affects focus, such as displaying a window.

3

Oh dear. I would have thought that CellLostFocus would have been called after everything was complete! What possible use would there be to pull focus back to the window the control is on?

4

I think what you posted is missing relevant events
IF you click to cause the lost focus you should get

 lost focus ( cause by a click on a different row )
 window2 activate (lost focus opens the window
 possibly window2 deactivate (the cell click now continues to execute and moves focus to the listbox that was clicked)
 click ( now your listbox gets the "click" event after everything else happened )

and the click is the one that caused the lostfocus to occur

trying to intercept and MOVE focus while in the middle of handling the stream of events from the USSER causing a change of focus is … perilous
and can lead to frustrations like this

5

Unfortunately, no. It happens right in the middle of everything. Trying to affect focus in a lostfocus event is a problem.

6

You would think so Norman, thats the problem, on example 1 above I dont click, I press ENTER on the keyboard and Window1 is still brought to the front when no code or mouse interaction has asked it to come to the front (especially after asking Window2 to be shown).

I have made a video to illustrate the problem in example 1.

Here is a video of the problem in example 2.

7

The listbox itself receives focus after you finish editing a cell. The cell editing actually takes place in a separate textfield control. When that finishes, the listbox gets focus again. That’s what causes window2 to lose focus and window1 to regain it.

9

Hmm you are right there, I forgot that moving focus to a control in code also gains the windows focus IF its in the same application (it doesnt grab focus if you do that when you are in a different application).

I guess it boils down to when the CellLostFocus event should fire.

10

Can anyone explain the difference between the two videos?

Mainly:

Why the 2nd video ends up with Window2 in front as hoped/intended?
Why there is a missing Window3 Activate?
Why there is an extra Window1 Deactivate or a missing Window1 Activate?