Misc

Using beta 2.

A few oddities that I noticed while looking for something weirder (see my
other post) -- I suspect that:

    Presenter>>onSetFocus
    Presenter>>onKillFocus
    Shield>>onLeftButtonPressed:
    View>>wmWindowPosChanging:...

should not answer self.

Also both View>>wmWindowPosChanging:... and View>>wmWindowPosChanged:...
answer self with a comment to say "While we're restoring state it's not a
good idea to propagate this event", but ^ self is (if I understand what's
going on) equivalent to ^ nil, i.e. invoke the default windows handler.
Should it be ^ 0 ?

------

In the VC's PAI, attempting to copy-and-paste a menu from one view to
another fails.  I was attempting to paste over a dummy (sub-)menu created
especially for the purpose.  It looked as if the paste had happened but none
of the menu's sub-objects had been copied over.  C&P-ing the menus' "items"
collection on its own worked fine.  I suspect the problem might have been
with C&P-ing the menu's "text" since doing that on its own gives a walkback.
The String "text" aspect "Copy"s OK, but then it won't paste without a
walkback, in fact any use of the PAI's menu thereafter will walkback.  The
problem seems to be that although the String has been put on the (System!
Hurrah!) clipboard correctly, and:

        Clipboard current getObject

works fine, answering the String I'd expect, but:

        Clipboard current getObjectClass

fails as it tries to de-STB the class object.  To reproduce (doesn't need
the VC) evaluate:

        Clipboard current
                setObject: 'Hello';
                getObjectClass.

------

Is there any chance of adding "compilation failures" to the global browse
menu ?

------

I suggest changing the name of the "Visual Object Finder" tab in Flipper to
just "Object finder" since you can also just type an expression (e.g.
"Clipboard current") into the text area and accept it to find an object
directly.  The explanatory text would need to be expanded.

------

BTW, MoenTreeView doesn't implement #visualObjectAtPoint: so it won't work
with the visual finder yet.

------

Not a bug, just an observation.  I suspect that the changed definition of
String>>asNumber, Number class>>fromString, etc. may cause fairly
wide-spread problems.  I find that I've made quite a lot of use of it, and
have been relying on the fact that it answers 0 for non-numeric Strings
rather than throwing.  It's not a major problem for me (I've just replaced
my uses with:
    CRTLibrary default atoi: aString
which actually works rather better for me since it also strips
leading/trailing spaces and I'm not bothered by the 32-bit limitation).

------

In the CHB, start dragging a method, drag it over the method list, then hit
<ESC> to cancel the D&D operation (thanks for implementing that, btw).  The
method the dragee was over remains highlighted and won't stop being so until
you change class.

------

I think this is worth mentioning explicitly.  I've now managed to port
nearly all of my code to D5, and (with trivial exceptions like
PrerequisitesBrowserShell vanishing and the above-mentioned
String>>asNumber), I have so far found exactly zero (0) unexpected problems.
That's great!

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
Fixed as #589.

>
> Also both View>>wmWindowPosChanging:... and View>>wmWindowPosChanged:...
> answer self with a comment to say "While we're restoring state it's not a
> good idea to propagate this event", but ^ self is (if I understand what's
> going on) equivalent to ^ nil, i.e. invoke the default windows handler.
> Should it be ^ 0 ?

It is referring to the internal events, rather than passing the event on to
the default window procedure. I think in the case of WM_WINDOWPOSCHANGED
returning 0 would be better, but in the other case any non-integer return
value will do (although ^nil is clearer) since one probably does want to
pass it on for default processing, if only because there is no particular
reason not to.

>
> ------
>
> In the VC's PAI, attempting to copy-and-paste a menu from one view to
> another fails.  I was attempting to paste over a dummy (sub-)menu created
> especially for the purpose.  It looked as if the paste had happened but
none
> of the menu's sub-objects had been copied over.  C&P-ing the menus'
"items"
> collection on its own worked fine.  I suspect the problem might have been
> with C&P-ing the menu's "text" since doing that on its own gives a
walkback.
> The String "text" aspect "Copy"s OK, but then it won't paste without a
> walkback, in fact any use of the PAI's menu thereafter will walkback.
.....

Recorded as #591.

> Is there any chance of adding "compilation failures" to the global browse
> menu ?

Do you use it often enough for that to be useful?

>
> ------
>
> I suggest changing the name of the "Visual Object Finder" tab in Flipper
to
> just "Object finder" since you can also just type an expression (e.g.
> "Clipboard current") into the text area and accept it to find an object
> directly.  The explanatory text would need to be expanded.

That isn't really the point of it - one can easily type any expression in
any workspace and press Ctrl+I to achieve that effect :-). In fact the UI
presentation may be rather different anyway, depending on what we decide.

