Jump to content


Photo

File_text_open_write() Return Error Opening File


  • This topic is locked This topic is locked
12 replies to this topic

#1 Dr. Mean

Dr. Mean

    GMC Member

  • New Member
  • 81 posts

Posted 12 February 2008 - 03:40 AM

So I'm just wondering what the file_text_open_write() and file_text_open_read() functions return in different cases. In the GM manual it says that it returns the file id of the opened file. But what if there was an error? Do these functions throw any exceptions? This would be beneficial to know. The error I am getting is "Error opening file for writing.".

Another interesting point is that this only occurred when I try to run the exe inside a compressed file (.rar, .7z, etc). I'm running windows XP.

I sent it to one friend who had Vista, and it worked fine. For another friend who had vista, it did not work, even when extracted! After a few times of trying, it actually worked for me trying to run the exe inside of the compressed file! o_O


If anyone could shed some light on this, I'd appreciate it.

Thanks,
Vince R.
  • 0

#2 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1842 posts
  • Version:GM:Studio

Posted 12 February 2008 - 05:20 AM

A quick check shows that file_text_open_read() returns -1 when the file does not exist. file_text_open_write() can't really return an error, since it will just create the file if it does not exist. I recommend always making sure that it will work manually though, before you attempt to use it (check that the file exists, that it's not read-only, etc).

As far as your game working on some PCs and not others, it sounds like it's just a difference between different compression programs. Some programs will extract all data from a compressed folder before running an exe, and others simple wont. If you're really worried about it create a self-extracting archive, make the game store all resources in the exe, or recommend that all users extract all the files manually before trying to play.
  • 0

#3 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 12 February 2008 - 11:17 AM

file_text_open_write() can't really return an error, since it will just create the file if it does not exist.

<{POST_SNAPBACK}>

Ehhrrmm... If it can't create the file (drive/folder does not exists, the file is read-only or other things) it should return a -1 value too.
  • 0

#4 Aragon1029

Aragon1029

    GMC Member

  • New Member
  • 940 posts

Posted 12 February 2008 - 11:47 AM

and this appears only if the directory isn't there, or the directory is unreadible, that function only reads un-compressed directorys so it can't read anythign inside o fa ZIP files, but R.E.A.L. can if im correct.
  • 0

#5 Dr. Mean

Dr. Mean

    GMC Member

  • New Member
  • 81 posts

Posted 12 February 2008 - 06:45 PM

Right, so it creates the file if it doesn't exist, but what if it can't.

Yeah, I understand that GM wouldn't be able to read files within a compressed file. That's why I said it makes sense that it didn't work. My question was simply how to check if it wasn't able to open the file. Also, interesting side note, it DOES work inside all compressed files (rar, zip, 7z) now for me. o_O

So as I understand your replies, the function will return -1 if it has to create the file, or if it is not able to. So if it returns -1, then one could check to see if the file exists to see if the creation was successful.

Also, you recommend checking if the directory exists and is writable? Any other checks you recommend?


Thanks for your help!


EDIT** I really wish these types of things were better documented =/.

Edited by Dr. Mean, 12 February 2008 - 06:53 PM.

  • 0

#6 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 12 February 2008 - 09:39 PM

So if it returns -1, then one could check to see if the file exists to see if the creation was successful.

<{POST_SNAPBACK}>

Nope. The -1 result means that the creation was unsuccessfull. Period.

It might even be so that you could not create the file because the allready-existing one has its read-only bit set or is located on a read-only medium (like a CD or DVD).

This means that even if you find that a file of the same name is present you still cannot write to it.

Hope that clarifies it.
  • 0

#7 Dr. Mean

Dr. Mean

    GMC Member

  • New Member
  • 81 posts

Posted 12 February 2008 - 09:40 PM

Alright there's been another development.

So I needed to rewrite all of my import/export functions to include error checking, and I came across another oddity while trying to check if a file was an archived file.

Here is my import script:

argument0 is the name of the save data file.
//checks to see if the directory exists, and creates it if it doesn't
CheckDirectory("gamedata");

fileid = file_text_open_read(argument0);

if (fileid == -1 || !file_exists(argument0))
{
    return false;
    exit;
}


if (file_attributes(argument0,fa_hidden) ||
    file_attributes(argument0,fa_sysfile) ||
    file_attributes(argument0,fa_volumeid) ||
    file_attributes(argument0,fa_directory))
{
    return false;
    exit;
}

//for loop that reads the values in the file into an array
//I've left this out because it doesn't relate to the problem at hand (I'm sure of it;) )


file_text_close(fileid);

return true;




Here is my export script:

argument0 is the name of the save data file.
CheckDirectory("gamedata");

fileid = file_text_open_write(argument0);

if (fileid == -1)
{
    if (!file_exists(argument0))
    {
        return false;
        exit;
    }
}


if (file_attributes(argument0,fa_readonly) || 
    file_attributes(argument0,fa_hidden) ||
    file_attributes(argument0,fa_sysfile) ||
    file_attributes(argument0,fa_volumeid) ||
    file_attributes(argument0,fa_directory))
{
    return false;
    exit;
}

//takes values out of array and writes them to file, using a for loop
//i left this out


file_text_close(fileid);

return true;



