Focus issues

General
1

How do I find where keypresses are going when no control has focus? I have been using the window Keydown event successfully but suddenly it doesn’t work. This happens after I use a different window to open a file. When I return from it to my main window, focus is lost and the only way to get it back is to click somewhere on it. Then the Keydown event starts working again.

I’m using Windows 10 with latest iteration of Xojo (up to Oct): 2024 r3.

Edit update: Actually, I just discovered I lose Keydown events even when a control (like a listbox) on the window has focus IF I have double-clicked a file to open. I press the keys and nothing happens.

Edit 2: Whenever I break the program and check my main window, it ALWAYS says the Focus is Nil, even if I’ve just clicked on it. I don’t get it.

2

Did you try setting the focus for the offending window in its Activate event?

3

No. But I’m about to.

4

Does the window even have focus?

5

Every time I break it says Focus:Nil. I’ve tried breaking immediately after setting the focus to the window but I still get that. Seems like a system bug, maybe in the latest version.

6

Didn’t help.

7

Well, don’t set the focus to the window. Set it to the control in the window you want to use to catch the keystrokes.

8

Yes, I’ve tried that. The problem is I’m using the Keydown event for the window to accept keypresses from a variety of sources. If I set it to one particular control – and I’ve got lots of them on the window – it doesn’t work as expected in other areas. I guess one of my questions here is how is my window event for keydown picking up keypresses if the debugger always tells me the window in question has a Focus of Nil? Another question is: if I’m pressing keys and nothing happening, where are those keypresses going to and can I figure it out?

I place a button on the window to tell me what control presently has focus. Often it’s none … but sometimes the keypresses do what they’re supposed to, sometimes not. I’ve had this program written and running for years … we use it at our church for song lyrices displays, etc. The problem seems new.

9

The Window can have a Keydown event as well as a control. If no control has focus then Key events go there. If a control has a Keydown event, and it has focus, then it goes to that first. If you return False from a control Keydown then the Window.Keydown should fire next.

It can be helpful if you have some key events that you want handled by a control and others that are handled by the Widow all the time. Which sounds like what you may be looking for.

1 Like
10

Thanks for that clear explanation. I didn’t know the keydown hierarchy. This is very helpful.

11

Focus is a reference to which control has focus. If no control has focus, it will be Nil.

Note that some controls consume key presses directly, with no keydown events. Same with menu shortcut keys.

12

I’ve run into this problem before. My solution has been to write two methods (one for key up, one for down) to handle all the keystrokes, and call that method from the KeyDown and KeyUp events of every control, and the window itself. For me, that solves the problem. If you need to know which control sends the messages, you can add a variant to the methods to pass that reference.

2 Likes
13

a. Search if you set the Focus to Nil
if so, comment the line, then test.

b. Check if you have a Control outside of the Window (design mode)

c. Type “hello”, select-all, copy: doyou have hello in the clipboard ?

1 Like
15

Good suggestions, esp. #3. This way I’ll know if the keystrokes are being recorded anywhere. Will try. Thx.

16

This is a good suggestion but may be quite tedious for me at this point since I have many controls on the window. But I have in the past noted that KeyUp helps sort out some difficulties so I will look into this.

17

Ah! So now I understand the window property focus. I thought it flagged whether the window itself had focus which, on second thought may have been pointless. Anyway, that clears up one mystery for me.

18

I don’t know if this will help, but I have had a similar program issue on the Mac. What I found is that things happen too quickly when returning control to the calling window. I used MonkeyBread’s [DelayMBS] command before issuing the [Return] command to the main window. It seems to allow the program to complete fully what it’s doing so you get a clean break to go back to the calling window. I have used a delay as small as 0.01 sec to as much as 0.5 sec in various places, on a “trial and error” basis to see how fast I can transfer control back.

Christian Schmitz in his MonkeyBread products states

ActivateWindowMBS

MBS Util Plugin, Plugin Version: 21.5, Platforms: macOS, Windows, Targets: Desktop only.
Function: Activates the window.
Notes: This function does more than just show. if the window has been minimized, it will restore it. Alsothe window is moved to front and made the current window for keyboard input.

Sadly windows limits which windows can go to front, so some windows may not come to front unless they are clicked on.

That was the problem I was having, and putting in a time delay before returning to the calling ‘main’ window solved the issue.

1 Like