Class browser disappearing source fix?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Class browser disappearing source fix?

Shaping-2
Will the mouse-over-tab-causing-method-source-to-disappear problem be fixed
soon?  It slows me down the most.


Shaping


Reply | Threaded
Open this post in threaded view
|

Re: Class browser disappearing source fix?

Andy Bower-3
Shaping,

> Will the mouse-over-tab-causing-method-source-to-disappear problem be
> fixed soon?  It slows me down the most.

Currently we have fixed the fact that mousing over the tabs when the
filter pane is pinned used to cause the source to disappear. It is
proving somewhat more difficult to prevent this from happening if you
have the filters unpinned and they slide out as the result of an
accidental mouse movement.

It is not really an option to change the SIOT to only slide out when
the mouse is clicked, rather just via a hover. The SIOTs in Microsoft
applications work this way and we treat this, then, as an informal
standard.

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.

--
Andy Bower
Dolphin Support
www.object-arts.com


Reply | Threaded
Open this post in threaded view
|

Re: Class browser disappearing source fix?

Schwab,Wilhelm K
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]