Ed Leafe wrote:
On Nov 10, 2005, at 3:28 PM, Paul McNett wrote:
Huh? You want dDropdownList to behave differently from other controls
WRT Hit?
It already does, based on the changes we made a few weeks ago. For
list boxes and such, Hit only fires when you double-click or press
Enter on them. Dropdowns fire Hit when you select a new value.
Ok, I've got to look at that. However, my overriding point is that ValueChanged
is a completely different event from Hit. When you want something to happen when
the control's value changes, you should bind to ValueChanged, not Hit.
The thing that Hit should do is whatever the main purpose is for that control.
With lists, you are selecting an item, and when you double-click or press enter
on an item, the item is selected, so a Hit is generated. For dropdown lists, it
is the same except just moving to the item selects it. So, I think without
looking at it the controls are behaving correctly WRT Hit.
Oh, maybe you meant to say:
> This is the case only in dropdowns; on other list controls,
you can
> change the value without firing *ValueChanged*.
ValueChanged should always fire when the value changes, whether
through user interaction or programatically. However, with most
controls this will happen only when the control loses focus (when
flushValue() is called).
When you scroll through a list, the value changes without losing
focus. flushValue() should certainly be called in these cases,
I agree, BTW. I just wanted to point out that it doesn't currently work this way
for all controls. In my mind, flushValue() should happen immediately for all
controls except dTextBox and dEditBox. Do you agree?
since
other controls depend on the list. Imagine a list box with client
names, along with several fields with client info. As you scroll
through the list, with focus remaining on the list, shouldn't the
controls update as the client changes?
Yep, however one could argue that that shouldn't happen in the same callstack
for performance reasons if you have lots of controls to update, but yes I agree.
Even if the controls aren't data-bound to each other like in your demo, the
ValueChanged needs to be raised upon the value changing, so that if some other
control is interested in responding to that, it can.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
