ANNOUNCE: eTcl 8.4.12-pl6 for Windows Mobile (PocketPC and Smartphone)

[Eric Hassold]

I'm pleased to announce immediate availability of eTcl 8.4.12-pl6 for
Windows Mobile 2003 or better.

As usual, it is available from:
http://www.evolane.com/software/etcl/index.html

Linux and Win32 versions also available, but are nearly unmodified since
previous release.

Some useful notes can also be found on the Tcl Wiki:
http://wiki.tcl.tk/15260
http://wiki.tcl.tk/eTcl

Last two weeks, since previous release, have been dedicated to fix all
reported bugs, and to make eTcl fully compatible with all Windows Mobile
devices (that is both PocketPC and Smartphone devices, for all OS
versions from Windows Mobile 2003 to Windows Mobile 5).

Here is a small list of major changes since previous release:
- Native menu support has been fully rewritten from scratch to work on
Smartphone as well. As a side effect, Tcl event loop now remains active
even when a menu popup is displayed.
- eTcl will now run in true VGA mode instead of QVGA compatible mode,
when device supports it.
- CAB are marked as compatible with all OS versions, and are available
as both PocketPC and Smartphone versions (actually, their content is
strictly identical, Smartphone requires compressed CAB whereas PocketPC
requires uncompressed one, so can't provide a single one valid for all
platforms)
- desktop installer now contains CABs for all targets, and will
automatically choose the correct one during installation.
- A first (unstable) API for playing sounds (WAV) has been added
- Add a "wce platform" subcommand to guess from Tcl if running on
smartphone or pocketpc device
- All known bugs has been fixed, including:
+ corrupted image display when image size was not a multiple of 8
+ exec not working for executables in ROM
+ local time formatting broken
- Sqlite has been upgraded to 3.3.3

I believe that from this release, Tcl port to Windows Mobile platforms
can be considered as completed. As usual, all comments, bug reporting
and feedbacks are much appreciated to help us provide a robust Tcl port
for mobile devices.

Eric Hassold
Evolane - http://www.evolane.com/

[s-imai]

Hi.

I've used eTcl for Windows Mobile with iPAQ hx2490(Windows Mobile 5.0).
When I input Enter-key to some widgets from HP's Thumb keyboard,
Thumb keyboard input a newline character and another box-shaped
character.
but Software keyboard of PocketPC can correctly input Enter-key.
Is it a compatibility problem of Thumb keyboard and eTcl for Windows
Mobile?

[screen shot]
http://www.interq.or.jp/japan/s-imai/etcl_bug.jpg

-----
Satoshi Imai

[suchenwi]

I have no experience with such keyboards, but box-shaped characters are
produced for such where no glyph is found in any font. Could be a
Carriage-Return (\x0D) for instance, if the keyboard thinks it must
send \x0d\x0a as usual in Windows files.

There's a way to find out: type, in the ETcl console,
cons e {bind .console <Key> {puts K=%K,k=%k,A=%A}
This will display keysym and keycode, and possibly printable form, for
each keypress, virtual or physical.
It taught me that the central "Return" key also sends a R3(134) event,
while the cursor keys also come with an R1(132) event, on my HTC
Magician pdaphone.

Best regards, Richard Suchenwirth

[s-imai]

Hi. Thanks for your answer.

I tried the code with HP's thumb keyboard.
Here is the result.

http://www.interq.or.jp/japan/s-imai/etcl_bug2.jpg

HP's thumb keyboard input \0x0\0xd as a Carriage-Return?

Best regards,
-----
Satoshi Imai

[suchenwi]

Interesting... so between keyboard and Tk, somewhere a \x00 (NUL)
creeps in. To C it wouldn't matter much, as it terminates the string,
but Tcl (in order to deal with arbitrary binary strings) converts it to
an unlawful UTF-8.. \xc0\x80, iirc...
Maybe Eric should be informed. Suppressing \x0 from keyboard should be
an easy matter.

[s-imai]

Hi.

When I added the following codes, the problem was solved. so Thumb
keyboard send \x0d\x0a ?

# an example
pack [text .text]
bind .text <Key> {
if {(%k == 0) && ("%A" == "\r")} break
}

-----
Satoshi Imai

[suchenwi]

One could generalize that solution to all text widgets, when such a
keyboard is in use:

bind Text <Key> {if {%k==0 && "%A" eq "\r"} break}

\x0d\x0a is the typical line-ending of text files in Windows, but I'm
not sure whether it is correct to produce both for a keyboard. In any
case, yet another workaround :-)

[s-imai]

Hi.
Thanks for your answer.

From now on, I would write the following codes.

bind Text <Key> {if {%k==0 && "%A" eq "\r"} break}

bind Entry <Key> {if {%k==0 && "%A" eq "\r"} break}

-----
Satoshi Imai

[Eric Hassold]

Hi,

I unfortunatly missed your reply in c.l.t, since I got the bad idea to
enable message threading in my newsgroup reader, so your late answer to
my announce got lost among all other messages sent to clt in the meantime.

I have already packaged and published a new pl9 release today, before
seeing about the iPaq Thumb key event problem you reported, so it
unfortunatly doesn't include fix for it. Please let me know if I can
send to you a test version to let you check it for this problem, so that
this get fixed, without requiring the proposed workaround anymore,
before pl10 gets out (soon).

Best regards,

Eric

s-imai a écrit :