Re: [lmi] Re: allocating consecutive ids in XRC

[Greg Chicares]

On 2008-09-18 13:49Z, Vadim Zeitlin wrote:
[...]
> 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.
[snip discussion]
>  What do you think about this? Would it be useful to implement it?

No, I don't think it should be implemented. It's not worth the
contortions you'd have to go through. At this moment, lmi has
137051 lines of code; condensing fifteen of those lines into
one isn't worth a lot of effort, especially since the fifteen
are all clear, similar, and grouped together. This:

    EVT_UPDATE_UI(XRCID("edit_cell"            
),Skeleton::UponUpdateInapplicable)
    EVT_UPDATE_UI(XRCID("edit_class"           
),Skeleton::UponUpdateInapplicable)
    EVT_UPDATE_UI(XRCID("edit_case"            
),Skeleton::UponUpdateInapplicable)
    ...

is neither difficult to understand nor costly to maintain. I
just don't know how to make UponUpdateInapplicable() work:
that's the real problem.