Why is GuiCanvas its own Parent?
by Aaron Wieland · in Torque Game Builder · 08/27/2005 (11:54 pm) · 6 replies
Although GuiCanvas subclasses GuiControl, and its Parent typedef is defined accordingly, the GuiCanvas namespace is linked to... the GuiCanvas namespace, which in turn links to the GuiControl namespace. Given that endless recursion does not occur, there must be two instances of the GuiCanvas namespace.
This oddity is demonstrated by opening the console and entering writeOutClasses();, and then examing the docs for GuiCanvas. Or, you can tell a GuiCanvas to perform an invalid method, and then read the error message; e.g., (new GuiCanvas()).foo();.
I encountered this discrepancy while generating wrapper classes -- when infinite recursion was a problem.
This oddity is demonstrated by opening the console and entering writeOutClasses();, and then examing the docs for GuiCanvas. Or, you can tell a GuiCanvas to perform an invalid method, and then read the error message; e.g., (new GuiCanvas()).foo();.
I encountered this discrepancy while generating wrapper classes -- when infinite recursion was a problem.
#2
08/28/2005 (1:07 am)
Oh, and if you care to explain "what is a torque namespace and how it's used" it would help too. I know there are some posts scattered around that talk about it a bit, but i havent needed to hunt for it before so I dont think i'll start now :)
#3
I originally generated the wrappers by parsing the output of writeOutClasses() and writeOutFunctions(). Though mostly successful, that effort turned out to be a bad idea, because it relied on the accuracy of the documented usage for each method (at least it gave me an excuse to learn SmaCC, a Smalltalk Compiler Compiler). Incidentally, I had the same problem with GuiCanvas, but I worked around it by editing the text file.
I needed the minimum and maximum number of arguments for each method and function, and I didn't want to muck around with any more parsing. So, I took another look at the code in consoleDoc.cc that implements writeOutClasses() and writeOutFunctions(). I didn't care for the prospect of teasing apart the code for traversing the class hierarchy and the methods and fields of each class. Instead, I copied and pasted the whole thing, and modified it to create a class that used function pointers (callbacks) instead of printXXXX(). (I normally hate copying and pasting, but that's sometimes the best I can do while working with code I'm not responsible for maintaining.) That turned out to be relatively quick and easy, certainly easier than parsing text files. But once again, there was that inconsistency with GuiCanvas.
Because I'm using the scripting interface, the wrappers aren't essential, merely nice to have; they make the syntax much cleaner. And I'm nearly finished (with the automated part, anyway; I'll probably add a few convenience methods manually later on).
I'm not an expert on namespaces either, but they usually mirror the C++ class hierarchy. There's a good explanation of namespaces here. Like you, I'm doing this work to avoid getting too familiar with TorqueScript. ;-)
08/28/2005 (6:42 am)
I appreciate the generous offer of assistance, but everything worked fine after I added a hack to handle GuiCanvas. I reported the issue in case it was a bug; if so, I can remove the hack once it's been fixed.I originally generated the wrappers by parsing the output of writeOutClasses() and writeOutFunctions(). Though mostly successful, that effort turned out to be a bad idea, because it relied on the accuracy of the documented usage for each method (at least it gave me an excuse to learn SmaCC, a Smalltalk Compiler Compiler). Incidentally, I had the same problem with GuiCanvas, but I worked around it by editing the text file.
I needed the minimum and maximum number of arguments for each method and function, and I didn't want to muck around with any more parsing. So, I took another look at the code in consoleDoc.cc that implements writeOutClasses() and writeOutFunctions(). I didn't care for the prospect of teasing apart the code for traversing the class hierarchy and the methods and fields of each class. Instead, I copied and pasted the whole thing, and modified it to create a class that used function pointers (callbacks) instead of printXXXX(). (I normally hate copying and pasting, but that's sometimes the best I can do while working with code I'm not responsible for maintaining.) That turned out to be relatively quick and easy, certainly easier than parsing text files. But once again, there was that inconsistency with GuiCanvas.
Because I'm using the scripting interface, the wrappers aren't essential, merely nice to have; they make the syntax much cleaner. And I'm nearly finished (with the automated part, anyway; I'll probably add a few convenience methods manually later on).
I'm not an expert on namespaces either, but they usually mirror the C++ class hierarchy. There's a good explanation of namespaces here. Like you, I'm doing this work to avoid getting too familiar with TorqueScript. ;-)
#4
though later on (a few days ago actually) I found out that some classes such as guiFadeIn..whatever... dont actually contain added scripting functionality, so I also added functionality to parse the IMPLEMENT..whatever... macro's that are sprinkled in the definitions. This seems to be THE way to figure out what to parse, and i should probably modify my parser to ignore classes that dont use the IMPLEMENT... macro. (Though it seems to work fine now, and i havent tracked down exactly what the IMPLEMENT macro does, so i'll probably leave it for now)
sorry i am adding ...whatever... to the end of everything... i'm not near my dev machine right now so I'm recalling from memory :)
thanks for the heads up on the namespaces.. i'll check that out.
08/28/2005 (11:55 am)
The primary way I mapped the functions was by parsing ConsoleMethods and ConsoleFunctions,though later on (a few days ago actually) I found out that some classes such as guiFadeIn..whatever... dont actually contain added scripting functionality, so I also added functionality to parse the IMPLEMENT..whatever... macro's that are sprinkled in the definitions. This seems to be THE way to figure out what to parse, and i should probably modify my parser to ignore classes that dont use the IMPLEMENT... macro. (Though it seems to work fine now, and i havent tracked down exactly what the IMPLEMENT macro does, so i'll probably leave it for now)
sorry i am adding ...whatever... to the end of everything... i'm not near my dev machine right now so I'm recalling from memory :)
thanks for the heads up on the namespaces.. i'll check that out.
#5
08/28/2005 (12:40 pm)
Are you referring to the namespace hookup that happens in GuiCanvas::onAdd ?
#6
Unfortunately, I lack a decent setup for debugging the engine, so I'm not sure where it happens. But I took your cue and looked at GuiControl::onAdd(), and I think that might be the culprit. It appears that when a GuiControl is created, and it has a name, its namespace is linked to that of its class rep -- and wouldn't that be the same namespace in the case of GuiCanvas? Is that code intended for script objects, when the namespaces wouldn't match? Perhaps I'm just confused. ;-) I'm still unsure how two Namespace objects with the same name are created.
08/28/2005 (5:12 pm)
@Robert:Unfortunately, I lack a decent setup for debugging the engine, so I'm not sure where it happens. But I took your cue and looked at GuiControl::onAdd(), and I think that might be the culprit. It appears that when a GuiControl is created, and it has a name, its namespace is linked to that of its class rep -- and wouldn't that be the same namespace in the case of GuiCanvas? Is that code intended for script objects, when the namespaces wouldn't match? Perhaps I'm just confused. ;-) I'm still unsure how two Namespace objects with the same name are created.
Torque Owner Jason Swearingen
Though, you are obviously doing it different from me. I look at the C++ code and parse it to determine what's what's parrent.
Honestly, I dont really know what this "namespace" stuff in torque is about. probably because I havent had the need to learn what exactly a torque namespace is....
if you want to elaborate more on what you are wrapping and why, and why you use namespaces, maybe i can help you. (I wrote a C# wrapper, t2d.net, and it is at 100% of t2d functionality right now)
-Jason