April 2000
Your feedback helps us give you the most useful features. Visit our Website for Microsoft® Windows® CE tools at http://www.microsoft.com/windows/embedded.
To locate material in these Release Notes, select one of the general categories under Contents, or choose Find from the Edit menu of the browser.
Platform and Processor Support
The list of processors and platforms supported by this release of eMbedded Visual C++ (see the Platform and Processor Support link on the Welcome page) is expandable for future add-ins.
CPU missing from Add Project Configuration list
If you try to add a configuration for a CPU that does not appear in the drop-down list of the Add Project Configuration dialog box, verify that you have selected a platform that supports that CPU. Also, if you've opened a project where the platform and CPU text fields are grayed out, you will need to add a configuration (see Adding a New Configuration to an Existing Project). In this scenario, the list of CPUs corresponds with the first platform that occurs alphabetically in the drop-down list. You may need to create a "dummy" configuration to activate the grayed-out fields. At that point, you can select the appropriate platform.
In yet another scenario, if you create a project with only one SDK installed (for example, the Pocket PC SDK), the project will list only Pocket PC CPUs in the toolbar drop-down list. If you then install an SDK that does not have at least one CPU in common with the CPUs available in Pocket PC, you will not see this new SDK in the Platform drop-down list for that project nor will you be able to use Add Configuration to add a CPU from the second SDK. The only way to add a CPU to this project from the second SDK is to first uninstall the Pocket PC SDK. Then Add Configuration will allow selection of CPUs from the second SDK. Finally, if you then reinstall the Pocket PC SDK, both SDKs will now appear in the Platform drop-down list. Any future projects created after this sequence will show both SDKs in the Platform drop-down list.
Working with projects that target an unsupported CPU
If you open a project targeted to a specific CPU that's not supported by the SDKs installed on your system, no warning message appears. Instead, the project opens but both the platform and CPU text fields are grayed out. To work with the project, you must either install an SDK that supports the CPU, or add a new configuration. (See Adding a New Configuration to an Existing Project.)
Taskbar repainting problems when the emulator and desktop run at the same resolution
Running emulation at the same screen resolution as the desktop is not recommended. This scenario creates significant conflicts between the emulation taskbar and the desktop taskbar, resulting in unpredictable display behavior.
Interaction with Windows CE Toolkit for Visual Basic 6.0
If you installed the Windows CE Toolkit for Visual Basic 6.0 before you installed eMbedded Visual C++ 3.0, eMbedded Visual C++ includes configuration information for the H/PC running H/PC Pro Edition software even if you did not install the H/PC Pro SDK. You may then see the H/PC listed as a target in the IDE. However, to build applications for it, you must install the H/PC Pro SDK.
Multiple Language Resource Files
If you choose a resource language that is not installed on your machine, a dialog might appear directing you to a readme file. That information is now provided by online Help. Select "language resource files (eMbedded Visual C++)" from the Help index.
Mixed Japanese/English pathnames
In the Japanese version, combining English and Japanese characters in pathnames is not recommended.
Help menu in HTML Help window displays inactive menu items
The Help menu in the HTML Help viewer includes menu items "MSDN Library Help" and "MSDN Online." These items are not functional in eMbedded Visual Tools.
Link errors in Japanese H/PC 2.0
Link errors may occur in building Win 32 DLL programs. This behavior does not appear to affect building EXE or MFC projects.
Errors due to inaccurate pathnames, spellings, etc.
To avoid errors such as "Cannot launch remote exe, File Not Found" or "Please check remote exe path," be sure to verify file location and spelling, including extension, when specifying local and remote exe file names. For example, \windows\start menu\HelloWorld.exe for a remote exe, and d:\temp\HelloWorld\MipsDbg\HelloWorld.exe for the local exe.
Application error using macro tool
When eMbedded Visual C++ is installed on a Japanese path, running or recording using the macro tool produces an application error.
Subdependencies do not download
If Project (or DLL) C is a dependency of Project B, which is a dependency of Project A, only Projects A and B will be downloaded when A is rebuilt.
Automatically generated .MAK files fail to define CENoDefaultLib=$(CENoDefaultLib) /nodefaultlib:oldnames.lib. Without this definition, the linker will try to link oldnames.lib, which no longer exists in Windows CE.
Caption ID not updated properly
In the Resource editor, Caption ID is not updated properly if changes are made using the Resource Symbols dialog box. To correctly make changes, use the Menu Item Properties dialog box.
Note on using Microsoft Visual SourceSafe
If you delete an eMbedded Visual C++ project from Visual SourceSafe, then attempt to re-open the project in the IDE, you will see a recovery message. If you select OK, you will be asked whether you want to re-attempt the connection in future sessions. Select No, then close the workspace and reopen it. (If you choose Yes, you will continue to get this series of messages in future openings.)
CommandBar buttons not displayed properly
If you add a ComboBox to the CommandBar and the ComboBox width exceeds the form width, the CommandBar divides into two lines. At run time, only the upper half of the CommandBar buttons will be visible. To avoid this scenario, reduce the Width of the ComboBox or try to make it multiple-button width.
Some imported H/PC 2.00 projects might not build correctly for x86em configurations
All imported projects in eMbedded Visual C++ will have the /Gz flag added among the settings for x86em. To build these projects, remove the /Gz flag, using the Project Options edit box in the Project Settings dialog box. (The /Gz flag specifies the _stdcall calling convention for all prototyped C functions, except for functions that take a variable number of arguments and functions marked _cdecl or _fastcall.)
Building PowerPC applications
To build PowerPC applications, manually edit linker settings as follows:
eMbedded Visual C++ lets you add new configurations to existing projects as new platforms and processors become available.
To add a new configuration:
Additional step for Pocket PC projects only: From the Project menu, choose Settings | Link. In the Category drop-down, select Input, then add AYGSHELL.LIB to the Object/library modules field.
Additional step for DLL projects only: From the Project menu, choose Settings. In the Settings For drop-down list, select the configuration being added. Then, on the C/C++ tab, add the following to the Project Options edit box:
/D "_USRDLL" and /D "PROJNAME_EXPORTS", where PROJNAME is the name of the project.
Important: New preprocessor definitions must be added manually
To add preprocessor definitions:
Additional steps for MFC projects
,_AFXDLL". If this is an ActiveX control, also add ",_USRDLL".Default flags differ among processors
Default compiler flags can differ, depending on the processor. To inspect or modify flags, choose Settings from the Project menu, then select the C/C++ tab and use the Project Options edit box.
The Resource compiler ignores the character EUDC 0xE000 in STRINGTABLE. Results can range from errors to shutdown of the IDE.
IDL compilation anomaly when converting older projects
When converting a project built with an earlier SDK, it is reported that the MIDL compiler may not recognize an enum in an IDL file. The following example was submitted:
[uuid(GUID)] enum
{
IDC_ENDCOMPUTER = 4095
};
Changing these lines to the following allowed successful compilation:
typedef [uuid(GUID)] enum
{
IDC_ENDCOMPUTER = 4095
}WHAT_EVER;
Debugging problems can arise when different copies of the same DLL are present on the target device. Make sure there is only one copy. For additional information, select "DLLs (eMbedded Visual C++), debugging" from the online Help index.
The Debugger does not support showing the return value for functions, even if the Return value checkbox in the Debug tab of the Tools | Options dialog box is checked.
Specifying local and remote file names
In the Additional DLLs category of the Project Settings | Debug dialog box, you do not need to specify a remote DLL name if you have already specified the local name. If you do not have a local copy and don't want to be prompted to specify a local copy of the remote DLL, leave the local name blank and enter the remote DLL name in the Remote Name column.
Cannot debug a Windows CE application with a Japanese name
Microsoft does not support debugging DLLs or using projects that have Japanese names. To work around this issue, you should name your DLLs and projects in English.
You can start a debug session with a Japanese-named application, but no breakpoint set in the IDE is hit. The debugger skips all the breakpoints you set, and runs the application on the device without stopping. If you add a DebugBreak statement (a hard breakpoint) to the source, the debugger stops, but the arrow only appears in the disassembly window.
Stepping Into system DLLs not supported
Stepping through a function pointer into a system DLL freezes some devices. Be aware that DLLs are shared, not copy-on-write.
Debugging applications that have caused exceptions
While debugging an application that has caused an exception, occasionally the debugger may confuse the user. When the "First-Chance Exception" dialog appears, the IDE goes to disassembly view and the title bar continues to say "Run." The debugger waits, expecting user input. To work around this, press F5, and the normal debugging process continues.
Ambiguous source lines for loops when debugging optimized code
Source line ambiguity can occur on looping constructs when debugging optimized code. This can happen because the optimized loop actually exists in two places. Part of the source line is handled in one place, and the rest of the source line is handled in a different place. This is clear when looking at the mixed disassembly source window. The source line number appears twice in the disassembled listing.
The Microsoft® eMbedded Visual C++® 3.0 debugger is a single–executable debugger. In general, it cannot step from one executable into another. The workaround is to perform the following steps:
Applications that are DLL-only or ActiveX Control-only need an executable or container for debugging
To debug DLL-only and ActiveX control-only applications for this release, create a container or an executable and add the application to it. Specify the DLL or ActiveX control as an additional DLL in the Debug tab.
Platform Manager hangs on reboot or broken serial connection during debugging
While you are debugging an application, if you reboot the H/PC or otherwise break the serial connection through a loose cable or dropped connection, eMbedded Visual C++ stops debugging and does not generate any warning or error messages. When you try to restart debugging, you cannot reestablish the connection.
Consequently, if the device crashes, the communications channel is destroyed with the IDE; you must then restart the session to continue. The workaround for all of these issues is to close Platform Manager and eMbedded Visual C++, then restart.
Debugging a DLL that is loaded by an EXE in ROM
If you wish to debug a DLL that is loaded by an executable (EXE) in ROM, you must add the command DebugBreak() to DllMain() when dwReason == DLL_PROCESS_ATTACH.
For example, if you wish to create a ControlPanel applet, and CtlPnl.exe is in ROM on the device, you will need to modify DllMain in your applet:
BOOL WINAPI DllMain(HANDLE hDLL, DWORD dwReason, LPVOID lpReserved)
{
if(dwReason == DLL_PROCESS_ATTACH)
{
DebugBreak();
}
…
}
The debugger will not indicate that the application has hit the DebugBreak(), but you will be able to debug properly. If you wish to run the program with the DLL, without using the debugger, you will need to remove the DebugBreak() command from DllMain.
Step Over on CreateThread causes fatal application error on SH3 Windows CE for Palm-size or Pocket PC
During debugging, do not attempt to step over a call to CreateThread. Instead, insert a breakpoint on the next line, press F5, and remove the breakpoint you just set.
No dialog box when the debugger Steps Over DebugBreak
If you step over a routine that contains the DebugBreak function, the debugger stops executing when it encounters DebugBreak. The Breakpoint dialog box, which indicates where the breakpoint was hit, does not appear.
If two copies of an executable file exist and one is in the same directory as the CEMON debugger, CEMON always debugs the file in its directory, no matter which file you specify. To avoid this, be sure that the directory that contains CEMON—usually the Windows directory—does not contain a copy of your executable file.
If you add a DLL to a project during debugging, the debugger does not load the debug symbols for the new DLL. To avoid this problem, map all DLLs to your project before debugging.
DLL Load Notification shows no file name
When the IDE prompts for the path to a local DLL, the dialog does not contain the file name. If you browse for the DLL, the edit box contains the name of the DLL you picked when you return but does not show the DLL the debugger was looking for. Make sure to note the exact name of the DLL before beginning a file search.
Debugging an application on a MIPS Windows CE-based device
If you debug an application on a MIPS Windows CE-based device, you cannot use the Watch window to evaluate a function with a character string as a parameter. You can, however, evaluate a function with a character pointer as a parameter.
For example, you cannot use the Watch window to evaluate the expression f("abc"), but you can evaluate the expression f(str), where str is a string defined in the application.
If you try to evaluate a function with a character string as a parameter in the Watch window, you receive a data type misalignment exception. If you leave the offending expression in the Watch window every time you step, or hit a breakpoint, it is evaluated and generates the exception.
To remove an illegal string evaluation from the Watch window
Handheld, Palm-size, and Pocket PC Emulation
The debugger goes to disassembly when it hits a memory breakpoint for x86 emulation. You cannot go back to the source code. Emulation applications are multithreaded, even if they are written with a single thread. In Microsoft eMbedded Visual C++ 3.0, memory breakpoints make multithreaded applications react irregularly.
Debugging an application from a DLL project before downloading to the target device
This issue only occurs in a DLL project. If you try to debug the application before you download it to the target device, you get a message box that states the executable file is not found on the device. Choose OK, and choose Build All from the Build menu or choose Update Remote Output File from the Build menu. Then you can start debugging.
Tracking the value of unreferenced variables in SH3
If an SH3 application contains an unreferenced variable, the debugger cannot show you the value of that variable. To see the value of the variable, rewrite your code to reference the variable. For example, use the variable on the rightmost side of an expression.
Palm-size or Pocket PC debugging problems
Debugging applications on a Palm-size or Pocket PC occasionally results in the debug monitor still running when debugging is complete. To work around this problem, terminate the process on the device.
Quick Watch window does not set or reset variables on a PowerPC (PPC)-based device
When debugging an eMbedded Visual C++ 3.0 application built for PPC, if you access the Quick Watch window to set or reset a variable, the following error message appears: "Error: cannot display value". All variable values must be set within the compiled code.
Incorrect Window Display During Debugging
The debugger sometimes displays the disassembly window instead of a source window when it hits a breakpoint in a secondary thread.
Breakpoints set in functions called from more than one thread simultaneously do not always work correctly.
Microsoft Windows CE does not support setting data breakpoints in x86 or Pocket PC devices.
Debugger Stops Unexpectedly When Setting Global Data Breakpoints in Applications
When a global data breakpoint (data breakpoint without a scope) is set in an application, the debugger will stop suddenly. When this occurs, press F5 or choose Start Debug >> Go from the menu bar to continue debugging. The workaround for this issue is to use a kernel debugger.
Setting Breakpoints on a MIPS Processor
If you try to set a breakpoint on the name of a function that is in a DLL that has not yet been executed, you may hit that breakpoint in assembly code, instead of in the DLL. If this happens, select Step Over repeatedly until you arrive at the function in the DLL. You can avoid this situation by using one of the following procedures:
Once you hit any breakpoint in the DLL, you are able to hit other breakpoints in the DLL.
Data Breakpoints on an SH Processor
On SH processors, if a data breakpoint is set on a variable that is assigned a value, but the variable is not used before it is assigned another value, the data breakpoint may not be hit. For example, if a data breakpoint is set on a loop index variable and that loop index variable is not used in the loop, then the data breakpoint is not hit until the loop is terminated. The following code example illustrates the problem:
for(i=0; i<10; i++) {
count++;
}
To work around this problem, be sure that the variable is used between assignments.
for(i=0; i<10; i++) {
j = i;
count++;
}
Also, the problem occurs in the following situation.
i = 0;
i = 1;
Put a statement, such as j=i, between the statements and the data breakpoint is hit.
Adding MFC Support to a New Configuration
To add MFC support to a new configuration, change the project settings as follows.
An ATL for Windows CE project that is made a dependency of another project does not register properly if ATLCExxx.DLL is not resident on the target device. Since ATLCExxx.DLL is a dependency of a dependency, it is not automatically downloaded. This issue can be resolved by manually downloading and registering ATLCExxx.DLL, or by making the dependent project the active build target and performing a Rebuild All. After applying one of these two solutions, the container project can be made the active build target without experiencing further registration failures with the dependent project.
In the case of an MFC or OLE project that has been made a dependency of another project, the application WILL fail to execute. In this CASE, neither MFCCExxx.DLL nor OLECExxx.DLL are automatically downloaded. The resolution again is to manually download the required nnnCExxx.DLL or perform a Rebuild All of the dependent project.
MFC Dialog Applications Can Prevent Switching to the Today Application
Pocket PC specifications do not recommend the use of modeless dialog boxes because all windows must be full-screen and only one application is active at any point in time. Modal dialogs satisfy requirements in this area. The application wizard generates code for modal dialogs as well. When a dialog-based application is generated, the modal dialog that is created for the application has a NULL parent, as this application has no parent. The OS equates NULL dialog parents with the Today application. Therefore, when a modal dialog application is active, you cannot switch to the Today application until the modal dialog is dismissed since its parent becomes the Today application.
Compiler Errors When Building an Executable Application for a H/PC Pro Device With MFC AppWizard
The Pocket PC MFC AppWizard generates applications specifically for the Pocket PC. If you build an executable MFC application for the H/PC Pro device using the WCE Pocket PC MFC AppWizard (exe) the compiler generates errors. You must use the WCE MFC AppWizard (exe) to build an MFC executable application for any device other than a Pocket PC.
Pocket PC MFC Wizard Creates an Incorrect MainFrame.cpp File When the Class Name is Changed During Setup
When using eMbedded Visual C++ 3.0 and the Pocket PC SDK to create a project with the MFC AppWizard, if you change the class name from CMainFrame to anything else in step 4 of the wizard, an error appears. The compiler error states:
error c2653: 'CMainFrame' : is not a class or namespace name
This error occurs in the wizard template file mainframe.cpp. The function declaration
LPTSTR CMainFrame::MakeString(UINT stringID)
should have the class name which you changed in step 4 of the wizard.
The workaround is to change the CMainFrame to the name of the class which you changed in step 4 of the wizard.
Help Topics Menu Item Fails in an MFC for Windows CE Application
The Help Topics item on the Help menu in an MFC for Windows CE application does not work. A workaround is provided below to fix this problem.
To fix a Help Topics menu item
// *ON_COMMAND(ID_HELP, OnHwlp) // in the message map
CWinApp* pApp = Afx GetApp();
ASSERT_VALID(pApp);
TCHAR szHelpFileName[_MAX_PATH];
lstrcpy(szHelpFileName,_T("\\"));
::PegHelp(szHelpFileName);
#include "wcextrn.h"
Message Maps in Help for Windows CE
The following table shows messages related to Help in MFC for Windows CE and shows whether the messages are supported by the Windows desktop or the Windows CE environment.
| Message | Message Handler | Desktop | Windows CE |
|---|---|---|---|
| WM_HELP | CWnd::OnHelpInfo | Yes | Yes |
| WM_COMMAND + ID_HELP | CWnd::OnHelp | Yes | Yes |
| WM_COMMAND + ID_HELP_FINDER | CWnd::OnHelpFinder | Yes | No |
| WM_COMMAND + ID_CONTEXT_HELP | CFrameWnd::OnContextHelp | Yes | No |
Much like the Microsoft Foundation Classes for the Windows desktop operating system, MFC for Windows CE has inherent functionality to help you design user Help systems. The following list summarizes the differences between Help for Windows CE and Help for the Windows desktop operating system:
The Palette sample does not always refresh the bitmap on high color displays (greater than 256 colors). You can still use the logic of the code to allow 16-million-color bitmaps to work on 64K displays if this functionality is required.
Support for Methods of the CWnd Class in MFC for Windows CE
MFC for Windows CE supports both the OnHelp and OnHelpInfo methods of CWnd class. CWnd::OnHelp is a handler for COMMAND + ID_HELP, which calls PegHelp using pApp->m_pxzHelpFilePath.
Subclassed MFC for Windows CE ActiveX Controls May Not Work Properly
If you use the subclassing feature of the MFC for Windows CE, ActiveX Control wizard, your controls may not perform properly. MFC for Windows CE does not currently support subclassing.
The ActiveX Control Wizard May Cause Some Controls to Not Register When Adding Multiple Controls to an MFC ActiveX Project
When you use an SDK that supports MIPS to build an MFC ActiveX project and add multiple ActiveX Controls with the wizard, not all of the controls will register. Some of the options in this wizard may cause the resulting control to register incorrectly.
When running an NMAKE Command for an ActiveX Control Debug Build, eMbedded Visual C++ Will Not Find the TLB File
If you use eMbedded Visual C++ 3.0 and a Platform SDK to make the Debug build for an ARM system then export the makefile and run NMAKE from a command line, the .tlb file will not be found. When a Release build is made, you can open the .mak file and copy the following line:
$(INTDIR)\test4.res : $(SOURCE) $(INTDIR) $(INTDIR)\test4.tlb
Paste this line into the corresponding .vcn file of the Debug build.
Using the Find and Replace Dialog Boxes on a Handheld PC When Statically Linking with MFC
On H/PC using Version 2.0 of the Windows CE operating system, the Find and Replace dialog boxes are implemented in a resource file that must be included by your MFC application when linking statically using Uafxwce.lib or Uafxwced.lib.
To include the resource file to implement Find and Replace dialog boxes
#include "wceres.rc".A Parent Menu From an MFC Application is Still Visible When the Modal Property Sheet is Open
The Pocket PC SDK guidelines recommend that a menu in a parent window should no longer be visible when a modal property sheet is open. MFC works fine when a modal dialog is open as the menu of the parent is hidden behind an empty control bar.
The workaround for this issue is to create an empty control bar upon property sheet initialization and destroy it upon exit from the property sheet modal loop. The Pocket PC SDK sample, propdlg, demonstrates this fix.
The following steps show a workaround for this issue:
CControlBar* m-pWndEmptyCB;
BOOL CMyPropSheet::OnInitDialog()
{
// WinCE: modal propertysheets initially do not want a menu, so we // create an empty menu bar.
m_pWndEmptyCB = new CCeCommandBar;
if(m_pWndEmptyCB !=NULL)
((CCeCommandBar*)m_pWndEmptyCB)->CreateEx(this);
BOOL bResult = CPropertySheet::OnInitDialog();
return bResult;
}
if(g_pCPropertySheet->DoModal() == IDOK)
{
…
}
if(g_pCPropertySheet->m_pWndEmptyCB != NULL)
{
g_pCPropertySheet->m_pWndEmptyCB->DestroyWindow();
delete g_pCPropertySheet->m_pWndEmptyCB;
g_pCPropertySheet->m_pWndEmptyC = NULL;
}
ATL for Windows CE Does Not Support Singleton Objects
ATL for Windows CE does not support singleton objects. A compile error is generated if you try to make an ATL for Windows CE object a singleton by adding the following macro to your class:
DECLARE_CLASSFACTORY_SINGLETON("class name").
The CComClassFactory class is supported by Pocket PC; however, the FinalRelease() method calls CoDisconnectObject() which is only supported by Platform Builder. To use this class for Pocket PC, you need to comment out (//)the call to CoDisconnectObject().
Compilation Errors Occur When Building an OCX or MFC DLL After Inserting an ATL Control
A compilation error occurs when building an OCX or MFC DLL after inserting an ATL control into it. This also occurs when a client reads an ATL component interface using Vtable interfaces which results in compile-time binding. Windows CE only supports a DLL-type COM server and not an executable type (EXE). The workaround for this issue is to modify the ATL for Windows CE headers as follows:
HRESULT wce_CLSIDFromProgID(LPCOLESTR lpszProgID, LPCLSID pclsid);
wce_CLSIDFromProgID in the wceatl.cpp file.COM Project Will Not Build When Adding a New Configuration
When you build an ATL COM project without support for the CPU that you are testing, you receive a resource error stating that you cannot open the <COM project>.TLB file. The <COM project>. TLB exists in the external dependencies and is in the appropriate folder for the desired CPU.
The following steps will reproduce this error:
Causes for this issue are as follows:
midl/nologo/Oicf/h"ATL31.h"/iid"ATL31_i.c""ATL31.idl" ".\ATL31.tlb" ".\ATL31.h" ".\ATL31_i.c"
The WCE ATL wizard will always generate this custom build information during the project creation. To work around this issue you need to copy the custom build information from another configuration which contains the custom build information. A step–by–step list of how to accomplish this workaround is as follows:
Older ATL Projects May Include the Wrong Definition
Older ATL projects may have _WIN32_WINNT defined in the StdAfx.h file. If the following definition is declared in StdAfx.h:
#define _WIN32_WINNT 0x0400
you need to modify the declarations as follows:
#ifndef _WIN32_WCE #define _WIN32_WINNT 0x400 #endif
This change prevents _WIN32_WINNT and _WIN32_WCE from being defined simultaneously and allows the conditional defines in the OS header files to work properly. For example, this modification allows AF_IRDA to be defined correctly for IrDA support in ATL.
Older ATL Projects List Ordinals When Built in eMbedded Visual C++ 3.0
If you open an older ATL project (created with VCCE 6.0 for example) using eMbedded Visual C++ 3.0 and build the project you will notice the following warning for all the MinSize Configurations:
mfcs42d.lib(stdafx.obj): warning LNK4044:unrecognized option "ignore:4089"; ignored :\TEST.def: warning LNK4222: exported symbol "DllCanUnloadNow" should not be assigned an ordinal :\TEST.def: warning LNK4222: exported symbol "DllGetClassObject" should not be assigned an ordinal :\TEST.def: warning LNK4222: exported symbol "DllRegisterServer" should not be assigned an ordinal :\TEST.def: warning LNK4222: exported symbol "DllUnregisterServer" should not be assigned an ordinal
For these older ATL projects, you must remove the ordinal for all of these functions in order to build a clean project.
Failure of Remote Registration of an ATL Control
If remote registration of an ATL control fails, it may be necessary to copy ATLCE210.dll, ATLCE211.dll, ATLCE212.dll, or ATLCE300.dll to the Windows directory on the device or, in emulation, to use REGSVRCE to register the .dll.
You can use eMbedded Visual C++ 3.0 to register ActiveX controls on a Windows CE-based device. To confirm that your control registered successfully, look at the dialog box that appears on the device interface.
The Visual Basic for Windows CE CreateObject function cannot load ActiveX controls that are created with MFC for Windows CE. CreateObject can load ActiveX controls that were created with ATL for Windows CE.
ATL Sample Sketch for the Handheld PC Using Windows CE Version 2.0 SH3 Causes an Error When Changing Pen Width in VB Script
On a Handheld PC using Version 2.0 of the Windows CE operating system, changing PenWidth with the CInt command results in an error when using Sketch.dll in a VB script, because PenWidth property has the type short and CInt constructs the int value.
To work around this problem, change the PenWidth property to type int.
Painting a CScrollView Client Area
Windows CE does not implement GDI transformations, which include the ability to set the origin of a window used to implement Window scrolling. It is up to the developer to recalculate the coordinates based on the scroll position when drawing to a device context in a view. The WCEDBTST MFC sample illustrates a possible workaround. The following code shows a simple example.
// Draw a black rectangle using the logical coordinates
// (10,20) to (90,40) We are assuming MM_TEXT coordinates
// (the only coordinate system supported under Windows CE),
// and we offset manually based on the scrollbar positions.
CMyScrollView::OnDraw(CDC* pDC){
// Get the scrollbars. In this sample, we are assuming that
// the scrollbar ranges are equal to the height and width of
// the CView client area, in pixels.
int nOrgX = -GetScrollPosition() .x;
int nOrgY = -GetScrollPosition() .y;
// Get logical coordinates for rectangle.
CRect wndRect(10,20,90,40);
// Offset using the origin.
wndRect.OffsetRect(nOrgX,nOrgY);
// Draw it with the color = black.
pDC->FillSolidRect(wndRect,RGB(0,0,0));
}
Choice of Threading Model Not Available In ATL Object Wizard
When you build an application with the WCE ATL COM AppWizard and insert a new ATL Object, the Apartment Threading Model option is disabled in the Attributes tab because the ATL Wizard always sets the ThreadingModel to Apartment in the .rgs file.
Opening an ATL project from a network share can result in a compile-time error
Building an ATL project you have opened from a network share results in a compile-time error under the following conditions:
To avoid this error, either copy the project to the local machine or map the share where the project is located.
Sharing Programming Components Among Projects
This online Help topic contains obsolete information. Specifically, controls are no longer present by default in the Component Gallery, and you cannot share controls between eMbedded Visual C++ and desktop Visual C++.
The following structures listed in the API reference are not supported in this release of Windows CE: MOUSEKEYS, SOUNDSENTRY, STICKYKEYS, TOGGLEKEYS, HIGHCONTRAST, ACCESSTIMEOUT.
The following messages listed in the API reference have been replaced as follows:
MFC CFormView Class Found under "CFontView Class" in Online Help Index
In the Microsoft Foundation Class Library for Windows CE within the Index tab CFormView class is listed as "CFontView class" instead of CFormView class.
If you have accepted the default directories when installing Microsoft eMbedded Visual Tools, additional documentation can be found in the following locations:
| Subject Area | Path and File Name |
|---|---|
| Installation and Setup | C:\Program Files\Microsoft eMbedded Tools\README.HTM |
| eMbedded Visual Basic | C:\Program Files\Microsoft eMbedded Tools\EVB\releasenotes.htm |
| eMbedded Visual C++ | C:\Program Files\Microsoft eMbedded Tools\EVC\releasenotes.htm |
| SDK: H/PC Pro | C:\Windows CE Tools\hpcproreadme.htm |
| SDK: Palm-size PC 1.2 | C:\Windows CE Tools\pspc12readme.htm |
| SDK: Pocket PC | C:\Windows CE Tools\pocketpcreadme.htm |
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2000 Microsoft Corporation. All rights reserved.
Microsoft; MS-DOS; Windows; Windows NT; eMbedded Visual Basic; eMbedded Visual C++; SDK for Windows CE, Handheld PC Professional Edition 3.0; SDK for Windows CE for the Palm-size PC 1.2; and Windows Platform SDK for Pocket PC are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.