WxWidgets For MFC Programmers

First, look at Compiling A WxWidgets Application to see what you need for your new project settings.

If you plan to use both MFC and wxWidgets (and are using stdafx.h), make sure to have "include <wx/wx.h>" above the MFC include lines. Otherwise, you may get errors about a "constant" in the CreateDialog function.

Unlike MFC's CString::Format function, the wxString::Format function is a static member function. This means that calling "myStringInstance.Format(...)" will return the formatted text in a new wxString rather than change the string in the myStringInstance variable. You might be able to get away with a search and replace of ".Format(" to " = wxString::Format(" or ".Printf(" when porting your application.

There is a guide for porting an MFC application to wxWidgets. See Porting MFC applications to Linux.

[hide]

Dialog Data Handling

First, forget about MFC's DDX/DDV macros. wxWidgets takes a more object-oriented approach with wxValidators. The help is very good on the topic of wxValidators. Just remember that wxTextValidator works for wxTextCtrls and wxGenericValidator works for just about everything else.

Second, no more having to remember if you want to send TRUE or FALSE to the UpdateData Function. The function names TransferDataToWindow and TransferDataFromWindow are clear enough.

If you have a problem with errors when transferring data between the variables and the window, try changing the data type of the variable. BOOL and bool aren't the same and might cause you issues.

Finally, a pitfall that might come up with radio buttons. wxGenericValidator will connect an integer variable with a wxRadioBox, but NOT with a wxRadioButton. You can only connect a bool variable with a wxRadioButton. If your radio buttons are spaced out with controls in between them (possibly other controls that go with a particular radio button), you'll need to use a wxRadioButton rather than a wxRadioBox. Unfortunately, this may cause large code changes if you had an integer associated with these.

Associating HWNDs with wxWindow Instances

