[litwindow-users] Re: wxTextCtrl

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

yrs90 wrote:

 > I get the impression that wxTextCtrl support is currently limited to use
 > with a double value.  Why does wxTextCtrlBase::SetValue call
 > wxTextCtrl::SetLabel (rather than wxTextCtrl::SetValue) if the value 
isn't a
 > double?


I will investigate that. Might be a typo or it might be that for 
wxTextCtrl SetValue and SetLabel do the same thing.

wxTextCtrl should accept any data type. If its a double, it will switch 
to 'numbers only' mode automatically. Also it eliminates the need to 
convert your double from/to string, as is currently neccessary in the 
traditional programming world.

But it should be possible to use a string.

 > I'd like to assign a wxString to Value, but I'm having trouble 
figuring out
 > how to convert a wxString to an accessor in a wxTextCtrl rule.  I thought
 > wrongly that perhaps the following rule would work.
 >
 > PROP_GetSet(wxString, Info)
 > RULE("xrcTextCtrl.Value",
 > make_accessor(make_expr<wxString>("xrcList.Current.Info")))


I'll investigate.

 > - - -
 >
 > On a different tact, I was puzzled by the following code snippet.
 >
 >         // mark current m_value as invalid
 >         g_rapidUI->ValueChanged(GetWndAggregate()["Value"], false, 
false);
 >         // assign new accessor
 >         m_value=newValue;
 >         // and send change notification for new accessor
 >         g_rapidUI->ValueChanged(GetWndAggregate()["Value"], false);
 >
 > How/why does the first call to ValueChanged mark m_value as invalid? 
  I had
 > thought the notification was only required after updating. I notice 
that it
 > won't be solved until the second call, but I thought deferred 
resolution was
 > just for use when invalidating multiple values.


Actually the code does invalidate multiple values here. It is a bit 
difficult to see, because the 'Value' is an accessor itself.

The first NotifyChanged tells the RapidUI mechanism that the accessor 
that up to then pointed to the value has changed. RapidUI marks all 
rules that depend on that accessor as 'dirty'. Every rule has a list of 
accessors it depends on.

Next time they are evaluated, they will refresh their dependency list 
with new accessors.

Without the first ValueChanged call the dependency-list for the rules 
would still contain the old accessor, which is no longer valid after 
m_value=newValue.

RapidUI rules dependency has two flavors. Static dependency means that a 
rule depends on an accessor and that never changes its location and type 
in memory during the lifetime of the rule. The object pointed to by this 
accessor may change, but not the accessor itself.

Dynamic dependency otoh allows that the accessor itself changes.

Hajo