[lmi] Re: allocating consecutive ids in XRC (was: UpdateUI problems in main_wx.cpp)

[Vadim Zeitlin]

 Hello again,

 This is the reply just to the first question of this thread, I'll post a
separate reply concerning the real issue once I understand it myself.

On Sat, 23 Aug 2008 16:48:27 +0000 Greg Chicares <address@hidden> wrote:

GC> > Unfortunately I don't have any satisfactory solution to it. There is
GC> > EVT_UPDATE_UI_RANGE() but nothing guarantees that the numeric values of 
the
GC> > corresponding ids are going to be consecutive, strictly speaking (even if
GC> > this is very likely in practice). And I don't think there is any way to
GC> > define a consecutive range of ids in the XRC. I hope Vaclav would correct
GC> > me if I'm wrong.
GC> 
GC> Writing one EVT_UPDATE_UI_RANGE entry would be more appealing than
GC> writing fifteen distinct handlers that all map to the same function,
GC> if it were feasible and guaranteed to work.

 Unfortunately the only possibility I see to make it work is rather ugly.
Let me explain what it is and why I think there is no way to avoid it:
to ensure that we have N consecutive ids we need to call wxWindow::
NewControlId(N). So the XRC code must know in advance the value of N, i.e.
the number of consecutive ids we need, even when allocating the first id
(or, in fact, any id of this range). So this information would need to be
encoded as part of the string id used in the XRC file, e.g. instead of
"edit_cell", "edit_case", "edit_class" we'd need to name the items
"edit_1_of_3", "edit_2_of_3" and "edit_3_of_3" or something like this.

 I.e. all strings ids which should be part of a range of consecutive values
must have a fixed, recognizable form from which both the length of the
range and the position of this item in the range can be extracted.

 The obvious problem with this approach is that if you now add a fourth
item to the range you have to rename all the existing ids (this doesn't
need any changes at the code level, just in the XRC, but is still painful).
Unfortunately I see no way around it, other than reserving more ids than
needed in advance...

 What do you think about this? Would it be useful to implement it?
VZ