Palm and Pocket PC

By Larry Choice

Summary of the versions of SF 5.x and workability with Palm & PocketPC 2002 (PPC)

(this list is not all inclusive, but represents what I personally know or have tried. Since my applications have been based on static tables, I have not done anything with linking/updating to external data bases.

5.0 Not really functional with PPC, so I did not ever use this version. No Palm OS 5 support.

5.1 Finally working with PPC although with several bugs. Still no Palm OS 5.

Palm: No problem with button & bit map stacking on Palm regardless of OS version

PPC: Limitations: max of 15 tables, Get user name not working - therefore problem creating registration/shareware model. Proper display of filtered tables on DropLists or ListBoxes requires workarounds, extensions not working for PPC. There are other issues, but these were the main ones for me.

5.2 Update for Palm OS 5 which did not really work. I never really used this version.

5.2.1 Finally working support for Palm OS 5.

Palm: Button bitmap stacking problem returned - requires different stacking order depending on whether Palm device uses OS newer or older than 4.0. No support for Palm OS older than 3.5. (However Visor and Visor deluxe, OS 3.1H3M, seem to be OK and I also don’t see the control stacking problem on the Visor.).

PPC: Some fixes for PPC, but several steps back. GetUserName and GetUserID now work. Some questions remain about functionality/reliability of extensions on PPC. SF Form Designer automatically creates *.cdb files for PPC -- this is a complete disaster. Rebuilds can take forever. But even worse, this feature creates the *.cdb tables in reverse order; e.g. an alphabetical list of records displays in z-a order. I experienced the case where a fully "clean" and working application from SF 5.1 would not even load on the PPC with out crashing. More info on how to solve these problems below.

Developing Satellite Forms applications for Palm and PocketPC 2002 (PPC) from a common source. (Things Puma Tech forgot to tell you)

General Info:

0. thoroughly read and understand the ReadMeEE.txt files supplied with Sat Forms. You should reference the SF 4.1, 5.1 and 5.2.1 files.

1. SF version: Unfortunately, to fully support Palm OS 5 devices and PPC you are going to need to be able to run both SF 5.1 and 5.2.1. To do this on a single computer, you will need to be using the Win2K OS on the PPC. ( I assume WinXP will work but I have not tried it). You will need to create two separate user environments on the PC and install SF 5.1 on one user and SF5.2.1 on another user.

2. Screen layout and overall app design. While SF does provide common dual platform support of the basic app functionality, table schema, filtering and linking, some things have to be different between the two platforms. Most of these differences center around the different screen sizes and resolutions. For a professional looking application, you will need to lay out each form separately for the Palm and PPC. Fortunately this is an area in SF that seems to work very well, all control sizes and positions can easily be specified differently for each platform with no functional problems.

3. Device support:

Palm: Per Puma Tech SF 5.x versions no longer support devices with Palm OS prior to 3.5; however the Visor and Visor Deluxe with OS 3.1H seem to be OK. To support Palm OS 5, you must use SF 5.2.1. With SF 5.2.1 there is a control stacking bug which causes stacked bitmaps and buttons to work differently depending on whether a Palm device uses OS4.0 and newer or OS 3.5. To stack buttons and bitmaps in OS 3.5 the button must be behind the bitmap; for OS 4.+ the button must be in front of the bitmap.

PPC: At this time only devices with PocketPC 2002 OS are supported.

4. Image files: beginning with SF 4.1 SF has supported both gray scale and color images. (See details in the SF 4.1 ReadME) If you import an application from an older version of SF, SF will automatically create a set of image files and place them in a separate Image folder on your PC. I strongly recommend that you rename all the image files to some logical name instead of keeping the generic "BitmapXXXX.bmp" supplied by SF.

5. Color: While SF claims you can use 16 bit color (assuming you can afford the memory usage), I have never been able to get it to work.

Supporting Dual Platforms:

1. Property Space: With the advent of dual platform support a critical part of the SF designer is the Property Space window. By default this appears at the right of the Designer screen. When you select an individual control, the control properties are displayed in the Property Space window. If you have enabled the designer for dual targets, the Property Space window will show a series of checkboxes for each control. These checkboxes indicate the properties inheritance value for an individual control property. For a given form and control, the inheritance box may be checked on both platforms, one platform only or neither. By default, when a control is created on a form, the box will be normally checked, indicating a global property. This parameter will then apply to both platforms. (You will note that the global box is never checked for control position and size). If you want a different property for a parameter such as button label or control action, then you should uncheck the global box. You can then select the individual platform and specify different values for this property. For example, this makes it easy to have a button run a different script for the Palm and the PPC.

2. Forms: By default, a form is always created for both platforms when you insert a new form or paste in a form copy. You can later delete a form from a platform version; thus you can have similar but different forms for the two platforms. (Note: this is generally not necessary, but it is possible).

3. Controls: When you insert or copy & paste a new control onto a form, the control will, by default, appear in both platforms and have its global inheritance enabled. You can then selectively enable, disable and edit global properties or even delete the control entirely from one of the platforms.

4. Vestigial Controls and Forms: If you delete a form from one platform, the form name will still show in the form list on that platform, but the name will be "grayed out." I have coined the term "vestigial form" for this situation. This means the form is not active in the currently viewed platform, but is still present in the other platform version. Once installed in an application, to fully delete a form, you must select each platform and delete the form from each platform individually. If you want to restore a "vestigial form" to active status, right mouse click the name and select "include in project". A similar situation applies to individual controls on a form. If you delete a control from only one platform, it will still show in the control list, but it will be "grayed out". The lets you have the same form on both platforms, but uses different controls between the two platforms. As with forms, to completely delete a control, you must delete the control separately from each platform version.

5. Scripts: Certain scripts are global in nature and must be the same on both platforms. This includes AfterOpen, AfterLoad, OnPenDown, OnKey, etc. Scripts unique to an individual control (e.g. OnClickButtonA) can be different between platforms. (For that matter the action associated with a control can be different between platforms -- on the Palm a button could jump to another form, while on the PPC the same button could run a script). Using a button to run a script will actually allow you to create different versions of the global scripts for the two platforms. For example in an AfterOpen script you can add the line "ButtonA.ExecAction" and specify a different script for ButtonA in each platform.

Major Bugs and workarounds:

Palm: Things seem to be fairly stable with SF 5.2.1 and OS 5 support is mostly OK, although there may still be some remaining bugs. The biggest Palm problem for me is the control stacking issue which precludes a common solution for both OS3.5 and newer versions. (I can't use the button sandwich, because I have too may buttons - over 100 in some cases on an individual form).

PPC: There are two major issues here for me.

1. Custom controls which I use only on the Palm target, still confuse the PPC run time. For example I use the custom LSListBox control on my Palm versions. Even if this control is "deleted" (in vestigial form) on the PPC version the PPC app crashes immediately upon loading. This new PPC bug caused my working 5.1 applications to fail on SF 5.2.1 on the PPC. Note: this a problem between Sat Forms and PocketPC when any custom control is used for a Palm version of an application. It is not a problem per se with LSListBox which still works just fine on the Palm. Solution: A)Use only standard controls for each platform or B)Use different forms for each platform. I discovered that if I put the LSListBox on a form which is "deleted" from the PPC version then the compiler and runtime don't get confused. I created two forms e.g. ListPalm with LSListBox and ListPPC with standard ListBox. Then I delete the ListPalm form from the PPC target and delete ListPPC form from the Palm target. Although in-elegant this works for me.

