For simple debugging purposes, I'm trying to write certain stats to a file. But each time I do, I get an error message. My code (actually to test) straight from the manual:
function Log_Grid()
{
File *output = File.Open("c:\temp.tmp", eFileWrite);
if (output == null)
Display("Error opening file.");
else {
output.WriteString("test string");
output.Close();
}
}
Now all I get is error opening file, no matter what I try. What can be wrong?
Two remarks on this piece of code:
1: Shouldn't the output.Close(); be moved one bracket down? In this example the file gets opened, if nothing is written to it, it stays open.
2: Why aren't there brackets after the first if?
In my opinion, the code should look like:
function Log_Grid()
{
File *output = File.Open("c:\temp.tmp", eFileWrite);
if (output == null) {
Display("Error opening file.");
}
else {
output.WriteString("test string");
}
output.Close();
}
But also that doesn't work (Error opening file...)
If anyone could guide me to the correct solution..
I haven't read the codes yet, but try to remove the "c:\" parts in those File.Open() calls and see if it works.
As far as I remember, for security reasons (so you cannot mess up others' and your systems by say, wiping out important files in C:\Windows, etc.) writing are allowed only on files that are located in the game's own folder and down (say gamename\dat\).
Gilbot is correct as for the reason your code isn't working. But to answer your two other questions:
Quote from: Leon on Wed 21/01/2009 03:32:21
1: Shouldn't the output.Close(); be moved one bracket down? In this example the file gets opened, if nothing is written to it, it stays open.
2: Why aren't there brackets after the first if?
1: No, because if (output == null) returns true, the file wasn't opened, and hence need/can not be closed.
2: The brackets aren't necessary because only one function is run after the if statement. It might as well read "if (output == null) Display("Error opening file,");" on a single line. The linebreak is purely a matter of style and will be ignored by the compiler.
Thanks for the answers.
I realised the way of thinking too late. Why close what can't be opened in the first place? :)
It still doesn't work. But another error though: Error: Null Pointer Referenced (on the line with >>)
I try to write the contents of a 6x6 grid to file, so I get 6 chars on 6 lines:
The complete code:
int aa = 1;
int bb = 1;
String myStr;
File* myoutput = File.Open("grid.txt", eFileAppend);
if (myoutput == null) {
Display("Error opening file.");
}
else {
while (aa < 7) {
while (bb < 7) {
>> myStr = myStr.Append(String.Format("%d",GetGrid(aa, bb)));
bb++;
myoutput.WriteRawLine(myStr);
}
bb = 1;
myStr = "";
aa++;
}
myoutput.WriteRawLine(myStr);
myoutput.Close();
}
Two more questions about this.
-When a file doesn't exist and you use eFileAppend, is the file created? Or should I do a File.Exist first then?
-Does it matter where this function resides? At the moment it's in the room script. I tried it in the global with an import in the room script with the same result.
[edit]
When I come to think of this... why this whole exercise... Is there a way to see the value of variables at runtime? In VisualStudio you have the Watch-option to see them at breakpoint and 'play' with them. Is anything similar in AGS possible?
Strings initialize to null. Just replace:
String myStr;
With:
String myStr = "";
;)
I believe that eFileAppend will attempt to create non-existent files.
As for the location of the script, you shouldn't put it in the room script unless you want it only available in that room. Even if you import it at a global level it may not work right since room scripts are only loaded while in that room.
There's no way to do this directly yet, but you could view them using the string formatting functions of Character.Say/Display/String.Format, the last in correlation with a GUI Label would allow lots of flexibility....
Man, if all was that simple... thnx! Worked like a charm (after tweaking the output).
The string.format together with a GUI is what I use at the moment for debugging but it's sometimes too fast. That's why the file comes in handy.
Thnx again.