I commented several weeks ago on the enhanced Emulator UI Mgr Data Access
error messages which are welcomed restrictions, but are causing problems
because of code implemented prior to those restrictions. For the time
being, I have been forced to turn off the setting for UI Mgr Data Access.
Unfortunately, that prevents me from uncovering any "valid" form based data
access violations.
This is a formal request to provide relief for several situations that
exist. I developed a system for a client that is very dynamic in nature
(the form content varies depending on execution time decisions by the user).
Since there were no provided access methods to certain data, I directly
accessed some structures. I need a way to replace those direct accesses
with functionality provided by Palm OS. If I have overlooked an access
method, please direct me to the correct one. Note that all the following
notes refer to a robust application that works just fine and dandy. The
problem is that the Emulator is restricting access to certain data.
1) There is no LstGetListChoices so I can retrieve the LstSetListChoices
pointer I stored in *each* dynamically populated list. I used
lstp->itemsText. Emulator 4.0 burps on access to that.
2) There is no access method to retrieve either the list id or the popup
trigger id from the frmPopupObj object. Currently, I use popupP->listID and
popupP->controlID. At execution time, I know of no other way to tie the
list id to the popup trigger, other than defining another table of my own.
That's undesirable because it creates a source code maintenance effort,
which should not be necessary for information that already resides in the
form. I also have many popup triggers associated with many lists on many
screens. The effort to change all that code to build and maintain my own
dynamic list is huge.
3) There is no clean interface to the frame attribute of buttons.
Currently, I use ctlP->attr.frame. There needs to be an external access to
that, and several other attributes. For instance, I can't set the usable
attribute of the frmScrollBarObj without directly accessing
barP->attr.usable. Also, the control group id is not accessible.
4) I can't "clone" a button (I copy the whole button object to a work area,
dynamically change the information I need modified, then use CtlNewControl
to add it at its appropriate location on the screen). There is some
intricate logic in that routine that self-manages the size, location, and
frame of each button depending on the choices made at execution time by the
user. When I try to copy the button object to the work area, Emulator
complains that I'm trying to access memory that belongs to the form manager.
I haven't tried to point to a dynamically added button and "clone" it from
there (use CtlNewControl, then modify the newly added button) because it
would require a rewrite of a complex routine. Even then, it would run into
the problem mentioned above with the frame attribute.
I have already gone through the entire application and cleaned up the other
"invalid" accesses. Some of Palm OS's new functionality helped in that
aspect, such as FrmGetObjectIdFromPtr (which I had to simulate for pre-4.0
versions, but at least there's a way to get what I needed).
If I'm missing some functionality, or there's another way to get the
information I need without violating rules, please let me know. If no
relief is forthcoming in a near future release, I will have to somehow
convince my client that it will be worth their time and effort to rewrite
major sections of a tightly integrated application to compensate for some of
the above mentioned lack of functionality.
Regards,
Terry
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