>
> ------
>
> BTW, MoenTreeView doesn't implement #visualObjectAtPoint: so it won't work
> with the visual finder yet.

Thanks, #592

> ------
>
> Not a bug, just an observation.  I suspect that the changed definition of
> String>>asNumber, Number class>>fromString, etc. may cause fairly
> wide-spread problems.  I find that I've made quite a lot of use of it, and
> have been relying on the fact that it answers 0 for non-numeric Strings
> rather than throwing...

Yes, I think that may be true, but it was wrong before and the effect of the
change will be obvious and is easy to fix.

>...  It's not a major problem for me (I've just replaced
> my uses with:
>     CRTLibrary default atoi: aString
> which actually works rather better for me since it also strips
> leading/trailing spaces and I'm not bothered by the 32-bit limitation).

Instead of:

    Number fromString: aString

(I refuse to give an alternative for String>>asNumber, since it is an
abomination), use:

    (Number readFrom: aString readStream).

Using a stream one can easily skip leading whitespace too, and trailing
anything is ignored.

> ------
>
> In the CHB, start dragging a method, drag it over the method list, then
hit
> <ESC> to cancel the D&D operation (thanks for implementing that, btw).

You wouldn't believe what a big change it was to do that - it necessitated
the (re)introduction of Interactors in fact.

>...  The
> method the dragee was over remains highlighted and won't stop being so
until
> you change class.

#592.

> ------
>
> I think this is worth mentioning explicitly.  I've now managed to port
> nearly all of my code to D5, and (with trivial exceptions like
> PrerequisitesBrowserShell vanishing and the above-mentioned
> String>>asNumber), I have so far found exactly zero (0) unexpected
problems.
> That's great!

Great. We were obviously too cautious :-)

Regards

Blair

Blair,

> > Is there any chance of adding "compilation failures" to the global
browse
> > menu ?
>
> Do you use it often enough for that to be useful?

Well, useful enough for *me*, yes.  I don't know about others.  I find that
I end up with compilation failures that I don't know about quite often (once
a week?), so I check quite a bit more often than that.  Especially at times
like the present.

I know that I can arrange for the Transcript to flash, but if I turn that on
then it flashes all the time (for other reasons -- e.g. because I
load/unload packages *often*) and the flashing is like "crying wolf" (just
more irritating ;-)

> (I refuse to give an alternative for String>>asNumber, since it is an
> abomination) [...]

I agree :-)

And (in retrospect) reel with shame to think that I used it at all --
actually only once (mostly I used Integer class>>fromString:), but that's
like being only a little bit pregnant.

> > ------
> >
> > In the CHB, start dragging a method, drag it over the method list, then
> hit
> > <ESC> to cancel the D&D operation (thanks for implementing that, btw).
>
> You wouldn't believe what a big change it was to do that - it necessitated
> the (re)introduction of Interactors in fact.

I do believe it.  I wonder how long it'll be before someone finds that they
*need* exactly the new functionality -- my guess is months at most.  I can't
exactly put my finger on it (and, in any case, haven't looked very closely
yet), but the new stuff "feels" right somehow.

> Blair

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > > Is there any chance of adding "compilation failures" to the global
> browse
> > > menu ?
> >
> > Do you use it often enough for that to be useful?
>
> Well, useful enough for *me*, yes.  I don't know about others.  I find
that
> I end up with compilation failures that I don't know about quite often
(once
> a week?), so I check quite a bit more often than that.  Especially at
times
> like the present.

One can choose 'Browse' from the CHB categories tree context menu at any
time, and it will open a method browser on all methods in that category.
Would that not be almost as convenient?

I'll just explain that the motivation for having certain searches on the
top-level browse menu is mainly because they are things that one might
commonly want to do, but which are hidden away in otherwise unexpected
places, and in one case (maybe more) have no other GUI command.

>
> I know that I can arrange for the Transcript to flash, but if I turn that
on
> then it flashes all the time (for other reasons -- e.g. because I
> load/unload packages *often*) and the flashing is like "crying wolf" (just
> more irritating ;-)

True. I have mixed feelings about the Transcript "flashing" option. I think
it would be better if one could arrange that if only flashed if no part of
the Transcript was visible on screen at all, but I don't know how to do
that. It probably needs some way to say that one is not interested in it
flashing for particular notifications, but that in turn would require a way
to categorise notifications, and it quickly estimates into an entire
industry.

> >...
> > You wouldn't believe what a big change it was to do that - it
necessitated
> > the (re)introduction of Interactors in fact.
>
> I do believe it.  I wonder how long it'll be before someone finds that
they
> *need* exactly the new functionality -- my guess is months at most.  I
can't
> exactly put my finger on it (and, in any case, haven't looked very closely
> yet), but the new stuff "feels" right somehow.

