Re: [AD] trying to make allegro compatible with MFC

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> > what do you think?
> > is this good enough?
>
> I found some problems with your new winalleg.h:
> - the WINDOWS_RGB trick doesn't work (MinGW32):  c = WINDOWS_RGB(0,255,0)
> gets expanded as c = RGB(0,255,0) and gcc obviously produces a parse
error.
> Why not simply copy the Windows RGB macro into winalleg.h ?
for me it is ok

> - same thing for ALLEG_TRACE and ALLEG_ASSERT,
sorry, i was using MSVC so i was not aware of it

> - you have moved #include <windows.h> out of the scope of the extern "C"
> declaration.
yes, but that is purpose, since in any way windows.h is just C code (and the
afxwin.h header cannot be inside the extern "C" for obvious reasons)
you can make windows.h inside extern "C" if you want though, just making
sure you dont include afxwin.h inside this scope

> About #define WIN32_LEAN_AND_MEAN: on the K6-III 400Mhz I have here,
> removing the define causes the compilation time for the Windows-specific
> source files to be increased from 1'50" to 2'20". So I think we should
keep
> it for the library build:
> #ifdef ALLEGRO_SRC
>    #define WIN32_LEAN_AND_MEAN
> #endif
right

> About #define NO_STRICT: it seems this flag can conflict with the Win32
API
> call DialogBox() (see the "Allegro and custom WinMain()" thread on [AL]).
> Removing it causes a little compilation warning to be issued by gcc for
> wsndwo.c, that is very easy to fix. I think we should get rid of this
> define.
Yes, it causes some problems with END_OF_MAIN()
but if you say they can be avoided i'm 100% for it



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/