MS Visual Studio 2005: Why Be Bothered with It?
With the release of MS Visual Studio 2005 last November, Windows Mobile 5.0 at the very end of its beta cycle, and a proliferation of WinCE 5.0-powered devices, it is time to commence considering to move your C/C++ mobile applications from eMbedded Visual C++ to the new development environment. You can reasonably ask why you should do it at all and battle new headaches if you still can continue to use existing developing tools and libraries. In my opinion, there are serveral reasons that could cause you to think it over seriously right now. I will leave aside the features of the IDE itself and discuss the pros and cons with a developer's vision.Porting Possibilities
If you have an existing eVC project and want to import it into VS 2005, you have two options. One is to use eVC Upgrade Wizard add-on for VS 2005, which is available for download from Microsoft's site here. If you take a look at the bottom part of this page, you will see a notice that this is an unsupported addon, so you have a good chance to experience some problems with it. Nevertheless, it may help you migrate your project easily enough. You might be required to adjust some of the project settings—for example, a way of MFC usage—but usually they are really minor ones.The second way is to create a brand new solution and projects and then manually add all files. It looks more a more difficult method, but in some cases this is the only thing to do because you can get the standard header files and project settings. This allows you to avoid some weird warnings and problems during solution compilation and linkage. Links at the end of this article may help you get more details.
Whichever way you use, now you have your application available under the MS Visual Studio 2005 IDE.
Benefits and Issues
C/C++ projects support and emulators
First of all, VS 2005 comes with support for native C/C++ projects and new emulators for smart devices. If you have had the chance to code really large mobile projects with millions of code lines, you will agree that it was almost impossible to use SDK emulators from eVC 3.X or 4.X. They are slow, they are not robust, they are... This left only one alternative to a developer: to use the old Palm-Size 2.11 emulator. It obviously made a serious impact on such applications. With new emulators, you can get rid of the old dragon. Not only that it is fast enough, but also is able to execute the code compiled for real devices, which is a nice capability. Thus, your application will look and behave more like its real instance on the handheld.Native device C/C++ projects support hasn't came for free. Microsoft made many additions to the C++ compiler ever since VS 2003 in comparison with eVC++, and the new Studio also keeps pace. It results in many tiny but annoying compiler errors like the following case:
//The second for statement will generate an 'undeclared variable' error. I haven't yet seen any C++ programmer who would write the above code in C-style.
for (int i = 0; i < nCount; i++)
{
...
}
...
for (i = 0; i < nCount2; i++)
{
...
}
int i = 0;so you may evaluate a number of possible changes here. You will find additional info regarding new C/C++ compiler features among the links at the end of the article.
...
for (i = 0; i < nCount; i++)
{
...
}
...
for (i = 0; i < nCount2; i++)
{
...
}
Moving Forward to MFC 8.0
If your application uses the MFC library for Windows CE, you can expect many surprises as well, and they are not always pleasant. Version 8 of MFC and ATL were significantly changed since previous MFC 3.0 times. Some changes were expected, for instance, new string classes, but other ones I honestly can't get. Just take a look at the following list of unsupported classes (you can get full info here):- CSplitterWnd
- CDialogBar
- CReBar
- CColorDialog
- CFindReplaceDialog
- CFontDialog
- CPrintDialog
- COlePropertyPage
- CEditView
- CBitmapButton
- CReBarCtrl
- CSocketFile
- CInternetFile
- CHttpFile
- CLongBinary
- CInternetSession
- CInternetConnection
- CHttpConnection
- COleSafeArray
- CPrintInfo
- COleCmdUI
- CDAOFieldExchange
- CDBVariant
- CFieldExchange
- COleDataObject
- CRecentFileList
- COleCurrency
But this is not the end of the story. Far from it! If you will examine the MFC headers, you can find a lot of code similar to the following snippet:
class CFont : public CGdiObjectOnce again, I appreciate the new MFC version. It required improvements, but this and similar differences may hurt your application badly. As the best case, you can inherit your own class—say, CMyFont—that implements a lack of functions:
{
DECLARE_DYNAMIC(CFont)
public:
static CFont* PASCAL FromHandle(HFONT hFont);
// Constructors
CFont();
BOOL CreateFontIndirect(const LOGFONT* lpLogFont);
#ifndef _WIN32_WCE // Unsupported Win32 API call
BOOL CreateFont(int nHeight, int nWidth, int nEscapement,
int nOrientation, int nWeight, BYTE bItalic,
BYTE bUnderline, BYTE cStrikeOut, BYTE nCharSet,
BYTE nOutPrecision, BYTE nClipPrecision,
BYTE nQuality, BYTE nPitchAndFamily,
LPCTSTR lpszFacename);
#endif // !_WIN32_WCE
...
};
class CMyFont : public CFontbut this is not always feasible. Be ready for the black box job, folks!
{
public:
// Constructors
CMyFont();
BOOL CreateFont(int nHeight, int nWidth, int nEscapement,
int nOrientation, int nWeight, BYTE bItalic,
BYTE bUnderline, BYTE cStrikeOut, BYTE nCharSet,
BYTE nOutPrecision, BYTE nClipPrecision,
BYTE nQuality, BYTE nPitchAndFamily,
LPCTSTR lpszFacename)
{
LOGFONT lfFont;
memset(<lfFont,0,sizeof(lfFont));
lfFont.lfHeight = nHeight;
lfFont.lfWidth = nWidth;
lfFont.lfWeight = nWeight;
lfFont.lfEscapement = nEscapement;
lfFont.lfOrientation = nOrientation;
lfFont.lfWeight = nWeight;
lfFont.lfItalic = bItalic;
lfFont.lfUnderline = bUnderline;
lfFont.lfStrikeOut = cStrikeOut;
lfFont.lfCharSet = nCharSet;
lfFont.lfOutPrecision = nOutPrecision;
lfFont.lfClipPrecision = nClipPrecision;
lfFont.lfQuality = nQuality;
lfFont.lfPitchAndFamily = nPitchAndFamily;
_tcscpy(lfFont.lfFaceName,lpszFacename);
return CreateFontIndirect(&lfFont);
}
0 nhận xét:
Đăng nhận xét