Indeed. We wouldn't have introduced Interactors (having removed them in the
interests of simplification) purely to support escaping out of drag & drop
with a key press, but it seemed that it was probably just the tip of an
iceberg. Certainly the whole mouse tracker implementation is cleaner now.

Regards

Blair

Blair,

Not really.  See below.

> I'll just explain that the motivation for having certain searches on the
> top-level browse menu is mainly because they are things that one might
> commonly want to do, but which are hidden away in otherwise unexpected
> places, and in one case (maybe more) have no other GUI command.

Hmmm... that's not at all what I'd have expected.  I'd have thought that the
main browser "point" was where all the global browsing options were
provided, with (for the sake of usability) appropriate duplications in other
contexts (such as the CHB, and the method browser itself).

So, I'd have expected that little-used global browsing options (and if you
want to consider compilation-failures to be little used, then I won't argue)
would appear only on the global browser.

As I've said before (but on a slightly different subject) I don't see why I
should have to open a CHB to browse for compilation failures *especially*
when the CHB I'm forced to open will not be used to view them.

> > I know that I can arrange for the Transcript to flash, but if I turn
that
> on
> > then it flashes all the time (for other reasons -- e.g. because I
> > load/unload packages *often*) and the flashing is like "crying wolf"
(just
> > more irritating ;-)
>
> True. I have mixed feelings about the Transcript "flashing" option. I
think
> it would be better if one could arrange that if only flashed if no part of
> the Transcript was visible on screen at all, but I don't know how to do
> that. It probably needs some way to say that one is not interested in it
> flashing for particular notifications, but that in turn would require a
way
> to categorise notifications, and it quickly estimates into an entire
> industry.

Agreed.  I just turn it off and have done...

> Indeed. We wouldn't have introduced Interactors (having removed them in
the
> interests of simplification) purely to support escaping out of drag & drop
> with a key press, but it seemed that it was probably just the tip of an
> iceberg. Certainly the whole mouse tracker implementation is cleaner now.

BTW, should interactors be added to the Command C-of-C ?  I'm thinking here
of handling keyboard accelerators that are bound to commands.   I'm not
saying I definitely think they should, just trying to get the role of
interactors clearer in my head.

> Blair

    -- chris

Blair,

> > I suggest changing the name of the "Visual Object Finder" tab in Flipper
> to
> > just "Object finder" since you can also just type an expression (e.g.
> > "Clipboard current") into the text area and accept it to find an object
> > directly.  The explanatory text would need to be expanded.
>
> That isn't really the point of it - one can easily type any expression in
> any workspace and press Ctrl+I to achieve that effect :-).

A small follow-on has occurred to me.

That isn't true if you are using a different kind of Inspector (as I am
now).

But I don't want to cut myself off from the flipper completely, so I find it
useful to be able to start a flipper and then "accept" an expression into
its "visual object finder" tab.  If you don't think that's important enough
to clutter the interface by changing the name/extending the text then I'd
probably agree with you (now); the point of this message is just to ask you
not to decide that the "accept" option is pointless in the V-O-F tab, and
disable it.

> Blair

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > > I suggest changing the name of the "Visual Object Finder" tab in
Flipper
> > to
> > > just "Object finder" since you can also just type an expression (e.g.
> > > "Clipboard current") into the text area and accept it to find an
object
> > > directly.  The explanatory text would need to be expanded.
> >
> > That isn't really the point of it - one can easily type any expression
in
> > any workspace and press Ctrl+I to achieve that effect :-).
>
> A small follow-on has occurred to me.
>
> That isn't true if you are using a different kind of Inspector (as I am
> now).
>

Shift+Ctrl+I then.

> But I don't want to cut myself off from the flipper completely, so I find
it
> useful to be able to start a flipper and then "accept" an expression into
> its "visual object finder" tab.  If you don't think that's important
enough
> to clutter the interface by changing the name/extending the text then I'd
> probably agree with you (now); the point of this message is just to ask
you
> not to decide that the "accept" option is pointless in the V-O-F tab, and
> disable it.

The V-O-F tab may not be there at all (it seems more useful to drive the
whole thing off the tool bar), we haven't decided yet.

Regards

Blair

Blair,

> Shift+Ctrl+I then.

(but that brings up the alternate inspector -- which is best left bound to
the BasicInspector)

Actually, on my machine Shift+Ctrl+I doesn't do anything from a normal
workspace (but shift+click-on-the-InspectIt-button works fine).  Is that
something that is supposed to work in the current beta ?

> Blair

    -- chris