[XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item().
Jens Thoms Toerring
jt at toerring.de
Thu Jul 3 17:45:26 EDT 2008
To subscribers of the xforms list
On Thu, Jul 03, 2008 at 04:53:23PM -0400, Jason Cipriani wrote:
> Let's say I have a menu with these items, created in fdesign:
> 1. Red
> 2. Green
> 3. Blue
> So the IDs (returned by fl_get_menu) are 1, 2, and 3.
> If I use fl_delete_menu_item() to remove the second item (id = 2),
> then I've observed that the IDs of the other menu items do NOT change,
> leaving the menu like this:
> 1. Red
> 3. Blue
> This is convenient and is what I want to happen, I was pleasantly
> surprised when I noticed it. However, I was always under the (possibly
> incorrect) impression that menu item IDs *always* corresponded to the
> index of the item (so Blue would have been changed to 2 rather than
> remaining as 3).
> Is this ("Blue" keeping it's ID of 3) a bug that coincidently worked
> out well for me? Or is this intentional behavior that I can rely on in
> the future?
No, I don't think it's a convenient bug but intended that way.
The value that is returned is actually not necessary identical
to the index of the entry, the structure for an entry has a
member for storing the value to be returned. The index of the
item is just the defalt value set at creation. But you can over-
ride this value at creation of the menu, see "%xn" at the end of
page 201 of the PostScript documentation for 0.89, all that's
required is that it's positive (but I don't know off-hand if 0
is regarded as positive). So I guess you can rely on the beha-
viour and should cry "BUG" if you find it behaves differently;-)
Best regards, Jens
\ Jens Thoms Toerring ________ jt at toerring.de
To unsubscribe, send any message to
xforms-leave at bob.usuhs.mil or see:
List Archive: http://bob.usuhs.mil/pipermail/xforms and
More information about the Xforms