There's a difference between fixing bugs and rewriting code. The suggestion was to switch to a gadget. That's not a simple bug fix. A gadget would require much more manipulation by my set of library routines.
Essentially what I built was an "object" (using OOP terminology) that uses standard Palm OS form objects. This provided a means to take advantage of all the built-in functionality of Buttons (like: group ids, events, etc.). I combined that with List functionality to create a very clean UI that the user raves about. So, now they have a user-driven "widget" that requires ZERO coding on their part that can be "linked to" (I also built a "link" capability that uses FrmGotoForm ... which is a "go to" form, but it returns to whichever form "linked" to it so the called "object" form doesn't have to worry about where to go). At execution time, a dynamically created multiple row horizontal "list" of buttons is positioned next to a List of text selections. What the user ends up with is a minimum-tap method to select any one of several possible values for EACH entry in the associated list. Note that the user could define any number of these "widgets" on a given form, and each could be any number of rows. Anyway, the "object" uses 98% supported Palm OS form objects, events, etc. What's missing is the ability to keep the Palm Button draw logic from displaying button borders. And, of course, the infamous inability to create a scrollbar dynamically. Both of those capabilities seemed like oversights by the Palm OS implementors back in the early days. Let's face it ... if the Constructor can build a frameless button, why shouldn't the dynamic UI API be able to do the same thing? The same logic applies to scrollbars. And, you could even include dynamic Tables in that, but I don't want to muddy the waters with yet another discussion about "sane" UIs. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
