[litwindow-users] Re: RULE expressions?

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> Very helpful explanations.

And very helpful questions for me too. I'll certainly go back to this 
email exchange when I continue writing the documentation for the library.

> I am having trouble with using an enum as the data type in a property.  I
> get an unresolved external symbol.  How do I declare the enum?
> BEGIN_ADAPTER_ENUM is an empty macro.

Not implemented yet. Currently you must treat enums as ints when it 
comes to the library. The idea behind BEGIN_ADAPTER_ENUM was to allow to 
provide the list of enums and also a list of strings representing the enums.

> I want to try the following rule.  I hope to enable a menu entry only if my
> state is equal to idle which is an enum value.
> 
> class myClass
> {
> enum State m_state;
> }
 > BEGIN_ADAPTER(myClass)
 > PROP(m_state)
 > END_ADAPTER()
 >
 > RULE("MyMenuXRCID.Enable", make_expr<enum State>(m_state) == 
make_const<enum
 > State>(IDLE))
 >
 > Is this valid?

The rule is perfectly valid, except that you must currently use ints. So

RULE("My...", make_expr<int>(m_state)==make_const<int>(IDLE))

Note that you are creating a rule that directly references m_state. This 
is okay, but limits the possibilities you have with rules. The rule 
above binds the .Enable property to the variable m_state, which must 
exist at compile time.

Alternatively you could write

RULE("My...", make_expr<int>("m_state")==(int)IDLE))

Two things:
a) make_const<int> is not neccessary, because after make_expr<int> at 
the beginning of the == expression, the compiler should be able to 
deduce the type automatically. See 
lwbase\src\unittest\constraintstests.cpp for more examples.

b) By using "m_state" rather than m_state you pass in the name instead 
of the reference. The difference is similar to the difference between 
static and dynamic linking. Passing m_state is like static linking. The 
name is resolved at compile time. Passing "m_state" is dynamic linking. 
The name is looked up at runtime and searched for in the data collection 
you pass to RapidUI with AddData or operator <<. The later allows 
writing reusable rules.

The only problem you probably will run into in the example above is the 
fact that you are trying to enable/disable a menu item. Other than 
windows, menu items are created on the fly when they are needed and are 
not really windows. I am not sure if they can be accessed by the RapidUI 
mechanism. Or, hm, in fact, I am almost certain they cannot.

The name lookup works as follows:

for all windows you pass to RapidUI with AddWindow
    if window.name == name
       return found
    for all children of window (recursively)
       if children.name == name
          return found

But since menu items are not children of windows they will not be found.

This might be added, but my design vision aims at a different direction. 
I would like to create action items, like delphi has them. An action can 
be enabled and disabled and be triggered. Action *elements* are elements 
that can trigger an action. Menu items are action elements, as are 
buttons. RapidUI will bind action elements to actions and automatically 
enable/disable all action elements depending on the enabled state of the 
action itself.

So a listbox might expose an Add and a Delete action. Several buttons, 
menu elements etc... will be bound to these actions. And several rules 
govern the enabled/disabled state of the action.

Summary:
For menu items I would stick with the traditional "OnUpdate" method for 
now. For all other elements (buttons, textboxes etc...), creating a 
Enable rule works fine.

Regards

Hajo