>We're setting the following:
OK. I do need to know why you need to do this, given the API for 3.0 or
later.
>fieldPtr->attr.editable
>fieldPtr->attr.underlined
Is this because of the PalmRez underline problem?
>fieldPtr->attr.justification
>fieldPtr->attr.usable
What wrong with FldSetUsable?
>fieldPtr->attr.visible
FldDrawField? FldEraseField?
>listPtr->attr.usable
OK. There's no API. Why do you need to do this?
listPtr->attr.visible
LstDrawList? ListEraseList?
and querying the following:
>menuPtr->attr.visible
Why?
>fieldPtr->attr.dirty
FldDirty?
>fieldPtr->attr.numeric
>fieldPtr->attr.editable
>fieldPtr->attr.usable
Why? There is FldGetAttributes too.
Also:
>myList->attr.hasScrollBar = true;
Why? I don't think this does anything except disable the scroll arrows as
a side effect. It was apparently intended to support poppup lists with
scoll bars to better facilitate scrolling. The current mechanisms, both
the scroll buttons and drag scrolling (pen down and move the pen above or
below the list) aren't great for long lists. But this ability isn't
available.
>Others probably modify the ListAttrType.search bit too.
I think this is an attribute that the tools should support. I don't think
this value need to change on and off while a program is running. The tool
should ideally check to make sure that there are items in the list and that
they are in alphabetical order.
Speaking to the list in general:
So the FldGetAttributes and FldSetAttributes routines are sort of a catch
all to allow developers to get access to field attributes without having to
provide a dozen API functions. It's not really a great routine because it
exposes internal attributes and the attribute structure is a fixed size
(which is basically full) and therefore not really extendable. The
alternative is to add a Get/Set routine for every external attribute. But
every API call that we add takes away memory from the dynamic heap, and we
have to bloat the ROM to add the function. So there's reluctance to adding
a lot of Get/Set routines. In the end, the Field code has both
FldGetAttributes and some individual Get/Set routines.
There are a lot of UI values which can be set by Constructor/ResEdit/Pilrc
for which we don't provide API calls. The expectation is that developers
shouldn't need to change an object while the program is running. To a
large extent, Palm expects folks to have multiple versions of UI objects
and to switch between them (Show/Hide) as opposed to mucking with objects.
It should be simpler for the UI designed, simpler for the localizers,
simpler for the code, and simpler for the API.
Hopefully that explains some of our decisions.
Keep the comments coming. And don't forget to mention why the values need
API exposure.
-Roger Flores
