WinCE.NET compilation/link fix

[wxtrac]

Issue migrated from trac ticket # 9014

component: wxMSW-CE | priority: normal

2008-02-13 13:02:32: magneticore created the issue

---

WinCE 5 Unicode Visual C++ 2005

When the define __WINCE_NET__ is used to build WinCE.NET application, some libraries are missing to link correctly, and some defines must be set into setup to compile correctly (Unicode is on).

In setup.h, if wxUSE_MINIFRAME is not set to 1, compilation fails.

Files modified by patch to correct these problems: include\wx\msw\wince\library.h include\wx\msw\wince\setup.h

[wxtrac]

2008-02-13 13:02:32: magneticore uploaded file WinCE_NET.patch (1.6 KiB)

Diff SVN patch

[wxtrac]

2008-02-21 12:37:49: @vadz commented

---

Sorry, what is __WINCE_NET__ and who defines it?

As for wxUSE_UNICODE it really should be already defined (as 1) already (at least in the svn trunk).

Also, we clearly should fix the compilation with wxUSE_MINIFRAME==0 instead of forcing it to 1, what errors did you get exactly?

[wxtrac]

2008-02-25 11:51:33: magneticore commented

---

Hello,

Sorry, what is __WINCE_NET__ and who defines it?

__WINCE_NET__ is defined by wxWidgets in setup.h (include\wx\msw\wince\setup.h) for WinCE if _WIN32_WCE >= 0x400 (WinCE version).

_WIN32_WCE must be defined in preprocessor definitions under Visual C++ project when it is used to build applications for some industrial PCs or mobile device equiped by WinCE.NET, as follow: _WIN32_WCE=$(CEVER) and CEVER is in my case 0x500 (WinCE 5) defined by the SDK and platform build.

Note: in my case, the following terms are not defined: POCKETPC SMARTPHONE

An industrial PC with WinCE can have a standard screen of 800x600 or ever better, with windows menus, etc.

As for wxUSE_UNICODE ... Unicode is off in setup.h for WinCE in 2.8.7, but platform.h undefines it and defines as on if _UNICODE or UNICODE is defined, and Visual C++ defines _UNICODE and UNICODE as 1. But it would be better to define wxUSE_UNICODE as 1 by default under WinCE.

Also, we clearly should fix the compilation with wxUSE_MINIFRAME==0 instead of forcing it to 1, what errors did you get exactly?

This happens in: include\wx/aui/floatpane.h

exactly here in the file: ....

if wxUSE_AUI

include "wx/frame.h"

if defined( WXMSW ) || defined( WXMAC ) || defined( WXGTK )

include "wx/minifram.h"

define wxAuiFloatingFrameBaseClass wxMiniFrame

else

define wxAuiFloatingFrameBaseClass wxFrame

endif

class WXDLLIMPEXP_AUI wxAuiFloatingFrame : public wxAuiFloatingFrameBaseClass ....

The compiler tries to use wxAuiFloatingFrameBaseClass defined as wxMiniFrame, because WXMSW is defined. But wxMiniFrame is not declared because wxUSE_MINIFRAME is set as 0.

Note: I have not tested to see if wxAui can work under industrial WinCE, but there is no reason that it does not run, since it is possible to move windows and to have floating windows under industrial WinCE.

[wxtrac]

2008-02-25 18:15:45: magneticore commented

---

Sorry for the mistake, but __WINCE_NET__ is defined by wxWidgets in platform.h file (include\wx\platform.h) for WinCE if _WIN32_WCE >= 0x400 (WinCE version).

[wxtrac]

2008-02-27 18:34:29: @vadz commented

---

Thanks for the explanations!

I've fixed (blindly but the fix is really simple so hopefully it should work fine) wxUSE_MINIFRAME problem and applied the part of the patch adding __WINCE_NET__ checks (in a slightly modified form, please let me know if I broke anything). I still don't see any compelling reason to modify setup.h though as everything still seems to work correctly without this change so I didn't do it.

BTW, if you can provide a build slave (for our buildbot) for non-{PocketPC,Smartphone} WinCE builds, it would be great, as AFAIK nobody of the main developers uses this platform and so it risks to get broken without it. TIA!