>> Has anyone take a complete notebook, datebook or phonebook file
>> from the Zoomer and putting it on the OmniGo? Did it work? In other
>> words, do they use the same file format?
>>
>> Thanks,
>> -mat
The following is long and not of value everyone on this list.
In Summary: 1) you can run Zoomer Notebook on the OG to transfer text
to OG, but its a hack. 2) The relative size of Ink differs
between the Z and OG. 3) Many built-in features of
GEOS 2.0 SDK object libraries don't work the same when executed on
the OG. And finally, 4) The OG's firmware are in a much different
format that PC, or Zoomer, geodes.
I would be very interested to find out if any of you have
seen OG behavior different that described below.
1) Moving Data from the Z notebook to the OG notebook:
The Z notebook program does not "work" on the OG, but it will
run just well enough to cut and paste text from Z to OG.
The Z (Palm) notebook works as a "one shot" on the OG. You can view
a page, copy its text contents to the clipboard, EXIT the
Z notebook, move to the OG notebook and paste the data.
If you do not exit the Z notebook, and instead attempt to view
additional Z pages, the data will "appear corrupt", and my
continued uses usually hangs my OG. To run the Z file manager
and notebook at all requires copying the appropriate LIBS:
Page Object Library, PalmUI Library, Pen Support Library,
Print Spool Library, and Shell Library. The File Manager,
by the way, runs great. Also, I'm sure you can just
run an export to ascii tool on your Zoomer instead of this
kludge, but I after my Ink.
2) Ink coordinate space incompatibility between Z and OG:
Using the same procedures above, you can cut and paste (small)
amounts of Ink from Z's notebook to OG's notebook. However, the
Z's default coordinate space is approx 5 times larger than the
OG. Therefore any ink you copy from Z to OG will appear
5 times larger. Ink transfers to the clipboard appear to be bitmaped
in nature, as the the system runs of memory if you try to copy
even modest amounts of ink. (Say, a complete sentence) I am
"writing off" my ink, as I don't have enough data to justify
writing a tranlator. (pun intended).
3) Differences in Response to Z's SDK User Interface Libraries:
Available to GEOS programers are "Interaction Objects". These
are working menu strucures such as the "File", "Edit", and "Options"
menus that apear on many program objects. By simply calling
these objects, most of the User Interface work is done for you.
These menu objects written with the GEOS 2.0 SDK development kit, however,
do not respond well on the OG. Here is one example: I wrote
a simple ascii editor to modify config files. On the PC, and on
the Z, my "File" menu brings up a list of "Save, New, Save as, Close,
and Exit" objects. All I had to do was intercept the UI messages,
and respond accordingly. However, on the OG, this object funcitons
differently. When you tap the "File" menu, hoping to be presented
with the familiar list of options, the program sends the "SAVE" message,
and the file is written to disk. Tapping "File" a second time,
does bring up a list, but a different list: "Switch Document" (same function
as open), "Other->Copy To" (same as Save As), and "Rename".
You will notice the same behavior running the Z's (palm) notebook
on the OG. To fix my editor, I am writing the interaction user interface
from scratch. Are these details corrected on the OG SDK add on?
Does anyone know if the OG add on is available yet, and how much?
4) OG Firmware is not using run-of-the-mill goedes?
If you've put a file manager on your OG, notice that the firmware
apps (notebook, spread sheet, etc) are only 280 bytes long. I've looked
at them in a binary editor and they appear simlar to the first couple
hundred bytes of the standared *.geo files, but they end before
the library calls and executable code. Is this just a HP copy
protection feature? Is this an effect of the Execute in Place
feature? (if so, do MY *.geo apps run as XIP apps?). My understanding
is that the OG OS is GEOS 2.1, true?
Regards,
Ray Schuler