1) I separated Code new demo.zip attached to 1st post
Well, you're getting closer. Now you need to move your variable definitions into the functions.
For example:
// function to write a file
BOOL WriteToFile(PTCHAR String)
{ HANDLE file; // file handle
DWORD fsize; // size of file
.. open and write file here
CloseHandle(file);
return 1; }
By "non-globalizing" as many variables as possible you forestall the risk of ending up with unexpected or unknown contents when you do your function. Since the variables are created in the function, used only in the function and destroyed when it exits, you know exactly what you are dealing with. As general practice I use as few global variables as possible and have written entire applications with none at all.
I noticed the comment in your source that windows likes small text buffers. While this is true, it is always smartest to allocate extra space unless you have the means to discover the correct buffer size "on the fly".
For example: The maximum size of a file path is defined as MAX_PATH which is currently 260 TCHARs. You should always assign MAX_PATH + 1 and use and use an initializer to guarantee you know the contents going in. The +1 guarantees your string is null terminated.
Like this...
TCHAR CurentDirectory[MAX_PATH +1] = {0};
// get working directory
GetCurrentDirectory(MAX_PATH,CurrentDirectory);
In my own code I always have large lists of predefined buffer sizes that I apply throughout the code from a global .h file.
For Example...
// buffer sizes
#define MAX_HOSTNAME MAX_COMPUTERNAME_LENGTH
#define MAX_LOGLINE 300 // tchars
#define MAX_TEXTIP 16 // tchars
#define MAX_TEXTPORT 6 // tchars
#define MAX_PASSWORD 24 // tchars
#define MAX_UNCPATH 256 // tchars
#define MAX_TOOLTIP 32 // tchars
#define MAX_REMOTENAME 24 // tchars
#define MAX_PROGRAMNAME 24 // tchars
#define MAX_TYPENAME 20 // tchars
#define MAX_DGRAMDATA 1024 // bytes
2) Maybe i expressed my prob a bit unclear,
its not about the return values of windows functions
its about how unicode is encoded in windows functions.
Well, the programmer in me says "you don't need to know" since windows function calls (as opposed to C-99 calls) handle this seamlessly. But the fact is that (currently) a TCHAR is a 16 bit value, so it's two bytes. However, you should not count on that. With new OSs like Win7 (spit, curse!) and X64 versions of everything that may change.
The smarter way is to use the sizeof function...
// function to get byte size of string
DWORD GetBufferSize(PTCHAR String)
{ DWORD sl; // string length
sl = lstrlen(String); // get string length in TCHARS
sl *= sizeof(Tchar); // convert to byte size
return sl; } // send back the answer
// more efficient version
DWORD GetBufferSize(PTCHAR String)
{ return lstrlen(String) * sizeof(TCHAR); }
Either version will return the correct byte size whether UNICODE is defined or not.
i.e. if i use chinese (windows IME Pinyin)
and prly mix up with latin letters
in a dialog textfield
is every Unicode Code Token coded in 2 bytes ?
Or are there exceptions as some sources say
wich would make results differ from 1-5 bytes ?
Currently it's 2 bytes, but as explained, you can't count on that in the future. You won't find mixed sizes in the same string (yet) as this would totally confuse any attemtps to edit or manipulate the string.
2-1)
If every symbol is coded in 2 bytes,
are the w-filefunction bad practice ?
Help says it writes widechars
but both write and open lead to wrong results.
(write makes 1 totally different chinese letter of 2)
(load seems to make greek or something from it)
Generally I prefer to use Windows calls over C calls as much as possible. The problem is that Windows definition of Unicode can and sometimes does differ from that in C-99. Staying with windows functions provides a much more integrated approach that will update itself across different versions of windows as you recompile.
The thing to remember is that Microsoft (Spit, Curse!) is under some obligation to keep things compatible, C language maintainers are not (although Pelle has always done a great job of it).
3) Thank you for the basics,
i used mixed sources for learning and ended up wrong it seems.
Oh boy... if you only knew how many times I got it all wrong when I was first starting with C. Fact is I'm still amazed when I write something and it actually works the first try.
The best way to learn WinApi programming is to study WinApi code samples and read the tutorials. Windows is C, but the api calls are totally different, so it does take a while to learn, even if you already know C.
(Hense the suggestion that you download and install the Windows API documentation.)
