Parent Child Objects in different files
BlitzMax Forums/BlitzMax Beginners Area/Parent Child Objects in different files
| ||
| Hi All, I've got into a sticky mess creating my game, so I've decided to go back to basics in order to understand how BlitzMax can be used with multiple files. After one test I'm confused. I am unable to compile a Parent Child relationship where the Child can talk to the Parent. If I place the code in one file it complies OK: 'main2.bmx Type TFather Field c:TChild Method InitChild() c = New TChild End Method End Type Type TChild Field parent:TFather End Type Global Father:TFather = New TFather Father.InitChild() However spliting the files and using Imports does not work, here I have three files: 'main.bmx Import "TFather.bmx" Import "TChild.bmx" Global Father:TFather = New TFather Father.InitChild() ' TFather.bmx Strict Import "TChild.bmx" Type TFather Field c:TChild Method InitChild() c = New TChild End Method End Type ' TChild.bmx Strict Import "TFather.bmx" Type TChild Field parent:TFather End Type Gives the error "Compile Error. Unable to open file '.bmx/TFather.bmx.debug.win32.x86.i" I assume this error is because TFather is importing TChild and TChild is importing TFather. So before a file can compile the other file must be known. In C++ I'd create a header file for each object then include the header file but with a compilation directive that would say, hey if you've compiled this don't try and compile it again. But it appears that the BlitzMax compiler doesn't have the option to include these compiler directives. Nor the intelligence to work it out what has been compiled already (I thought this was the point of multiple passes in a compiler?). The only other option I have been able to get to compile is to remove all Imports from all files, then in the Main.bmx use "Include" on all of the files. While this works it seems to defeat the purpose of compiling individual files and of object reuse. What is the excepted and best practice for using multiple objects and files in a single program? Maybe this is just not possible? Regards, Jon |
| ||
| defeat the purpose of compiling individual files and of object reuse you've removed that option by coupling the 2 types together. just use include and move forward with the project. |
| ||
| Thanks for the reply. I've tried the Import on that one file and Import on the others. Now it's giving me properties not found on objects. I've stuffed up somewhere. I could pass all of the parent properties to the child, but that seems quite inefficient, but I'll leave that as an option. Since I'm using the Blide editor I'm going to try the "Managed Solution" build option and see if it can get it to work. I'll post back as I'm sure others must run into this problem for non trivial games. Thanks, Jon |
| ||
| OK that took 22 minutes to convert my game from an "unmanaged solution" in Blide to a "Managed solution". It's now compiling. If others are interested then the Managed Solution allows you to remove all Imports and Includes, in doing so the IDE will then "Manage" them for you. For reference "Blide" is a replacement IDE for BlitzMax: http://www.blide.org/ It's not ideal in that I'm now stuck on Windows and wont be able to easily compile for the Mac later. But I figure it's my first game in BlitzMax and I want to be coding the game and worrying as little as possible about the limitations of the compiler. Though if anyone does have a solution to this Parent/Child communication across files issue then I'd be keen to hear your thoughts! (the response - learn how to design OOP properly is a valid one) Regards, Jon |
| ||
| It's not ideal in that I'm now stuck on Windows and wont be able to easily compile for the Mac later Yes! The managed solution code is compatible with mac and Linux. Just compile the program manager that is automatically generated by BLIde on a Max or Linux and it'll work. |
| ||
| Excellent news! Thanks for the correction. :o) Thanks, Jon |
| ||
| Doesn't it just create a huge list of includes? |
| ||
| Doesn't it just create a huge list of includes? It deppends on how you organize your solution. If there's only one main program manager, everything else will be included but you can create as much additional program managers as you want spread and orgnize your code files in 'compilation units' and make those compilation units imported on other compilations units. In the form of a compilation tree. That is easilly done using BLIde managed solutions and mixes the best of import and include. You can have more info about this here: http://www.blide.org/help/index.html?add_import_nodes_to_a_managed_.htm |
| ||
| Interesting. But, I like to keep control of my imports and includes manually, so if I ever need to play with my code without BLIde, I understand the way they are organized better. Anyway, I am sure it is personal preference. I'm just a control freak. That is why I was so happy when you added the unmanaged solutions, which is also when I bought BLIde. :) |
| ||
Consider this alternate design which uses only one type? (It depends exactly what these types do in your game)Type TPerson Field name:String Field parent:TPerson Field child:TPerson Method GetChildName:String() If child Then Return name Else Return "" End Method End Type With this structure, you can have multiple generations of people, eg grandfather. However you'd need to check that parent/child is not Null before accessing them, as you can't tell whether a person has a child or not just by looking at the type. You could put this check into some kind of GetChild... method for example. If you want people to have multiple parents/children, you'll need to change the fields to lists or arrays of TPerson but I'll leave that up to you :) Anyway, I am sure it is personal preference. I'm just a control freak. I love managed solutions :D I don't see what there is to get control freaked over? |
   |