Reading/Writing & Types
Blitz3D Forums/Blitz3D Beginners Area/Reading/Writing & Types
| ||
That's TWICE now I've been caught out by the strange 'quirkiness' of ReadLine/Int etc. and Types. It's just annoying how I have been struggling with all sorts of other code until I finally remembered about this issue, so I thought Id post here to help anyone else that may have the same difficulty in the future! Blitz will not read the data whilst trying to populate the Type field. i.e Will result in NewType\FieldX=0 regardless of the data in the file. I have had to overcome this by a very simple workaround of: |
| ||
maybe can't create a type inside a file read/write operation? |
| ||
Im not sure, but I think it maybe to do with the order that Blitz compiles things (i.e. Types first), so it tries to populate the type fields before the values are resolved, effectively filling them with '0's as other undeclared vars... not sure though ;) |
| ||
Glad you mentioned this - just about to start doing similar. |
| ||
Odd, reading values directly into type fields works fine here. :/ |
| ||
Odd, reading values directly into type fields works fine here. :/ Works fine here as well. |
| ||
Heh... never worked for me, even from v1.83 |
| ||
This works on 1.90Type mytype Field x End Type File=OpenFile ("Myfile.txt") WriteInt(file,5) CloseFile file file=ReadFile("myfile.txt") NewType.MyType = New MyType NewType\x=ReadInt(File) CloseFile File Print newtype\x |
| ||
Okay, well - I seem to have another problem then... I believe it's connected to Global Types. I think I'm not declaring the Type as global properly so that when I come to populate it within the function, the main program doesn't record the instance... My function is: and my Type declaration goes very simply like this: |
| ||
Gah, see below - double posted myself!! |
| ||
You should consider outputting debuglog or text statements as you type fields get populated. At least you'll know whether they are set within the function or not. If they are set in the function and the debuglog statements suggest it's 0 outside then it's likely to be a global issue. BTW : Isn't it the type handle that needs to be global and not the type name? Type mytype Field x End Type Global newtype.mytype writing() reading() Print "Out function : " + newtype\x WaitKey() Function writing() File=WriteFile ("Myfile.txt") WriteInt(file,5) CloseFile file End Function Function reading() file=ReadFile("myfile.txt") NewType.MyType = New MyType NewType\x=ReadInt(File) CloseFile File Print "In function : " + newtype\x End Function |
| ||
I think you may have fallen for the common misunderstanding of how TYPES work in Blitz (I know I did!). Whenever you create a new instance of a TYPE ie. (LoadDecal.Shiplights = New shiplights) then the instance is ALWAYS global. Each instance of a TYPE you create is global and exists in your main routine and all functions. However!!! The pointer to that instance ('LoadDecal') is only local to your function. If you want to access this instance in your main code or another function, you will need to get a new pointer to that instance! Try doing this in your main code after (and maybe before!) calling your function: for test.shiplights = each shiplights ;test some 'type' data here next Hope that helps a bit, Rhy :) |
| ||
Well, in the Globals tab on the right of the 'debug' window, Shiplights always = 0 that's how I know it's not being populated.... But thanks, now that you mention it, Types have to be global because they can be iterated from wherever within a program! |
| ||
I think the debug window only shows you the current instance?? Not sure, cos I use Protean IDE. What does it show if you put a stop in your function after populating the type? Rhy :) |
| ||
Well, in the Globals tab on the right of the 'debug' window, Shiplights always = 0 that's how I know it's not being populated.... but the debuglog/text messages would have suggested that shiplights wasn't the problem. Never mind. |
| ||
DOH!!! Sussed it! In my PositionEntity commands, I forgot to enter 'MyType\.....' resulting in the Compiler assuming null values for undeclared variables such as 'My_Field' etc. etc. Changed to 'MyType\My_Field' and it's working fine! :) |
| ||
ah! the infamous "i forgot to do this" trick! :) rem: if you get a coding problem, break it down to the simplest example possible, test that out, make sure you know whats going wrong, (and of course how to fix it!), then go back to your big code and add it. saves alot of hassle. |
| ||
The biggest problem I have, is where "Galactic" has grown into a modular project with all the functions and routines etc. split across several files for 'Include' this is great for adding/changing bits, but very difficult to test small portions as so much relies on prior configurations. It's a shame that the compiler cannot be fed values at run-time, i.e. set a load of variables. I am currently trying to implement a debugging tool which will essentially be a copy of part of the code which will read relevant data from an editable file... It's a lot of work, and its tough because I wanna get back on with the flight engine :) thanks for the help & advice!!! |
| ||
Ahh. The blitzmax strict command would be handy to have in Blitz3D :) |