Zugg Software :: View topic - [3.10 Pro] In some circumstances focus not given to PE when making a delete

Posted: Tue Jul 28, 2009 4:58 am

Summary: In certain circumstances you can be in the PE and select text intending to delete it. Hit delete and it tries to delete rooms from your map.

Procedure:

1) Create a new session and enter it off-line
2) Open the map window with the "Map" button
3) Put the map in 'Edit Mode' with the pencil button
4) Create a room on the map
5) Select that room and directly after that open up the Package Editor (** Important to make sure you don't click on anything else in between **). Focus should remain on the map with the room selected when you hit the button to open the Package Editor.
6) Create a new class.
7) Select that class and hit the 'delete' key. (** Important to use the 'delete' key. Using the package editor menu to delete it operates differently **).
8) You will now get a pop-up box asking if you wish to delete the newly created room in your map. This is incorrect. It should delete what you have selected in the Package Editor and not what you have selected in your map window.

Posted: Tue Jul 28, 2009 4:49 pm

Added to bug list. Sounds like the keyboard focus is still stuck with the map window instead of the settings editor. In step (7), I'm assuming you clicked on the class name in the Tree View on the left?

Posted: Tue Jul 28, 2009 7:20 pm

If I recall correctly, I believe you are correct. I think I can click on things in the PE once it is open but the delete key still tries to delete in the map.

Posted: Tue Jul 28, 2009 8:15 pm

This is a really weird one. Do you know how long it has been doing this? Is this new to 3.10?

I can reproduce the problem. Looking at the code, it almost looks like a bug in the Windows API GetForegroundWindow routine. The Delphi "Screen.ActiveForm" points to the Settings Editor, and the Delphi "Screen.ActiveControl" points to the TreeView in the settings editor. But the Windows GetForegroundWindow (which is what Windows uses for keyboard focus) is pointing to some other window handle and I can't figure out what component that is. This is very odd. I have no idea why GetForegroundWindow isn't returning the handle of the proper window that has the keyboard focus.

Posted: Tue Jul 28, 2009 8:34 pm

OK, it's not the GetForegroundWindow after all...it wasn't getting to that point in the code where I called it. I had thought it was the toolbar system grabbing the DEL key, but it turns out to be the Delphi ActionList component that is grabbing it. Because the mapper is docked to the main application window, Delphi is looking at any action list within each component looking for a matching "shortcut key" assignment. Delphi apparently isn't designed to handle more than one ActionList component on the same form (with docking forms).

Not sure why this didn't get reported in the past since it seems like this should have been happening for years with a docked mapper window. It's going to be a pain to fix this since I'm somehow going to need to block Delphi's access to other Action Lists docked within the main application window. What a pain.

Posted: Tue Jul 28, 2009 9:12 pm

The ActionList component in Delphi has an event hook that I can use to prevent an action from firing if it's in a window (or docked to a window) that doesn't currently have focus.

Seems like an easy idea. Pass the form containing the action list and look at the current Screen.ActiveControl. Determine if the active control is within the form containing the action list. Do this by recursing up the ActiveControl.Parent pointers to see if any of the parents match the form containing the action list.

Yeah, seems easy. Except for the ^&$#*&# Developer Express Toolbar controls. Guess what? A control (like a button) docked to a toolbar has the toolbar as it's parent, but the toolbar itself doesn't have any parent!!! They have totally violated the entire architecture of Delphi! EVERY CONTROL is supposed to have a parent, which contains the control, until you get to the top level form, which has a NIL parent. So basically, they are treating each toolbar as a floating window, EVEN WHEN ITS NOT FLOATING!!!

So if the active control is on a toolbar, there doesn't seem to be any way for me to determine the real parent of that control. This is very annoying. Still looking for some other solution. I really hate debugging 3rd party code!!!

Edited: OK, not quite so bad. It only happens when the currently active control is docked within a DevExpress "container" object within a toolbar...like the command line field that is docked to the command line toolbar. Which, btw, is the control that most commonly has the focus in CMUD.

Posted: Tue Jul 28, 2009 9:44 pm

Geez, this does deeper and deeper!

So I finally got a reliable method to determine if the action list is within the focused form. But preventing the action list from executing the action also prevents any further keyboard messages from being sent!!! This means that when I tell it not to process the Delete action in the Mapper action list (because the settings editor has the focus), Delphi also prevents the OnKeyPress event from being sent to the Settings Editor window itself! So now pressing the DEL key in the Settings editor does nothing!

How the heck am I supposed to fix this?

Posted: Tue Jul 28, 2009 10:03 pm

Just confirmed that this problem DIDN'T HAPPEN in v3.08. So something new has caused this, and I have no idea what. As far as I know I haven't changed anything related to how shortcut keys are handled in CMUD. I'm completely clueless now.

Posted: Tue Jul 28, 2009 10:37 pm

Just to muddy the waters a bit more, this has happened in previous versions of CMud. I recall having it happen to me before, but I don't recall the version where it happened.

Posted: Tue Jul 28, 2009 10:42 pm

There was an old bug with this, which was then fixed. It broke again in v3.09 as far as I can tell.

I found the cause of this specific change. It has to do with how Delphi handles the "ownership" of docked forms. In v3.08 and some earlier versions (when I fixed the bug the first time), I added a property to the docking system to set the ownership of the pre-created docked windows to nil so that they wouldn't be owned by the main application window. The main application window sends keypresses to any ActionList within a component owned by the main window.

In 3.09 when I changed how the mapper window was docked, I changed how the docked panel was created, and forgot to set this owner field to nil. Once I did this, I have fixed the bug in 3.10.

However, while looking into this, I uncovered another related bug. If you select a room in the mapper and then press Ctrl-F, the Find dialog of the main session window opens instead of the Find dialog in the mapper window. But this bug has existed for a long time and even fails in the 2.37 version. The problem is that the map window never really takes the keyboard focus from the main command line when it is docked. This is also what prevents the keyboard map creation from working.

So, I've fixed the new problem reported here that started happening in v3.09, but be aware that other older and harder to fix issues regarding keyboard shortcuts are still present in 3.10. I'm not going to fix that today...it's a complex issue (as noted above) and that's more time than I have today when doing quick-fixes just to get a stable beta released before 3.08 expires.

Posted: Tue Jul 28, 2009 11:12 pm

I'm glad you found it! Thanks for looking at it.