GuiControl bug, "AP
by Tim Heldna · in Torque Game Engine · 07/29/2006 (8:11 am) · 9 replies
Here's a weird one.
Open any GUI control with the GUI editor, such as the options screen, and click on the first GuiControl in the list or the parent if you prefer.
Nearly all fields in that control are filled with the text "AP".
What's the story?
Open any GUI control with the GUI editor, such as the options screen, and click on the first GuiControl in the list or the parent if you prefer.
Nearly all fields in that control are filled with the text "AP".
What's the story?
About the author
#3
07/30/2006 (2:51 am)
Yeah I do the majority of my GUI work in script too as the editor seems to just mess things up. Which is a shame, what's the point of having a GUI editor if for the most part it doesn't work? 
#4
Go into gui\editor\guiInspector.cc and find void GuiInspectorField::setData( StringTableEntry data ). Change this code:
to
and *voila*, this bug should clear right up!
I have to give a major shout-out to Tom Bampton for providing the fix once I was able to track down the where/what/how of this bug!
08/11/2006 (11:46 am)
This is one of the nastier bugs I've ever seen in Torque but the fix is really simple =)Go into gui\editor\guiInspector.cc and find void GuiInspectorField::setData( StringTableEntry data ). Change this code:
if( mField == NULL || mTarget == NULL )
return;to
if( mField == NULL || mTarget == NULL )
return;
[b]data = StringTable->insert(data, true); // <--- This is the new code[/b]and *voila*, this bug should clear right up!
I have to give a major shout-out to Tom Bampton for providing the fix once I was able to track down the where/what/how of this bug!
#6
I second that. This is one of the worst bugs I've seen in a while, purely because it's so easy for anyone to do it, and it's results are incredibly obscure and hard to track down.
This bug has actually been annoying me since a long time before it was brought up on the forums, but I didn't have time to put in the significant amount of effort it took to figure out a solid repro case. Once Matt had done that hard work, the fix was relatively obvious within a few seconds debugging ;-)
In case you are wondering, here's the gory details:
The value that was being passed to the setData() method came from a ConsoleMethod's argv array. The script interpreter uses a static array for argv for calls made from script.
The setData() method calls inspectPreApply(). For GuiControls, this calls onSleep(), which in turn causes a call into script to the script version of onSleep(). At this point, everything is still fine since the call to Con::executef() specified a new argv array.
However, if the script onSleep() calls another function or method (in script), then the script interpreter's argv array will get munged. Since the value passed to setData() was part of that argv array, the data gets munged.
Thus, using the StringTable means we get a nice static string that won't get munged. We could also have copied it into a buffer, but that would be lame since the StringTable is there ;-)
One thing to note about this fix is that since setData() takes a StringTableEntry, it's arguable that it expects it's arg to already be in the string table and thus the proper fix would be to fix the apply() ConsoleMethod. However, I figured it was safer to fix it this way just in case there is other code that calls it without a string table entry. In any case, inserting something to the string table that's already in there returns the same pointer (which is part of the point in it's existence anyway) and it's not really an area of the code where we need to worry about performance.
The moral of this story? If you have some data that may have come through args to a ConsoleFunction / ConsoleMethod and you call into script, you'd better make sure that you have a safe version of it if you want to use that data after the Con::executef(). You're in for a whole world of hurt otherwise ;-)
T.
08/11/2006 (12:28 pm)
Quote:This is one of the nastier bugs I've ever seen in Torque
I second that. This is one of the worst bugs I've seen in a while, purely because it's so easy for anyone to do it, and it's results are incredibly obscure and hard to track down.
This bug has actually been annoying me since a long time before it was brought up on the forums, but I didn't have time to put in the significant amount of effort it took to figure out a solid repro case. Once Matt had done that hard work, the fix was relatively obvious within a few seconds debugging ;-)
In case you are wondering, here's the gory details:
The value that was being passed to the setData() method came from a ConsoleMethod's argv array. The script interpreter uses a static array for argv for calls made from script.
The setData() method calls inspectPreApply(). For GuiControls, this calls onSleep(), which in turn causes a call into script to the script version of onSleep(). At this point, everything is still fine since the call to Con::executef() specified a new argv array.
However, if the script onSleep() calls another function or method (in script), then the script interpreter's argv array will get munged. Since the value passed to setData() was part of that argv array, the data gets munged.
Thus, using the StringTable means we get a nice static string that won't get munged. We could also have copied it into a buffer, but that would be lame since the StringTable is there ;-)
One thing to note about this fix is that since setData() takes a StringTableEntry, it's arguable that it expects it's arg to already be in the string table and thus the proper fix would be to fix the apply() ConsoleMethod. However, I figured it was safer to fix it this way just in case there is other code that calls it without a string table entry. In any case, inserting something to the string table that's already in there returns the same pointer (which is part of the point in it's existence anyway) and it's not really an area of the code where we need to worry about performance.
The moral of this story? If you have some data that may have come through args to a ConsoleFunction / ConsoleMethod and you call into script, you'd better make sure that you have a safe version of it if you want to use that data after the Con::executef(). You're in for a whole world of hurt otherwise ;-)
T.
#7
11/10/2006 (10:46 am)
Why isn't something like this fixed in the HEAD version and download version?
#8
T.
11/10/2006 (11:35 am)
It is. We checked it into trunk before posting in this thread. There have been at least 2 new versions of Torque shipped since then, so I'd be surprised if it wasn't in there.T.
#9
11/10/2006 (12:47 pm)
Why don't GG post a blog or send an email advisory to say the source has been updated again. Or is there some other way of notification I don't know about? 
Torque Owner Cliff