Updated 2012-11-25 22:56:03 by RLE ▲

Marketing name used by Microsoft since about 2000 for Windows/CE, which runs on little handheld computers (PDAs) with small screens, e.g. iPAQ or Yakumo Alpha. Other incarnations include Windows Mobile 2003 and Windows Mobile 2003 SE (for Second Edition) The newest version of this operating system goes by the marketing name [Windows Mobile 5] which unifies both PDA and Smartphone versions of the system.

how to run Wikit on PocketPC -- also see Tclkit Mobile and eTcl

To port a Tk app to a PocketPC, consider that the screen is only 240x320 pixels, of which the top menu bar and at least the bottom right corner are not at the app's disposition.

As an example for porting, here is code with which MPJ adapted the code in Chess in Tcl to a HP Jornada:
 ###  Code to look better on a PocketPC
  wm geometry . 240x268+0+1
  . config -menu [menu .m]
  .m add casc -label Game -menu [menu .m.game -tearoff 0]
  .m.game add comm -label Undo  -comm {game undo;  game drawSetup .c}
  .m.game add comm -label Reset -comm {game reset; game drawSetup .c}
  .m.game add comm -label Flip  -comm {game flipSides .c}
  .m.game add separator
  .m.game add comm -label Exit  -comm exit
  game drawBoard .c -color {blue tan3}

How do people produce the PocketPC screenshots?

