file opening problem
-
Hello, I try to open a file using FILE *fopen( const char *filename, const char *mode ); but the function returns NULL. The file exists and is in the same directory than my executable. I tried with the emulator (the path is correct) and on the device and it doesn't work! Is it possible that the "working directory" of the executable is not his own directory ??? Any idea? Thanks
-
Hello, I try to open a file using FILE *fopen( const char *filename, const char *mode ); but the function returns NULL. The file exists and is in the same directory than my executable. I tried with the emulator (the path is correct) and on the device and it doesn't work! Is it possible that the "working directory" of the executable is not his own directory ??? Any idea? Thanks
cedric moonen wrote: FILE *fopen( const char *filename, const char *mode ); Oh, boy... :eek: Windows CE means UNICODE! So, never ever forget to use the wide char versions of everything. Forget
char, useTCHAR! Also,fopenwill NOT work, use_wfopen. Check the help file in order to find all wide character versions of the functions you would use on a desktop. -
cedric moonen wrote: FILE *fopen( const char *filename, const char *mode ); Oh, boy... :eek: Windows CE means UNICODE! So, never ever forget to use the wide char versions of everything. Forget
char, useTCHAR! Also,fopenwill NOT work, use_wfopen. Check the help file in order to find all wide character versions of the functions you would use on a desktop.Hi ! Thanks for response. First, fopen is supported. Taken directly from the MSDN help (from win CE !): Remarks The fopen function opens the file specified by filename. _wfopen is a wide-character version of fopen; the arguments to _wfopen are wide-character strings. _wfopen and fopen behave identically otherwise. If I still want to use char* in winCE, that's because I want to import some of my desktop libraries (I cannot write everything again). So, if char is supported for some functions (like fopen), I won't change everything ! Second, the "solution" to the problem: I made some test (open a file in write mode so I can check where is the default directory). The error is what I supposed it is: the default directory is not the directory of the executable, it's the "main root". So, I have to specify complete path :(. Anyway, thanks for help ;)! PS: I think I will post some silly questions like that for a while 'cause it's the first time I work on a PocketPC and I worked a lot before on desktop version... :)!
-
Hello, I try to open a file using FILE *fopen( const char *filename, const char *mode ); but the function returns NULL. The file exists and is in the same directory than my executable. I tried with the emulator (the path is correct) and on the device and it doesn't work! Is it possible that the "working directory" of the executable is not his own directory ??? Any idea? Thanks
cedric moonen wrote: Is it possible that the "working directory" of the executable is not his own directory ??? Windows CE does not support 'working directories'. You will have to supply the full path to the file you wish to open. GetModuleFileName can be used to find the path to the exe. Jonas “Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002
-
cedric moonen wrote: Is it possible that the "working directory" of the executable is not his own directory ??? Windows CE does not support 'working directories'. You will have to supply the full path to the file you wish to open. GetModuleFileName can be used to find the path to the exe. Jonas “Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002
Hi, Ok thanks :)
-
Hi ! Thanks for response. First, fopen is supported. Taken directly from the MSDN help (from win CE !): Remarks The fopen function opens the file specified by filename. _wfopen is a wide-character version of fopen; the arguments to _wfopen are wide-character strings. _wfopen and fopen behave identically otherwise. If I still want to use char* in winCE, that's because I want to import some of my desktop libraries (I cannot write everything again). So, if char is supported for some functions (like fopen), I won't change everything ! Second, the "solution" to the problem: I made some test (open a file in write mode so I can check where is the default directory). The error is what I supposed it is: the default directory is not the directory of the executable, it's the "main root". So, I have to specify complete path :(. Anyway, thanks for help ;)! PS: I think I will post some silly questions like that for a while 'cause it's the first time I work on a PocketPC and I worked a lot before on desktop version... :)!
cedric moonen wrote: First, fopen is supported. It is, but are you reading ANSI or UNICODE content? Are you specifying ANSI or UNICODE filenames and modes? When I moved to CE, I forgot about ANSI just to make my life less miserable, and it worked. cedric moonen wrote: So, I have to specify complete path Yes, CE is a bitch. Is it working, now?
-
cedric moonen wrote: First, fopen is supported. It is, but are you reading ANSI or UNICODE content? Are you specifying ANSI or UNICODE filenames and modes? When I moved to CE, I forgot about ANSI just to make my life less miserable, and it worked. cedric moonen wrote: So, I have to specify complete path Yes, CE is a bitch. Is it working, now?
João Paulo Figueira wrote: Are you specifying ANSI or UNICODE filenames and modes? I just open it for reading ("r") and that works fine. The contents are normal string that are stored in char*. João Paulo Figueira wrote: When I moved to CE, I forgot about ANSI just to make my life less miserable, and it worked. Yep, but I cannot do that: I have a huge library that was developed on desktop environment and I want to reuse it (rewrite everything will take me really too much time) and I need to be compatible with the file format from my desktop computer (they need to understand each other). So, I have no choice: I will need to use ANSI string and convert them to UNICODE when they are not supported :( ! But I think I'll find a way out ;) ! João Paulo Figueira wrote: Is it working, now? Yes, it is :)! Anyway, thanks ;)