PAI notes

Hi Blair,

I am sure these reports can go into the "dont do that category", but FWIW:
...

==========
Inspect

    temp := #foobar

The Instance Variables inspector allows you to change the contents of the
Symbol. Inspecting temp again shows the symbol was mutated. (D4's inspector
signals an error)

==========
Inspect

    temp := OrderedCollection new.
    temp add: temp
    temp

I think both inspectors do a good job of handling this. Setting an element
to nil, or adding an element deep in the cycle does show a refresh problem.
I know, "dont do that"? :)

==========
Inspect

    (1 to: 4) asOrderedCollection.

In the PAI edit pane, the contextMenu commands "Move to previous" and "Move
to next" are always disabled.

==========
Inspect

    temp := OrderedCollection new
    temp add: (temp1 := OrderedCollection new).
    temp

The defaultAction (ie double-clicking on one of the OrderedCollection
aspectAccessors) is to both expand/collapse the accessor and edit it.

=========
Inspect

    (1 to: 4) asArray

In the PAI, the "move to last"/"move to first" commands signal an Array dnu
#removeAtIndex:



Thanks,
Steve

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> I am sure these reports can go into the "dont do that category", but FWIW:
> ...

Thanks anyway.

>
> ==========
> Inspect
>
>     temp := #foobar
>
> The Instance Variables inspector allows you to change the contents of the
> Symbol. Inspecting temp again shows the symbol was mutated. (D4's
inspector
> signals an error)

This is "by design". The instance variables inspector is more similar to the
"basic inspector", in that it just shows the raw values of fixed and
indexable instance variables, which it gets/sets through #instVarAt:[put:]
and #basicAt:[put:]. Symbol does not block either of the mutating variants
of these low level-methods. If you open a basic inspector in D4 (or evaluate
<symbol> basicInspect in D5 to bring up the same basic inspector) you will
find the same behaviour. Symbols are inspected in D4 (and in D5 when using
the alternate inspector) as sequenceable collections, which goes through
#at:[put:]. The visual cue that this is a low-level view is that the
elements are displayed as integers rather than characters.
problem.
> I know, "dont do that"? :)

Again this is expected. The inspector is unable to see that change (there
being no events to hook), so a manual refresh will be required. This will be
bound to the F5 key in the release (which will mean changing the accelerator
for View/Test in the View Composer incidentally) to make this easier to
trigger, oh, and there will also be a refresh button on the toolbar of
Flipper.

I am interested in any cases of refresh issues following changes made in the
inspector itself, although it is worth noting that the instance variables
view is not meant to refresh in any sophisticated way. It should reflect
changes made directly to instance variables through it, but that is about
it.

>...
>     (1 to: 4) asOrderedCollection.
>
> In the PAI edit pane, the contextMenu commands "Move to previous" and
"Move
> to next" are always disabled.

Thanks, #863.

>..
>     temp := OrderedCollection new
>     temp add: (temp1 := OrderedCollection new).
>     temp
>
> The defaultAction (ie double-clicking on one of the OrderedCollection
> aspectAccessors) is to both expand/collapse the accessor and edit it.

I know this is strange, and indeed I think the tree's in Dolphin have always
exhibited that oddity. I'm tempted to disable the double click to
expand/collapse and add the #hasLinesAtRoot style to the tree so that there
is an expand/contract button for the root item. Comments?

> Inspect
>
>     (1 to: 4) asArray
>
> In the PAI, the "move to last"/"move to first" commands signal an Array
dnu
> #removeAtIndex:

Thanks, #864.

Regards

Blair

Hi Blair,

> > The defaultAction (ie double-clicking on one of the OrderedCollection
> > aspectAccessors) is to both expand/collapse the accessor and edit it.
>
> I know this is strange, and indeed I think the tree's in Dolphin have
always
> exhibited that oddity. I'm tempted to disable the double click to
> expand/collapse and add the #hasLinesAtRoot style to the tree so that
there
> is an expand/contract button for the root item. Comments?

This would suit me as I tend to use buttons to expand/contract a tree vs
double clicking.

As it stands, if I am editing an aspect the "side-effect" of expand/collapse
isnt noticeable, but if I want to expand/collapse, the "side-effect" of
editing does get in the way.

Thanks,
Steve

Blair,

> I know this is strange, and indeed I think the tree's in Dolphin have
always
> exhibited that oddity. I'm tempted to disable the double click to
> expand/collapse and add the #hasLinesAtRoot style to the tree so that
there
> is an expand/contract button for the root item. Comments?

I don't think there's ever very much point in turning off the
#hasLinesAtRoot style, unless the tree is going to be shown with at least
one level pre-expanded, since there's no indication whether there is
anything under the node to be expanded.

Indeed, there's no _real_ indication that the thing is a tree at all.

> Blair

    -- chris