MNO Thanks for the suggestion - it works very well for me too. Now I have a further question: I notice that the above code and the code for iFile 1.1 (and probably tkcon 2.3 but I haven't checked) include menus and the screenshot above clearly shows the menu appearing in the bottom left. This, for some reason, is not working for me. I am using the 8.4.3 binaries as posted on the Windows/CE page and iFile 1.1 from its page (as well as tkcon 2.3 downloaded elsewhere). I ran a quick test in tkcon, doing
 package require Tk
 . config -menu [menu .m]
 .m.game add comm -label Exit -comm exit

but I still don't see a menu anywhere even when activating (i.e. bringing to the front) the . window.

Is anybody else using the 8.4.3 binaries but seeing the menus? (i.e. have I messed up something in my installation or is this behaviour common to everybody?)

Ahh - I just re-read the README in that distribution, which has "Menus don't work correctly" as one of the TO-DO items. Any idea when/if menus will be fixed in the 8.4.3 distro?

MPJ Rainer's version 8.4a does file menu and menu buttons correctly. I'm sure TclGuy will get his version working soon.

MNO yes - I don't doubt it too :) I've also noticed another piece of behaviour which is perhaps specific to this 8.4.3 version. In e.g. iRead, the open file dialog box opens up underneath the main window and so far I've not been able to find a way to coax it into visibility (it doesn't show up in the running programs list so I can't activate it there, and activating iRead just brings up the main window) short of killing the iRead application after which it appears with an exception dialog box. AKG This issue still seems to be present in 8.4.4.

FW: Some notes on the lack of a native look for Tcl on PPC:

Windows CE predated by far the PocketPC interface, and its default interface is akin to a shrunken Windows 95, originally made for clamshell Handheld PCs that have wide, short displays. Being a general-usage embedded systems OS, CE provides tools to build new interfaces for different devices, which is how the PocketPC OS was made. Most applications written specifically for PPC use the features of the new interface, which uses full-screen PDA-style windows, has no desktop or taskbar, etc. But the old more generic CE APIs are still exposed, so it's still possible, for example, to make non-fullscreen, resizable windows, rather than the usual PocketPC full-screen panes. This is how the Tk ports are made - they use a library called celib.dll, which in turn uses the standard Windows CE APIs, so Tk windows are movable, draggable windows, with an X in the upper-right corner of the independent title bar, and to its left the usual minimize and maximize buttions, which are hidden until clicked (of course, in PocketPC, minimize really means "hide" since there is no taskbar).

So Tk apps will seem fairly foreign and inconsistent with the interface to an average user. One technique to look more native, often used on this Wiki, is to fake fullscreen mode by growing the window to fill the whole screen and poke its title bar above the PocketPC bar at the top. But that still leaves unsightly window borders at the bottom and left edges of the screen, which users can resize (experimentally or accidentally), which causes the title bar to snap back into view.

Plus, since the X of the title bar is covered up with this technique, there is no "X" with which to close the window (and, of course, it doesn't feature the normal PocketPC X in a circle in the upper right corner), so the application writer has to make their own X button, which looks even more appallingly unnative. Hence, I don't think Tk application writers should use the "fake fullscreen" technique - in my scripts I either let it stay as a full, movable window, or for a better, relatively native-looking implementation of "fullscreen" I just maximize the window at start by doing a [wm zoom .]. I think we should accept that Tk windows really can't look or work like true PocketPC ones, and exploit it by just allowing users to resize and move their windows and consider it a feature.

Also, there's no facility to tell when the input panel is popped up and shrink the window so what the user is typing isn't potentially covered. That's another huge lack. Resizable windows also help cope with that bug, allowing users to resize their window by hand so they can see.

RS 2006-01-14: eTcl has a more native window model: title-less, unmovable. Maybe that better fits your needs? There's also SIP access functions, but without documentation, I haven't tried them yet. My rule of thumb is: if keyboard input is expected (like for a console),
 wm geometry . 240x188

But that doesn't cover the "landscape" screen setting, of course...

Schelte Bron reported in the Tcl chatroom on 2004-12-22 that BlueTooth communications on a PocketPC work if you open it as COM5:

sbron The number of the com port being used is configurable in the BlueTooth Manager. The point is that it should be specified in the form COMX:. Not \\.\comX. In addition, it is not possible to fconfigure the baudrate on a BlueTooth serial port. But that's not a problem as the data seems to be going through correctly regardless of the baudrate.

RS is really enchanted by his O2 XDA mini (HTC Magician), see Sepp.

[Chuck Winters] I have a problem opening the serial ports on my IPAQ 5550 (Pocket PC 2003) - set com [open com1: r+] generates an error message - couldn't open "com1:":no such file or directory. I have identical problems with 8.4.12 and Etcl. has anyone else run into such problems? if so how have you worked around the problem? [Chuck Winters] Thanks to EH over on the Etcl page- com ports work in Etcl 8.4.12.pl3. PWE The other tcl version with working com ports is the 8.4a2 version by Rainer Keuchel.

dzach 6-Feb-2006 : Has anyone tried to run Snack on these devices? EH If you only wish to be able to play some sound files on these devices, and don't need all the features of snack, I have added (alpha) support for audio in eTcl starting from release 8.4.12-pl6 (see comments on evodio package). Snack is a little bit too large for being included as default inside such a distrib. BTW, snack unfortunatly uses lot of float internally, whereas ARM architectures usually don't have a FPU, so it uses lot of CPU. IMHO, this makes snack a wrong choice for just playing some sound on ARM based devices. dzach Actually, I wanted to use Snack for recording. Except if there is another tcl tool for doing that (which I am not aware of).

MSH 2-Jun-2006 : I have written a small starkit executable script for PPC which runs ok and would like to link it directly to a button on the machine but the program does not appear in the list of available programs, even when I move it to one of the system directories. Does anyone have an idea how to do this (regedit or the registry package maybe ?) I am using the mobile3 kit end even manage to change the icon using a modified SDX script. - RS: Drop a link to your app into "\Windows\Start Menu\Programs" (or how your localization calls the place). Similarly for games. Thanks a lot Richard; it works great but now the little keyboard button is not displayed on the bottom of the screen (it appears when the program is run from the file explorer but not from the button ?) Is there a magic command available to popup the input method within a starkit ? RS: In eTcl you have wce sipshow etc. For starkits, I don't know. I think the sip button is just "inherited" from the last app, so if you first load Internet Explorer, and then your app, the button will stay there. Thanks again for the quick reply. I just found wce but I found eTcl to be a very BIG executable, and I also use Metakit. I've heard rumours of eTcl light and will look back from time to time. EH 2006-06-15 So called eTcl light (actually, just a plain-vanilla Tcl/Tk, with ZipFS support and Etcl specific extensions, e.g. wce package) is now available for download. It is 1.8MB large (more or less the same than Tclkit Mobile), and can even be compressed using UPX to generate a 850kB executable, with no significant lose of performance. A 'standard' version is also available, not much larger, but with embedded support for pixane and sqlite.

MSH 16-Jun-2006 : Thanks for the eTcl news I will have a look. I just need to find mk4tcl.dll for pocketpc, anyone have any ideas. I have another small problem, I have associated the program to a button (thanks RS) but if I press the button twice two executables are loaded (especially easy as the X does not kill the program !), I would have thought that on a pocket device the default should be never to run any executable twice unless specified. but windows just keeps on until there is no memory left, Is there a mechanism (in windows or 3rd party) which blocks multiple execution, I tried using socket (see singleton application) (tclkit mobile) but they are not supported ? EH Don't want to seems to plead too much for eTcl ;-), but: this is the way it behaves on Windows Mobile, except if explicitely requested to behave differently, that is, if an instance eTcl is already running, with exactly the same command line arguments, it windows is raised, instead of starting another Tcl/Tk instance. About the mk4tcl.dll: next step is to release an eTcl devel package containing everything needed (headers, and tclstub.lib and tkstub.lib) to let everyone compile easily their own loadable extensions.

MSH 19-Jun-2006 : Thanks again; it's looking better and better. You talk about Zipvfs support; do you have any plans for MK4? I believe that this is the format used for the starkit vfs; that would open up the field for eTcl to load any tclkit file! I insist a bit only because I have no development facilities for PocketPC (I use a palm T3) so would not be able to do anything with the devel package ;-) Thanks again for a great package.

Arts and crafts of Tcl-Tk programmingPDACategory MobileCategory Windows