Home   |   Products   |   Documentation
 

dev net revision
29 July 2008
 

  
 

Windows CE and CMarkup

CMarkup has been used on Windows CE since early in 2001, using the UNICODE build. CMarkup is great there because of its small footprint. But new releases of CMarkup are not tested on Windows CE so there have been small compile issues in some releases.

CMarkup not working in WinCE 3.0Thanh Ly 10-Mar-2003

CMarkup class doesn't seem to be working on PocketPC devices running the older Windows CE 3.0 OS. I'm testing my application on various hardware and OS combinations. The XML functions in my application work as intended on all PocketPCs running PocketPC 2002 OS but not WinCE 3.0 although the hardware platform remains the same. There are no errors when compiling the program, it's simpily exhibiting this unusual behavior at runtime. For a simple test case and example, my application checks to see if there is a data file - which is an XML document - when it starts up and creates one if one does not already exist. The xml file is created but is empty, it does not contain the default XML structure my application was suppose to create.

I think the problem you are describing is related to the saving and loading of files, not the processing. CMarkup Save and Load may have problems with Win CE because of the wide char (UNICODE UCS-2) files on Win CE. But we can figure this out without too much difficulty. I would look at the flags involved in saving the file, and trace through to make sure the xml m_csData contains those default structures before it is saved. Also check into any differences between files on the two versions of the OS. UCS-2 has two bytes per character, ASCII is one byte per char, and UTF-8 is one byte per char for standard chars and more for languages outside of Western Europe. The Save and Load were primarily built for UTF-8 but can be modified for Win CE.

Re: CMarkup not working in WinCE 3.0Thanh Ly 10-Mar-2003

Good news. It seems to like the C runtime routines over Win32 routines for converting Wide-char strings into single byte strings. In CMarkup::Save replace:

int nUTF8Len =
WideCharToMultiByte(CP_UTF8,0,m_csDoc,nLength,NULL,0,NULL,NULL);
char* pBuffer = new char[nUTF8Len+1];
nLength =
WideCharToMultiByte(CP_UTF8,0,m_csDoc,nLength,pBuffer,nUTF8Len+1,NULL,NULL);
file.Write( pBuffer, nLength );
delete pBuffer;

with:

/* Mod by Thanh Ly 3/10/03 */
int newLen = m_csDoc.GetLength();
char *pBuffer = (char*)LocalAlloc(LPTR,newLen);
wcstombs(pBuffer,m_csDoc,newLen);
file.Write(pBuffer,newLen);
LocalFree(pBuffer);

So instead of calling WideCharToMultiByte() to do the string conversions, I use wcstombs() and it works just as well.

Conversion functions were added to CMarkup in developer release 6.6.

Markup 8.2 under Windows CEMartin 22-Mar-2006

I want to use my CMarkup Developer 8.2 under Windows CE. I see you use strerror() and errno which is not supported by Embedded Visual C++ 4.0 compiler. Have you done or do you plan to get back Windows CE compatibility by using GetLastError() and FormatMessage()? I remember that I had tested CMarkup 6.5 under Windows CE in the past and it was working perfectly.

Windows CE compatibility with the error string will be cleaned up in the next release after 8.2. strerror was introduced as part of efforts to reduce platform specific dependencies. I have been responding to Windows CE customers with the following options but neglected to post this until now.

  1. The quickest solution to get it to compile, inside the #ifdef _WIN32_WCE at the top of Markup.cpp you can add
    #define strerror(n) _T("file error")
  2. If errno is supported, you can replace each call to strerror with the error as just a number like
    strError.Format( "errno %d", errno );
  3. To get the actual error string, you can use something like
    // OS provides a system error string
    DWORD dwError = GetLastError();
    CString csDescription;
    FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
      NULL, dwError, MAKELANGID(LANG_NEUTRAL,SUBLANG_DEFAULT),
      csDescription.GetBuffer(255), nSize, NULL );
    csDescription.ReleaseBuffer();

I will probably implement a private function like CString x_GetSystemError() and use the GetLastError() function. As always, your feedback is welcomed.

strerror(errno)medica 10-Oct-2006

"x_GetSystemError() and use the GetLastError() function"
This would be a nice solution. Please do it.

It is done in CMarkup release 8.3 and the internal function used to get file errors is called x_GetLastError though there is no affect on the public CMarkup interface.

Embedded Visual C++ warning LNK1166medica 10-Oct-2006

I'm testing your CMarkup 8.2 at the moment. When I compile my project with embedded visual c++ (Windows CE) I always get the warning:

Markup.obj : warning LNK1166: cannot adjust code at offset=0x00001000, rva=0x0001CCE4

Try the /Gy compiler option. If the warning remains, based on my googling the warning apparently means it would be necessary to rewrite large functions into multiple smaller ones for the code to work correctly on certain TI 925 chips due to a bug on those chips.

 
 

Posted March 10, 2003 updated October 19, 2006. Question or comment about this article?

©Copyright 2008 First Objective Software, Inc. All rights reserved.