🚀 go-pugleaf

Files built for Win 98SE and below will show a smaller size for the
OPENFILENAME structure.  For instance on my XP machine the size is 88 bytes
and the OpenFileName call works well.  It doesn't work on my wife's Win98SE
machine because it uses the style and size of that structure consistent with
later versions of Windows.

So put these in the Defines box as a macro:
_WIN32_WINNT=0x400
WINVER=0x400

That should change it from the 0x500 that it defaults to and should cause
the Windows header files to expand with the older, smaller size for the
structure.  When the GetOpenFileName structure sees the smaller size in the
newer Windows versions it should know how to handle it and the old versions
only know how to work with the older size.

For when you use the command line tools add these lines to the end of the
bcc32.cfg file that is in the compiler's BIN directory.

-D_WIN32_WINNT=0x400
-DWINVER=0x400

Borland C++ 5.02 is from 1997 so is too old to reflect the changes in
Windows 2000 and beyond.

.  Ed

> John Berg wrote in message
> news:3eade901$1@newsgroups.borland.com...
>
> I'm building a pure API application with C++ Builder6.  The
> 'sizeof' function returns a value of 88 bytes for the
> OPENFILENAME structure, which causes a
> CDERR_STRUCTSIZE error and prevents the Open
> common dialog box from appearing.  Apparently the correct
> size is 76 bytes.  When this is coded directly into lStructSize
> the dialog box appears just fine.  Same code under Borland
> C++ 5.02 works OK, as 'sizeof' returns the value of 76.  What's
> wrong with Builder6?

"Ed Mulroy [TeamB]" <ed@mulroyREMOVETHESECHARS.org> wrote in message
news:3eadef87@newsgroups.borland.com...

> So put these in the Defines box as a macro:
> _WIN32_WINNT=0x400
> WINVER=0x400
>
> That should change it from the 0x500 that it defaults to
> and should cause the Windows header files to expand
> with the older, smaller size for the structure.

Also, just an FYI, you can alternatively use the OPENFILENAME_NT4 structure
instead of OPENFILENAME.  That way, you don't have to alter _WIN32_WINNT or
WINVER, which effect the entire API as a whole.  By using OPENFILENAME_NT4,
you'll be using the same structure that Win98 expects, as it doesn't include
any of the extra fields that OPENFILENAME has for newer OSes.  In fact,
that's why the API has OPENFILENAME_NT4 in the first place - for backwards
compatibility.


Gambit

"Remy Lebeau \(TeamB\)" <gambit47@yahoo.com> wrote:
>
>"Ed Mulroy [TeamB]" <ed@mulroyREMOVETHESECHARS.org> wrote in message
>news:3eadef87@newsgroups.borland.com...
>
>> So put these in the Defines box as a macro:
>> _WIN32_WINNT=0x400
>> WINVER=0x400
>>
>> That should change it from the 0x500 that it defaults to
>> and should cause the Windows header files to expand
>> with the older, smaller size for the structure.
>
>Also, just an FYI, you can alternatively use the OPENFILENAME_NT4 structure
>instead of OPENFILENAME.  That way, you don't have to alter _WIN32_WINNT or
>WINVER, which effect the entire API as a whole.  By using OPENFILENAME_NT4,
>you'll be using the same structure that Win98 expects, as it doesn't include
>any of the extra fields that OPENFILENAME has for newer OSes.  In fact,
>that's why the API has OPENFILENAME_NT4 in the first place - for backwards
>compatibility.
>
>
>Gambit
>
>
The Defines worked just fine; as you surmised I'm running under
Win98SE.  Will also try the OPENFILENAME_NT4 approach.

Thanks!

I had been calling GetVersionEx to see if it's in the NT line and version 5
or better, using sizeof(name) or 76 for the size depending upon the result.
What you show is a nice, clean way to do it.  Good trick - that's a keeper!

.  Ed

> Remy Lebeau wrote in message
> news:3eadf778$1@newsgroups.borland.com...
>
> Also, just an FYI, you can alternatively use the
> OPENFILENAME_NT4 structure instead of
> OPENFILENAME.  That way, you don't have to alter
> _WIN32_WINNT or WINVER, which effect the entire
> API as a whole.  ...