So those are my scripts. As you can see, in both cases, it checks to see if the file is hidden, a system file, etc., just in case someone messed with the properties. I [/i]previously[/i] had it check if the file was archived. But this always returned true, even when the file was clearly not in an archive. I am absolutely sure that this was the expression causing the scripts to return false, as I had it display the result of all the checks (for fa_readonly, fa_hidden, fa_sysfile, etc) individually.


So does anyone know what is up with that?


My app still works inside and out of archive files on my computer. At the moment, I'm still waiting to test it again on my friend's computer for whom it failed last time.
  • 0

#8 Dr. Mean

Dr. Mean

    GMC Member

  • New Member
  • 81 posts

Posted 12 February 2008 - 09:45 PM

So if it returns -1, then one could check to see if the file exists to see if the creation was successful.

<{POST_SNAPBACK}>

Nope. The -1 result means that the creation was unsuccessfull. Period.

It might even be so that you could not create the file because the allready-existing one has its read-only bit set or is located on a read-only medium (like a CD or DVD).

This means that even if you find that a file of the same name is present you still cannot write to it.

Hope that clarifies it.

<{POST_SNAPBACK}>



Ah okay. I just though that because you kind of implied it by saying "too" here:

file_text_open_write() can't really return an error, since it will just create the file if it does not exist.

<{POST_SNAPBACK}>

Ehhrrmm... If it can't create the file (drive/folder does not exists, the file is read-only or other things) it should return a -1 value too.

<{POST_SNAPBACK}>




Anyway, thanks though. However I see in your signature it says that your answers are only for GM 6.1. My questions are as follows.

How do you know that it returns -1 when there is an error (not if a file had to be created because it didn't exist?
Does the same function work the same way in GM 7 as opposed to GM 6.1?


Thanks!
  • 0

#9 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 12 February 2008 - 10:03 PM

Ah okay. I just though that because you kind of implied it by saying "too" here:
<snip quote>

<{POST_SNAPBACK}>

:medieval: That "too" was in relation to the "file_text_open_read(...)" command. Both will return a -1 on failure.

Anyway, thanks though. However I see in your signature it says that your answers are only for GM 6.1. My questions are as follows.

Thats not quite what I ment to say with it. My answers could be (and mostly are) valid for v7.0 too, but I have no way of checking that (I do not run GM v7.0 here).

How do you know that it returns -1 when there is an error (not if a file had to be created because it didn't exist?

Because I had a hunch that it would and I tested it. :P

Does the same function work the same way in GM 7 as opposed to GM 6.1?

Well, what stops you from testing that for yourself ? :rolleyes: But yes, I think it will.

Hope that helps.
  • 0

#10 Dr. Mean

Dr. Mean

    GMC Member

  • New Member
  • 81 posts

Posted 12 February 2008 - 10:18 PM

haha... okay thanks.


Yeah, I didn't want to use GM 7 when it came out.... sort of because I disliked that Mark Overmars sort of "sold out" to a stupid game company, and also because it required stupid sign up and registration things. Sort of like windows vista. GM 6.1 is to GM 7 as XP is to Vista. Or at least that's the way I perceived it.

I finally got it a few days ago, and it's not that bad. hehe. I really just wanted to get it so this small game I'm working on will run on vista, because GM 6.1 apps wont run on vista (in my experience anyway, not even in compatibility mode). I would assume that's because GM 6.1 was released even before vista was, hehe.


anyway, thanks for helping me out. I'll let everyone know if your "hunch" was right about returning -1.
  • 0

#11 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 12 February 2008 - 10:37 PM

I really just wanted to get it so this small game I'm working on will run on vista, because GM 6.1 apps wont run on vista

<{POST_SNAPBACK}>

You can download a "conversion" program from the YoYoGames website that will enable GM6-games to run on Vista. Can't remember the name of the program though.

anyway, thanks for helping me out. I'll let everyone know if your "hunch" was right about returning -1.

You're welcome :rolleyes:

Edited by ragarnak, 12 February 2008 - 10:37 PM.

  • 0

#12 Dr. Mean

Dr. Mean

    GMC Member

  • New Member
  • 81 posts

Posted 13 February 2008 - 12:23 AM

Ahh thank you for that. I'll try to look up that program...


Now... about my question in post #7!


To repeat, how does the file_attribute() function handle fa_archive? It seems not to work. I wont repeat any more, as it's all in post #7.


I'd really appreciate help on this one!

Thanks!
  • 0

#13 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 13 February 2008 - 08:26 AM

Ahh thank you for that. I'll try to look up that program...

<{POST_SNAPBACK}>

You're welcome. If you can't find it let me know (PM me with an E-mail address), and I can send you the program (I have it stored here).

Now... about my question in post #7!

To repeat, how does the file_attribute() function handle fa_archive? It seems not to work. I wont repeat any more, as it's all in post #7.

I think its based on a mis-understanding: the "fa_archive" bit is just a "this file has been written to since last time this bit was cleared" flag.

Its purpose is to aid (old, DOS-style) backup-programs to figure out which files have changed since the last backup and need to be updated. After that the backup-program clears that flag.

Suggestion: go to a file, right-click it and select "properties". Somewhere at the bottom there is a tick-mark set named "Archive". Un-set it and check with GM what the result is now.

Hope that helps.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users