Re: PocketPC -> WinCE

Hehe... ok I see, it's a bit more complicated than I first thought.

But what I really was thinking of, but I forgot to mention some important
information, was that if you are using VS .NET and C# (CompactFramework and
I probably should have posted this message in the compactframework) to
produce your PPC project, and as PPC uses the same version of Compact
Framework as WinEC does, I believe it wouldn't be too much of a hassle to
convert the source files (solution, projectfiles, formfiles) to WinCE style.

There are definitely platform specific pieces here as well, but I don't
think it is as deep as Robert explains he has in his C++ code. If you are
using PInvoke exstensively, expecially within the areas Robert talked about
you could be in trouble as well...

My PPC projects pretty much work on a WinCE machine after I
1. Create a new WinCE project
2. Import all code files
3. Set up dependencies
4. Fix the screen size and fix the control buttons
5. Fix potential menu-issues

There may be more than that to it, but I believe it can be overcome (until
proven wrong) :-)

/ Peter


<r_z_aret@xxxxxxxxxxxx> skrev i meddelandet
news:1fmgq1dg9183k92mpj9k748kgg0gpd4dpb@xxxxxxxxxx
> On Tue, 20 Dec 2005 10:37:17 -0500, "Ginny Caughey [MVP]"
> <ginny.caughey.online@xxxxxxxxxxxxxx> wrote:
>
>>Peter,
>>
>>I don't know of such a tool, although if the screen sizes are the same and
>>the particular CE machines has support for all the APIs you use, it might
>>just work as is with the menus and tabs appearing as you'd expect based on
>>the platform.
>
> All my apps are dialog based and I use C/C++ straight Win 32. So I
> don't know about forms. Also, I've been writing to the greatest common
> denominator, so my code may be more compatible/portable than other
> folks'. Most of my code is the same for Pocket PC and other Windows CE
> platforms. I use pre-processor macros to isolate the few instances. I
> see 38 instances of the Pocket PC macro in the code fro my static
> library (> 70K lines) that I used heavily in all my programs. I see 12
> instances in my main app (about 15K lines). Several of those instances
> (in library and app) are disabled. I'm checking those instances as I
> write this note; I haven't touched much of this code in a while, so I
> don't remember all the details.
>
> Menus are a major difference. Pocket PCs use SHCreateMenuBar to
> initialize the menu, while other platforms use CommandBar_Create.
> Pocket PCs handle. More bothersome is that Pocket PCs use an SHMENUBAR
> resource that no other platforms use. And I haven't found any way to
> generate one at run time, so I can't have proper dynamic menus in
> dialog boxes generated entirely by my static library (I've discussed
> this in other threads). I _think_ Pocket PCs do something different
> with HMENUs, but tracking that down hasn't been a high priority
> (strange statement, I know, but...). I see special handling for
> bitmaps, with some code specifically for WM 5 (I just added a hack
> that seems to switch to 0-based indexes for WM 5). The menu is not
> part of the client window for Pocket PC but is for other Windows CE
> platforms.
>
> I have some code to handle the higher resolution screens found on some
> Pocket PCs.
>
> Several SH... functions are used only with Pocket PCs. I tried
> SHHandleWMActivate, but didn't see any changes so I deactivated that
> code. I do use SHFullScreen, SHInitDialog, and SHSetNavBarText, but
> not much.
>
> The X and OK buttons have meanings that seem to vary from one Pocket
> PC version to another. This has been discussed in several other
> threads.
>
> -----------------------------------------
> To reply to me, remove the underscores (_) from my email address (and
> please indicate which newsgroup and message).
>
> Robert E. Zaret, eMVP
> PenFact, Inc.
> 20 Park Plaza, Suite 478
> Boston, MA 02116
> www.penfact.com


.

Loading