Andy,
> The best solution for our point of view would be to prevent the slidimg
> out action from propagating a filter change event until the actual
> selection is changed. This is proving more than trivial, however.
My money is on you rather than the bug :) However, this reminds of a
couple of questions that I've asked you over time. Perhaps one of these
forces is causing some of the trouble.
First, with respect to events and comparision/search policies, I have
long wondered whether they are required to act much like control rods in
a nuclear reactor. Comments?
With value-changed events, there has been some suggestion (probably on
clsd) that the windows controls are not very good about giving out the
correct value "during the changed event". Or was it during the changing
event?? Either way, I wonder whether it might make sense to have a new
#changedTo: event (or whatever you would decide to call it) that would
carry the new value vs. relying on the control to answer sanely to
#value. Another option (perhaps preferred) would be to use Smalltalk
code to ensure that #value always answers the "new" value.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]