2. Table (database ordering). SF 5.2.1 generates the PPC tables in reverse order from the Palm. For example an alphabetical list appears in the desired a-z format on the Palm, but in z-a order on the PPC. In my programs, this causes more than just esthetic problems. Stepping through the records of a table with some conditional actions behaves strangely depending on the table order and the conditionals. You would think that all you need to do on the PPC is re-sort the table to get into the proper order. If you do this in a startup script, you should see the proper ordering the first time you open a list on a form. Unfortunately, once you sort the list, performance on the PPC is wiped out. For example changing a filter on a large table normally takes < 3 sec on the PPC for the new filter to be applied and a filtered list to display. After sorting the new filter takes 15-20 seconds for the list to display. "Unsorting" the table by sorting back to the original order, does not solve the performance problem. The only way to recover the performance is to quit and re-load the app. Solution: this works and has been confirmed by SF tech support, but it's ugly. Note: any method of converting SF 5.2.1 *.mdb files into *.cdb files for the PPC results in bad ordered tables. However if you use *.mdb tables from SF 5.1 and convert using CERDKInst or even manually download and convert, the tables are OK. I have found that after finishing a SF 5.2.1 app I can still re-open the app in ver 5.1 of the SF designer. So here's the process restated.

1) finish the development in SF 5.2.1 for Palm and PPC.

2) close SF 5.2.1 and switch to SF 5.1. (this will need to be on a different system or a different user in Win2K)

3) (recommended) Create a new copy of the completed source (e.g. MyApp.sfa) in a different folder from the SF 5.2.1 source.

4) Open new copy of app, "save as" to create new set of tables and re-build PPC version.

5) Use CERDKInst to convert and install the 5.1 *.mdb files to *.cdb files on the PPC. (you can also install the SF 5.2.1 versions of MyApp.pda and MyApp.exe at this time.) Once you convert these files, you can manually copy the *.cdb files to your desktop for inclusion in a set of files for installation.

6) If not done in step 5, install the MyApp.pda and MyApp.exe files from the SF 5.2.1 version onto the PPC device. This completes the process.

Miscellaneous quirks, features and bugs:

1. Startup on PPC: Initial program load on the PPC takes several seconds on a large program. During this load time the screen is blank and there is no way today to display a "wait" message to the user.

2. File sizes: Minimum database size on the PPC appears to be 128K bytes. There is no fix for this at this time.

3. Memory Card support: On the PPC, you can move the entire application to a memory card and it will still work. There is a catch -- startup takes forever, more than a minute, during which the PPC screen is blank (see 1 just above). After loading, functionality and performance is normal. On the Palm (Sony Clié with memory stick) if you copy a complete app to the launcher folder on the memory stick, tapping on the icon in the memory stick list will automatically load the app into main memory and run the program. This takes a fairly long time, because all the files are re copied into the main Palm memory. When you exit the program, the files are left in the Palm main memory and need to be removed manually.

4. Installation on PPC: This is a little more complex than the Palm and the current support from SF requires a two pass install. You must distribute all the files in the folder: "Program Files\Satellite Forms 5.2\Redist\PocketPC 2002\Runtime Installer" and have your user run the "Setup.exe" program from this set. Then you need to create an install set for your program which uses the Sat Forms CeRdkInst.exe installer. (See the SF Readme for info on how to do this.) You could also just distribute a set of you program files (You should use the *.cdb files created under SF 5.1), and have your users manually copy the app files to the PDA using ActiveSync.