First, the previous figure shows the "run" dialog box for earlier versions of July.
In my initial conception, the prompt text in this dialog box is not the default text of the system, but should be written by me-at least Replace "Windows" with "July ".
But I finally gave up, because the words I wrote are garbled at the end. Since the runfiledlg API does not have detailed documentation support, and I do not have any reverse capabilities at the time, I simply gave the text parameter a null and used the default prompt to calculate the ball.
In retrospect, it is actually a fault caused by tchar. At that time, the runfiledlg statement I obtained from the Internet looked like this:
Int winapi runfiledlg (<br/> hwnd hwndparent, <br/> hicon, <br/> lpctstr pszworkingdir, <br/> lpctstr psztitle, <br/> lpctstr pszprompt, <br/> DWORD dwflags <br/> );
My development environment is vc6, and the project settings have not been changed. As a result, a ball is garbled. Because the string parameter of runfiledlg is actually the lpcwstr, and vc6 defines the lpctstr as the lpcstr by default.
I think it's time to review the meaning of tchar. It, as well as lptstr and lpctstr are both a typedef, not a specific type. It will point to the true type, that is, wchar or char, as the compiler determines whether a unicode macro is defined. In other words, tchar is indeed compatible with Unicode and ANSI encoding, but this compatibility is at the source code level. What should it be in the compiled PE executable image. Consider the following code:Char STR [32]; <br/> lstrcpy (STR, "Hello, world ");
I have seen countless similar code, and even I have written it like this. In the compiling environment of ANSI, it is okay to write this Code. However, if Unicode is defined, this code will receive a compilation error because lstrcpy will be defined as lstrcpyw, the required parameter types are lpwstr and lpcwstr.
Maybe you will say: I have the ability to control my source code and know whether I use lstrcpya or lstrcpyw. Do you need it?
Indeed, this is your freedom, and I will not interfere with your code style, nor question your control over the code.
However, if your code is to be provided to others, and you only provide an interface, or even if this interface crosses the PE boundary, should you always be responsible?
Don't make your ambiguous tchar troublesome for both parties.
---------- The legendary separation line ----------
If I provide you with a. dll and A. h, and the interface definition in this. H is described using tchar, what will happen?
- You can write two sets of Code respectively for a and W to test whether the tchar represents Char or wchar. This is troublesome for you.
- You can directly ask me what tchar represents. This is troublesome for both of us.
So why?