1.5.1 Bug - with keyboard not responding
by Steve Lamperti · in Torque Game Engine · 04/19/2007 (11:05 am) · 6 replies
Found an interesting bug, that effects my project, and I reproduced it in the 1.5.1 FPS starter.
If you hit F11 to open the editor, select the world inspector, then select something from the
tree so that its information shows up in the inspector pane, and then hit F11 again to close the editor, the keyboard input is locked up.
What happens is that the guiTreeview is set up as the first responder, and when the editor is left it's not being cleaned up, so it's still the first responder. Because it recognizes that it is not awake, it rejects all keyboard input, so the movement keys, and even the escape key do not function any more.
I am trying to come up with a clean fix. I will post here if I have one.
If you hit F11 to open the editor, select the world inspector, then select something from the
tree so that its information shows up in the inspector pane, and then hit F11 again to close the editor, the keyboard input is locked up.
What happens is that the guiTreeview is set up as the first responder, and when the editor is left it's not being cleaned up, so it's still the first responder. Because it recognizes that it is not awake, it rejects all keyboard input, so the movement keys, and even the escape key do not function any more.
I am trying to come up with a clean fix. I will post here if I have one.
#2
What I determined is that if you open the editor, you should be able to toggle F3/F4 and other binds. However, if you select something on the TreeViewCtrl, you will no longer be able to use the binds until you either select an object from the editor window or right-click in the editor window. 1.3 does not behave this way, but 1.4 does.
I've not looked into this yet, but I wonder if the problem is actually somewhere inside the TreeViewCtrl itself. More to come...
05/02/2007 (2:15 pm)
I reproduced your bug in 1.5.1, but I've not tested your fix in it (my engine is too different to test apples to apples). However, my guys are complaining about random loss of control, and it seems to stem (must be a fruit obession) from the same source.What I determined is that if you open the editor, you should be able to toggle F3/F4 and other binds. However, if you select something on the TreeViewCtrl, you will no longer be able to use the binds until you either select an object from the editor window or right-click in the editor window. 1.3 does not behave this way, but 1.4 does.
I've not looked into this yet, but I wonder if the problem is actually somewhere inside the TreeViewCtrl itself. More to come...
#3
As I mentioned in my post, the problem was that the tree view was still thinking it was the responder to the commands even when it should not be any longer. My fix is working fine in my project, and this part of the code is still pretty generic.
05/02/2007 (2:26 pm)
@James,As I mentioned in my post, the problem was that the tree view was still thinking it was the responder to the commands even when it should not be any longer. My fix is working fine in my project, and this part of the code is still pretty generic.
#4
Yes, I understand your issue. My point was that if the control was eating some events, who's to say it wasn't cleaning up after itself somewhere else?
Of course that someone could very well be someone like you who's actually looked at the code...
I just find it odd that it is only the TreeViewCtrl that is causing problems for me (I have four editors based upon the WorldEditor, but the TreeViewCtrl is in only one), which leads me to believe that some or all of the problems are here, waiting to be discovered.
05/02/2007 (2:41 pm)
@Steve,Yes, I understand your issue. My point was that if the control was eating some events, who's to say it wasn't cleaning up after itself somewhere else?
Of course that someone could very well be someone like you who's actually looked at the code...
I just find it odd that it is only the TreeViewCtrl that is causing problems for me (I have four editors based upon the WorldEditor, but the TreeViewCtrl is in only one), which leads me to believe that some or all of the problems are here, waiting to be discovered.
#5
I don't claim to have mastered this code at all, and if it turns out that there is a better fix then the one I suggested above, I will be glad to add it to my code, or merge it if it's fixed in 1.5.2.
05/02/2007 (2:59 pm)
@James,I don't claim to have mastered this code at all, and if it turns out that there is a better fix then the one I suggested above, I will be glad to add it to my code, or merge it if it's fixed in 1.5.2.
#6
Now that I've actually looked at the code, I can identify what I think are two bugs. I don't understand it well enough to fix them, but I was able to create a workaround for my main problem. It seems that on about line 1813 the code says:
However, when I debug this, mSelectedItems is either Empty or duplicate copies of the same items, so it always returns TRUE. Why things are added twice, I don't know. But I changed > 1 to != 2 as a kludge and it'll no longer eat my events. Of course, it really shouldn't return true but instead Parent::onKeyDown.
The other bug looks like it might have been fixed in 1.5.1. It has to do with the hitTest of the labels, but I'll have to look at it later.
I don't see anything that would explain your issue and I think your solution looks like a valid safety net. I did verified that my other editors do use the EditorManager and call the same code, so I still think there's something fishy about the TreeViewCtrl, but there you are...
James
05/02/2007 (3:21 pm)
@Steve,Now that I've actually looked at the code, I can identify what I think are two bugs. I don't understand it well enough to fix them, but I was able to create a workaround for my main problem. It seems that on about line 1813 the code says:
// only do operations if only one item is selected
if ( mSelectedItems.empty() || (mSelectedItems.size() > 1))
return true;However, when I debug this, mSelectedItems is either Empty or duplicate copies of the same items, so it always returns TRUE. Why things are added twice, I don't know. But I changed > 1 to != 2 as a kludge and it'll no longer eat my events. Of course, it really shouldn't return true but instead Parent::onKeyDown.
The other bug looks like it might have been fixed in 1.5.1. It has to do with the hitTest of the labels, but I'll have to look at it later.
I don't see anything that would explain your issue and I think your solution looks like a valid safety net. I did verified that my other editors do use the EditorManager and call the same code, so I still think there's something fishy about the TreeViewCtrl, but there you are...
James
Torque Owner Steve Lamperti
Imagine That!
In EditManager::onSleep() at the end, right before the closing bracket, I added the following code:
// JSL - fix keyboard control loss bug. GuiControl* responder = Canvas->findFirstTabable(); if(responder) responder->setFirstResponder();At the end of the includes, I had to add the following: