> Thank You. > I see in hbdefs.h: > > /* Include windows.h if applicable and requested */ > #if defined( HB_OS_WIN_USED ) && defined( HB_OS_WIN ) > > #include <windows.h> > #if defined( __GNUC__ ) > #define HB_DONT_DEFINE_BASIC_TYPES > #endif > > But I'am compiling daily minigui extended with mingw and MSVC8. > Problem appeared lately. So my naive solution was to include windows.h > in *.c files. > Anyhow HbQt is responsible for it's Qt include files. > By my logic (I don't have Your deep knowledge of Harbour), any > toolkit should be responsible for it's environment.
You're right in that. But, Harbour uses several C types which collide with Windows types, and until we fix this situation, this hack is - unfortunately - required. The historical reason is that these Windows types were also adopted by Clipper, so we started to use them in Harbour, too. For Clipper this wasn't such a huge problem, since it was MS-DOS based, but for Harbour it is, since it has to interface with virtually anything, among them: Windows. So, the proper fix is on the way, but it's a pretty tough and long process. My BOOL -> HB_BOOL, ULONG -> HB_SIZE fix was on such step. There is still several dozens of thousands of similar lines to fix, plus we will have to deal with compatibility, plus some tougher problems like existing HB_ULONG type. Thus it will still take some time to be able to make that right. To sum it up: The goal is to eliminate all Windows types from portable Harbour code, and make possible #include <windows.h> anywhere, without any interference with any Harbour code. This will also make it possible to build hbfimage on *nix platforms, and avoid any similar problem in the future. > I apreciate Your work very much Thank you. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
