Re: using structs like BROWSEINFO and OPENFILENAME (string members

first of all.....thanks for the detailed reply. your discussion of unicode
vs ansi reminded me to recheck my typelib and found a couple of errors. i
should explain a couple of things though: PTR is ultimately typedef'd to
long (and i *think* the 'const' keyword that gets applied to LP'C'XSTR types
is valuable only for compile time checking of callee attempted
modifications), and second my VB code does not use a UNICODE #define - the
typelib does so the #if's are in the typelib source.

so here's the first error i found:

[
usesgetlasterror,
#ifdef UNICODE
entry("SHBrowseForFolderW"),
#else
entry("SHBrowseForFolder"),
#endif
helpstring("Displays a dialog that allows selection of shell folders"),
]
LPITEMIDLIST WINAPI SHBrowseForFolder(LPBROWSEINFO lpbi);

i had to do was change the second entry parameter to:

entry("SHBrowseForFolderA"),


the second error was so blatent i'm shocked at myself, i had to fix the
order of structure members as you mentioned.....(doh!).



And as far as maintaining an additional application entity, the typelib, it
is not a problem since our product already has a companion installer that
installs other secondary application components.

Thanks again for the feedback
--nebbish


"Thorsten Albers" wrote:

> nebbish <nebbish@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Beitrag
> <F9610152-553C-4D43-97D1-95A167F2B9BE@xxxxxxxxxxxxx>...
> > PTR /* LPCTSTR */ lpszTitle; // text to go in the banner over the
> tree.
> > PTR /* LPTSTR */ pszDisplayName;// Return display name of item
> selected.
>
> a) Whatever type definition for 'PTR' you are using - it doesn't make much
> sense since the one is LPCTSTR and the other is LPTSTR, i.e. they both are
> different types (even if the difference is a very small one...). Why don't
> you use the 'orginal' types?
>
> b) 'LPCTSTR'/'LPTSTR' to my opinion doesn't make sense for a type library
> to be used in Visual Basic, since you can't set the define UNICODE when
> compiling you VB project (UNICODE defined: LPCTSTR/LPTSTR ->
> LPCWSTR/LPWSTR; UNICODE not defined -> LPCSTR/LPSTR);
> If in your type library you are referring to SHBrowseForFolderA() you
> should use
> LPCSTR lpszTitle;
> LPSTR lpszDisplayName;
> If in your type library you are referring to SHBrowseForFolderW() you
> should use
> LPCWSTR lpszTitle;
> LPWSTR lpszDisplayName;
>
> c) The reason that setting 'lpszTitle' doesn't work presumably is, that you
> have changed the order of the structure members 'lpszTitle' and
> 'lpszDisplayName'; this is the correct structure definition according to
> the PSDK:
>
> typedef struct _browseinfoA {
> HWND hwndOwner;
> LPCITEMIDLIST pidlRoot;
> LPSTR pszDisplayName; // Return display name of item
> selected.
> LPCSTR lpszTitle; // text to go in the banner
> over the tree.
> UINT ulFlags; // Flags that control the
> return stuff
> BFFCALLBACK lpfn;
> LPARAM lParam; // extra info that's passed
> back in callbacks
> int iImage; // output var: where to
> return the Image index.
> } BROWSEINFOA, *PBROWSEINFOA, *LPBROWSEINFOA;
>
> typedef struct _browseinfoW {
> HWND hwndOwner;
> LPCITEMIDLIST pidlRoot;
> LPWSTR pszDisplayName; // Return display name of item
> selected.
> LPCWSTR lpszTitle; // text to go in the banner
> over the tree.
> UINT ulFlags; // Flags that control the
> return stuff
> BFFCALLBACK lpfn;
> LPARAM lParam; // extra info that's passed
> back in callbacks
> int iImage; // output var: where to
> return the Image index.
> } BROWSEINFOW, *PBROWSEINFOW, *LPBROWSEINFOW;
>
>
> > i even tried some other memory allocation api funcs like GlobalAlloc and
> > CoTaskMemAlloc. still no joy. (i think they all use the same heap
> anyway -
> > i'm 70% confident about that)
>
> There is no difference between LocalAlloc(), GlobalAlloc() and, e.g., Dim
> abData(0 to 9) As Byte. You shouldn't use CoTaskMemAlloc().
>
> > *but* this requires
> > api declarations which i am trying to eliminate by using the typelibrary.
>
> Why? What is better in using a type library then using Declare statements?
> Using a type library makes it necessary to take care of at least one more
> additional file. When transferring you VB project to another computer you
> have to take care that the type library is transferred as well - also it is
> not part of the VB project. This external dependency IMHO should be
> avoided.
>
> > i am intensly curious about the details
> > of passing memory pointers back and forth between VB & the API and why
> the
> > two members of the struct seem to behave differently.
>
> The different behaviour results from the different data type: While the one
> is declared as string, the other is declared as long. While the one holds a
> real string pointer which for VB indeed is a string pointer, the other
> holds a long value which in fact is a pointer to memory where string data
> have been stored. VB doesn't anything about the latter, for VB it always is
> just a long value, nothing more.
> Strings in VB are handled a bit different than the other data types in that
> they may be internally converted from Unicode to ANSI or vice-versa. I.e.
> when a string parameter is passed to an external function in a non-VB
> library, the original OLE unicode string (VB uses OLE Unicode strings) is
> converted internally to an ANSI string. If an external function in a non-VB
> library etc. passes a string parameter to VB, the string is assumed to be
> an ANSI string and is converted internally by VB to an OLE Unicode string.
> This only happens if VB knows that the passed parameter is a string, i.e.
> if it is declared "As String".
> This is due to the fact, that VB 32 bit originally was designed for
> platforms with no or with very restricted Unicode support, i.e. where the
> Windows API uses ANSI strings and doesn't provide function ("W") versions
> which are able to handle Unicode strings.
>
> --
> Thorsten Albers
> Albert-Ludwigs-Universität Freiburg
> albers@
> uni-freiburg.de
>
.

Relevant Pages

  • Re: Error 52 Bad file name or number on file read
    ... Sorry Nick but if you're ending up with a mixture of ANSI and Unicode data ... Private Type FILETIME ... Public Function StripNulls(sText As String) As String ...
    (microsoft.public.vb.general.discussion)
  • Re: Did Borland doing well in Q4? Listen to the Earning CC
    ... AS an ANSI application you will need to change all "String" ... declarations to "ANSIString" (and Char to ANSIChar and PChar to ... Only THEN can you start thinking about how Unicode is best ... Even the specifically "ANSI" FS routines do not use ...
    (borland.public.delphi.non-technical)
  • Re: api call for tchar*
    ... > String passes an ANSI version while a ByRef passes a Unicode version. ... The row of characters is preceded by a Long ...
    (microsoft.public.vb.winapi)
  • Re: length checking...
    ... ANSI string. ... Win9x is dead, so all apps are becoming NT-only, which means - no reasons ... Unicode is much simpler then ANSI, and I would recommend Unicode for beginners ...
    (microsoft.public.development.device.drivers)
  • Re: Tranfering unicod charcters in Socket programming!
    ... You are telling about conversion b/w MBCS to Unicode. ... If this is not possible Shall I try with string to wstring ... int SendStringAsUnicode ...
    (microsoft.public.win32.programmer.networks)