Porting WORKING MFC Application and depricated classes

Hot Topic

Problem xml-serializing Contact object
SP1 Feature :Allow DataGrid cell drawing to be overridden Do’nt work properly with sqlceResultSet as DataSource
Activesync & emulator just won't connect
New to .net CF2 & PPC
VS2005 emulator network connection problems..
Can eVC++ applications also run in desktop WindowsOS's?
Trusted Publisher
DllMain Already defined - linking error
configuring pocket pc 2003 second edition in vs 2005 to test mobile web applications
How can I tell if the user clicked the OK on a form

Smart Device

how to hook a application when it start
VS2005 RC : No Windows Mobile 5, No Win CE 5 Projects with C++
Installation of Compact Framework 2.0 failed. Why?
Can I use Visual Studio 2005 to develop Compaq iPAQ (H3600 series) applications?
How to see a form without the need for events?
How to write a program for barcode scanner MC1000
Handling Null value
WCE 5.0 Test Kit -- Application Verifier Tools Can't Work
Windows Apps & Pocket PC Apps
CameraCaptureDialog

Porting WORKING MFC Application and depricated classes

I am trying rather unsuccessfully to port a WORKING eVC4 MFC application to VS2005 under the Mobile 5.0 SDK.

It would appear that microsoft has dropped some classes from support in the latest version of MFC. The two that are hitting me the hardest right now are CSplitterWnd and CEditView though I assume the CDumpContext is going to come around to be pretty troublesome as well.

Are there replacement classes that we are supposed to use, or are we supposed to rewrite MFC ourselves to make this work

Has anyone successfully overcome these issues that would care to share some strategies




Answer this question

Porting WORKING MFC Application and depricated classes

  • Stephen Solt

    Hi,

    It is true that some of the classes have been dropped from the device MFC libraries shipped with VS2005. Unfortunately there are no replacement classes for them either in the currently shipped versions. As far as the dump context related methods are concerned they need to be dropped from your code- which generally turn out to be the Dump method in the derived classes. This isn't included in any of the MFC classes too. In most cases the only debug method supported is AssertValid.

    Sorry for the inconvenience, but we are trying to come up with some method to help in such migration issues- till then you will need to implement these classes yourself if you need them.

    Thanks.



  • marta

    Well now that the code has been ported, even though it appears to compile it also appears that there is a lot of work ahead to get this to function properly.

    I am now considering suggesting that the client not bother with the upgrade to 5.0 and to remain on the current platform.

    It still makes no sense to me whatsoever that perfectly working code is destroyed by arbitrarily deprecating features that were depended upon. I guess in others' cases the splitter window amounted to somethgin extra, but in this case it was the main interface to our program on close to 10,000 units.



  • glider pilot

    But the question remains, are there any particular strategies that people are employing now to effect this change

    Is it possible that we are the only people trying to port currently working programs to this SDK that actually rely on CEditView and CSplitterWindow



  • Jose Picon

    Well I didn't bother trying to port the old eV4 mfc code, I took the latest code from the 8.0 mfc and ported it. It didn't take a whole lot just a few little changes.

  • IoPi

    Hi,

    Unfortunately for now you will have to create your own splitter window class, but since splitter windows do not conform to the WM UI guidelines ( full screen windows) you can think about having alternative implementations too.

    Thanks

  • Beleebe

    I'm sorry to report that I had the same problem with CSplitterWindow when porting an app from eVC++ 4 to Visual Studio 2005. For some deprecated classes, such as the library of MFC Internet classes that includes CInternetSession, I was able to port code from the MFC source that was part of the eVC++ install. However, CSplitterWindow was so heavily linked to other parts of the old MFC source that it proved to be too much trouble to port. Fortunately, the way in which CSplitterWindow was used in our code was not critical to the app -- each window simply displayed a list, so I just dropped CSplitterWindow altogether and put both lists in a single window. Perhaps you have more patience than I did and could extricate CSplitterWindow from the old MFC source. Good luck.
  • Porting WORKING MFC Application and depricated classes
Answer this question