Mandelbrot

Hi Everyone,


I'm trying to find details on the GetOpenFileNameW (Unicode version of GetOpenFileNameA) API, but can't seem to find any anything solid on the net. I'd be very grateful if anyone who has examples could post them for me.

I've tried changing my own code, but the boxes come out as gibberish (obviously the change from ANSI to Unicode), so I must be missing something somewhere.


Thanks in advance,
Paul.

avinash

Please post some code that you have written using GetOpenFileNameA. I will try changing it so that it uses GetOpenFileNameW.

Mandelbrot

Do you have the actual structures required to use this API? That's basically all I need. If you could post this for me, I would be really grateful.


TIA,
Paul.

OnErr0r

The difference is the OPENFILENAMEW structure used by GetOpenFileNameW. Since VB will attempt to convert the strings to ansi, you should use As Long instead of As String for all the string fields. Call lstrLenW on the returned pointer and RtlMoveMemory into a string.

When passing unicode strings TO the function you can simply pass StrPtr(myString) for the long field.

Mandelbrot

Excellent!

Thanks, OnErr0r - that answers the question perfectly.

I did actually see code elsewhere, written as C++, but using longs, and I couldn't understand why.

I'll take a look at that and post the resultant code.

Mandelbrot

Just one last question - I take it the integers (nFileOffset and nFileExtension) are retained as integers?

Squirm

Yes.

Mandelbrot

Thanks for all your help, guys

avinash

If a datamember of the structure is a string buffer, which is filled by the API, then in UNICODE, change the datatype to Byte. I have tried that for some other APIs, e.g., FindFirstFile, which takes Win32_Find_Data as parameter. If, in Ascii, the string buffer has some maximum size, then in Unicode make the size as double of that. Example: In Ascii, if it is a string buffer of 255 characters, in Unicode make it a byte array of 255 * 2 bytes.

There is one thing that surprises me regarding OpenFileName. One member of the structure is lpStrFile. Its type is String. But it is filled up by the API. Then, why is it not a buffer. e.g. lpStrFile As String * 255? Any clue?
Thanks

Mandelbrot

Ahhhh! I've just seen where the code's actually going wrong! The author of the code I've got has only defined a buffer size of 256 characters (lpStrFile). I'll increase this a little, and that should solve my problems without having to resort to memory management!

<Mandelbrot slaps forehead>

Avinash - thanks for that little nudge there! LOL!

avinash

Are you developing some Internationalization software?

Mandelbrot

No, Avinash - all of the previous apps I've developed have only ever required a single filename, in which case I've never noticed the size of the buffer. When I started using OFN_ALLOWMULTISELECT I hit the problem that the string wasn't long enough (i.e. the common dialog was feeding back a buffer overflow). I decided to look into it, and found that the GetOpenFileNameW had a huge string space without actually checking why the buffer was overflowing in the first place...