Post by yrs90Very 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.
Post by yrs90I 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.
Post by yrs90I 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
Post by yrs90State>(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
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click