From a recent discussion on the comp.soft-sys.wxwindows newsgroup (searchable via http://groups.google.com), here is an easy way to associate a Win32 HWND (hWnd) with a wxWindow instance:

  wxWindow * win = new wxWindow();
  win->SetHWND((WXHWND)hWnd);
  win->AdoptAttributesFromHWND();
  win->Reparent(wxGetApp().GetTopWindow());

OnInitDialog

A common thing to do in MFC is add some dialog initialization code in the OnInitDialog message handling function. wxWidgets allows this as well with the EVT_INIT_DIALOG message and the wxInitDialogEvent event class. The documentation mentions this under the topic wxInitDialogEvent, but none of the samples demonstrate using this functionality. Your OnInitDialog function should fit the following declaration:

  void MyDialog::OnInitDialogFunction(wxInitDialogEvent& event)

The key point is the wxInitDialogEvent parameter. If you use no parameters, the code will work fine in Debug mode but crash in Release mode (this experience was using VC 6.0 SP4).

wxWidgets and MFC Functions with the Same Name but Different Functionality

wxListBox::FindString is equivalent to CListBox::FindStringExact rather than CListBox::FindString. CListBox::FindString looks for list box entries "prefixed" with the search string rather than exact matches. I don't believe that wxWidgets has a function equivalent to CListBox::FindString.
As mentioned previously, wxString::Format is a static wxString member that returns a modified wxString, where CString::Format actually affects the CString instance that calls it.

wxWidgets and MFC DC Differences

A common error in MFC code is not restoring the original CDC brush, pen, or font after changing them with the CDC::SelectObject function. In wxWidgets, this problem doesn't exist since the restoration of the original brush/pen/font is taken care of by wxWidgets itself.

So You are About to Convert Your MFC Application

Change all your

ASSERT() to wxASSERT()
TRACE to wxLogDebug()
CString to wxString
MyString.GetLength() to MyString.Length()
MyString.Format("Some number %i", x) to MyString.Printf( "Some number %i",x)

Dialog Pitfalls

If you are taking the opportunity to change your MFC dialogs to use sizers, have a look at the advice on the wxSizer page first.

TRACE Pitfall

If instead of using wxLogDebug you change your TRACE to wxLogTrace() some will work, some will fail to show. Why? Because wxLogTrace is polymorphic and if you do something like wxLogTrace("Filename is: %s", pFilename), the first two arguments are char* so the compiler happily matches this up with the wxLogTrace variant with prototype wxLogTrace(const wxChar *mask, const wxChar *szFormat, ...). Oops!

Format Pitfall

Your use of Format will compile happily and do sweet FA if you don't make the change shown above. In wxWidgets wxString::Format does not change the string in place, instead it is a static function that returns the formatted string.

Changing Icon Formats

You may want to switch over to using xpm (X PixMap) format for all your smaller bitmaps and icons. ImageMagick (GPL) includes a command line utility with a nice convert function that handles xpm and it is available in both a Windows and a Linux version.

Class Translation Table

Here's a list of most MFC classes and their wxWidgets counterparts. (wxWidgets headers need to be prefixed with wx/):

(TODO: Put all classes from here)

MFC	wxWidgets	Header	Comments
CAnimateCtrl	wxMediaCtrl	mediactrl.h
CArchive			No Serialization in wxWidgets.
CArchiveException			No Exceptions in wxWidgets.
CArray	wxArray	dynarray.h	Requires macros and arrimpl.cpp.
CAsyncMonikerFile	??wxFile??
CAsyncSocket	??wxSocketBase??
CBitmap	wxBitmap	bitmap.h
CBitmapButton	wxBitmapButton	bmpbuttn.h
CBrush	wxBrush	brush.h
CButton	wxButton	button.h
CCachedDataPathProperty			No support in wxWidgets(?).
CCheckListBox	wxCheckListBox	checklst.h
CClientDC	wxClientDC	dc.h
CCmdTarget	wxEvtHandler	event.h	wxEvtHandler is probably the most fitting counterpart.
CCmdUI	???
CComboBox	wxComboBox
CComboBoxEx			wxComboBox does not support images
CCommandLineInfo	wxCmdLineParser
CCommonDialog	wxDialog
CCriticalSection	wxCriticalSection	thread.h
CDialog	wxDialog	dialog.h
CDatabase	wxDb	db.h
CDC	wxDC	dc.h
CEdit	wxTextCtrl	textctrl.h
CEditView	wxTextCtrl	textctrl.h	Use wxTextCtrl inside wxView, see IBM developerWorks "Porting MFC applications to Linux"
CEvent	wxCondition	event.h
CFile	wxFile	file.h	Wrapper around unix functions.
CFileStatus	wxFSFile	filesys.h	Part of wxFileSystem
CFrameWnd	wxFrame	frame.h
CImageList	wxImageList
CList	wxList		Macro based.
CListBox	wxListBox		Macro based.
CMap	wxHashMap		wxHashMap is unsorted - for sorted values use wxMap instead[1]
CMapPtrToPtr	wxHashMap		wxHashMap is unsorted - for sorted values use wxMap instead[1]
CMapPtrToWord	wxHashMap		wxHashMap is unsorted - for sorted values use wxMap instead[1]
CMDIChildWnd	wxDocMDIChildFrame	docmdi.h
CMDIFrameWnd	wxDocMDIParentFrame	docmdi.h
CMenu	wxMenu	menu.h
CMenuItemInfo	wxMenuItem	menuitem.h
CMultiDocTemplate	wxDocTemplate	docview.h
CMutex	wxMutex	thread.h
CObject	wxObject	object.h
COleDropSource	wxDropSource
CPen	wxPen
CPropertySheet	wxNotebook
CRecentFileList	wxFileHistory
CRect	wxRect	gdicmn.h
CSemaphore	wxSemaphore	thread.h
CSpinButtonCtrl	wxSpinButton		Portable programs: use wxSpinCtrl instead
CStatic	wxStaticText
CTime	wxDateTime
CTreeCtrl	wxTreeCtrl	treectrl.h
CTreeView			No support in wxWidgets(?).
CTypedPtrArray			No templates in wxWidgets, needs C++ compiler support.
CTypedPtrList			No templates in wxWidgets, needs C++ compiler support.
CTypedPtrMap			No templates in wxWidgets, needs C++ compiler support.
CUserException			No exceptions in wxWidgets.
CUIntArray	wxArrayUint	dynarray.h
CView	wxView	docview.h
CWaitCursor	wxBusyCursor	cursor.h
CWindowDC	wxWindowDC	dcclient.h
CWinThread	wxThread	thread.h	Main thread only for GUI routines in wxWidgets
CWnd	wxWindow	window.h
CWordArray	wxArray	dynarray.h	wxArrayShort on 32-bit platforms, etc.

[1] - wxMap is an unofficial user contribution - see this forum thread for the source.

clq

公告