On Thursday, 20 April 2023 at 15:15:49 UTC+1 Albrecht Schlosser wrote:
OK, great that you found this. I agree that we could do this and
have two notes:
(1) We probably don't need '#ifdef _WIN32' because this file is only
compiled under Windows anyway (we also include <windows.h> and
more).
True - I typed that out of force of habit, but this file *must* be WIN32 anyway so it's redundant here.
(2) I checked that 'SHGFP_TYPE_CURRENT == 0', hence we could replace
the constant (name) with 0 and add a comment which would have the
same effect.
Ian, can you please try option (2) just to be sure?
Yes, this seems fine too.
I checked, and (at least under mingw32) the enum explicitly sets the value to zero:
typedef enum {
SHGFP_TYPE_CURRENT = 0,
SHGFP_TYPE_DEFAULT = 1,
} SHGFP_TYPE;
So hard-coding it as zero would work here - though we'd probably need to add a comment that said the zero was meant to be SHGFP_TYPE_CURRENT I suppose.
That said, I do wonder if the issue is more to do with the
mingw32 headers than with fltk per se.
I'm not convinced that enum definition should be guarded by
the _WIN32_IE macro check at all...
It's presumably done because these constants/functions didn't exist
in versions older than '0x0500' which is IIRC Win XP or something
like that.
Yes, something like that, though this is the _WIN32_IE macro (IIRC, the installation of IE brought with it a load of dll changes to add new functionality that only later found their way into the OS core...)
The XP / Vista /Win7 versioning is mainly covered by the _WIN32_WINNT macro instead, and in that case I think 0x0501 means XP...
I have No Idea what 0x0500 means in terms of the IE versions though!
I note that shlobj.h has a lot of conditionally defined sections, using various MS macros (_WIN32_WINNT, _WIN32_IE, UNICODE, COBJMACROS, possibly others) and I'm not sure the mingw32 toolchain actually sets *any* of these by default!
How old are your MinGW header files? Maybe they are too old to
"know" about these features?
So I looked - I have a couple of mingw32 versions on this machine, one has the mingw32 files versioned as 5.0.2, the newer one has 5.3.0.
Both do define the necessary enum, but both have the conditional guard around the definition.
FWIW, I note that my mingw64 headers are versioned as 4.0.0 (they number it differently from the mingw32 folks though) but does not have the conditional guards around the enum declaration, so it "just works" as a result.
Anyway, we should try to fix this in one or the other way. The
cleaner solution would probably be to define the constant as you
suggested in your workaround.
