Opened 9 months ago

Closed 9 months ago

Last modified 9 months ago

#15579 closed defect (fixed)

__WXMSW__ incompatible change

Reported by: StuRedman Owned by:
Priority: normal Milestone: 3.0.0
Component: build Version: 3.0.0-rc1
Keywords: Cc: kolya.kosenko@…
Blocked By: Blocking:
Patch: no

Description

Documentation wx 2.8:
WINDOWS any Windows, yom may also use WXMSW
WXMSW Any Windows

Documentation wx 3.0rc1:
WINDOWS Any Windows platform, using any port (see also WXMSW)
WXMSW GUI using Windows Controls

So in a Windows command line application WXMSW is defined in 2.8 (and 2.9) and undefined in 3.0 .

This caused some hair-pulling for me trying to build aMule with 3.0 rc1 as you may imagine. Especially since WXMSW is first defined in the header and later undefined.

Any command line application using WXMSW in the 2.8 way (as synonym for "Windows") breaks badly with 3.0 rc1 and requires lots of changes. So I suggest you revert this change. If you don't please document it in a prominent place (switch this to documentation defect).

Change History (6)

comment:1 Changed 9 months ago by StuRedman

wiki formatting makes this ticket hard to read. Underline here means "surrounded with "

comment:2 in reply to: ↑ description Changed 9 months ago by kosenko

  • Cc kolya.kosenko@… added
  • Component changed from wxMSW to documentation
  • Milestone set to 3.0

__WXMSW__ is not defined in wxBase because this sub library is designed to be toolkit independent and should be able to work with other ports like wxGTK2/Win32 (__WXGTK__) and theoretical wxWinRT under Windows.

Any command line application using WXMSW in the 2.8 way (as synonym for "Windows") breaks badly with 3.0 rc1 and requires lots of changes.


No, you just need to add in your console application:

#if defined (__WINDOWS__) && !defined(__WXMSW__)
#define __WXMSW__
#endif

Or just change all __WXMSW__ with __WINDOWS__ using grep or search.

If you don't please document it in a prominent place (switch this to documentation defect).


Yes, I think documentation change would be better.

comment:3 Changed 9 months ago by vadz

  • Component changed from documentation to build
  • Status changed from new to confirmed

I did agree to this change myself, but thinking about it more now, I think we should revert it. The initial idea was to detect (wrong) uses of __WXMSW__ in wxBase code. But this could be achieved by undefining __WXMSW__ for wxBase compilation only. So I'm going to apply this:

  • include/wx/platform.h

    diff --git a/include/wx/platform.h b/include/wx/platform.h
    index 53b04e5..97c669f 100644
    a b  
    9595#   endif 
    9696#endif /* __WINDOWS__ */ 
    9797 
    98 /* Don't use widget toolkit specific code in non-GUI code */ 
    99 #if defined(wxUSE_GUI) && !wxUSE_GUI 
     98/* 
     99    Don't use widget toolkit specific code in non-GUI code in the library 
     100    itself to ensure that the same base library is used for both MSW and GTK 
     101    ports. But keep __WXMSW__ defined for (console) applications using 
     102    wxWidgets for compatibility. 
     103 */ 
     104#if defined(WXBUILDING) && defined(wxUSE_GUI) && !wxUSE_GUI 
    100105#   ifdef __WXMSW__ 
    101106#       undef __WXMSW__ 
    102107#   endif 

if there are no objections.

comment:4 Changed 9 months ago by kosenko

This should work for backward compatibility, but wx-users could wrongly thought that GUI code (__WXMSW__) is used somehow in their console applications.

comment:5 Changed 9 months ago by VZ

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [75006]) Don't undefine WXMSW for console mode applications using wxWidgets.

This partially undoes the changes of r73290 by keeping WXMSW defined for
the console mode user applications and only undefining it when building
wxWidgets itself.

This allows the existing code using WXMSW to continue compiling correctly
with wxWidgets 3.0.

Closes #15579.

comment:6 Changed 9 months ago by StuRedman

Thank you!
Defining __WXMSW__ myself was my first thought too, but I wouldn't do that, since I don't know what that might break in the included wx headers.
I agree that replacing it with __WINDOWS__ is the right step. Still, it is not equivalent, since __WINDOWS__ might be defined who-knows-where while __WXMSW__ clearly means "wxWidgets is active". I admit, I didn't even know there is something like wxGTK2/Win32.

Note: See TracTickets for help on using tickets.