A few miscellanea more

A very few very minor things...

--------

In the CHB, use the back-arrow to navigate back from a class-side method to
an instance method of the same class.  The Instance/Class "buttons" (or
rather tabs) don't update to reflect the change.

--------

I don't know whether this is a *really really* minor cosmetic issue, or a
slightly less minor problem in multi-column list views.  In the CHB the
first column of the selector list is a couple of pixels too wide; that lets
the highlight on the current method name peek out to the left of the
private/public icon.  In fact the highlight is actually showing on a second
copy of the name of the method, as you can see by expanding the first
column.  The *possible* problem might be that the primary column of a list
view now seems to require that the list view's #getTextBlock be nil as well
as its own #getTextBlock in order for that column not to have any text.
This doesn't apply to other columns, and seems to be a change since D4.  Of
course, that might well be by design, in which case the CHB thing is purely
cosmetic.

--------

Also very minor.  The release notes show #821 (cosmetic improvements to
tab-order in the Create Subclass Dialog(s)) as closed and fixed, but there
don't seem to have been any changes to the tab order (though the class-name
*is* now preselected -- thanks).

--------

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> A very few very minor things...

Ah, then the feeling I was getting that the goose is getting fat would
appear to be spreading :-)

> --------
>
> In the CHB, use the back-arrow to navigate back from a class-side method
to
> an instance method of the same class.  The Instance/Class "buttons" (or
> rather tabs) don't update to reflect the change.

Hmmm, I hadn't noticed that. Thanks, #871.

> --------
>
> I don't know whether this is a *really really* minor cosmetic issue, or a
> slightly less minor problem in multi-column list views.  In the CHB the
> first column of the selector list is a couple of pixels too wide; that
lets
> the highlight on the current method name peek out to the left of the
> private/public icon.

The column width had to be increased to avoid a more severe cosmetic issue
on Windows XP (with XP look'n'feel enabled). Any narrower and the icons of
the selected method "disappear".

>...In fact the highlight is actually showing on a second
> copy of the name of the method, as you can see by expanding the first
> column.  The *possible* problem might be that the primary column of a list
> view now seems to require that the list view's #getTextBlock be nil as
well
> as its own #getTextBlock in order for that column not to have any text.
> This doesn't apply to other columns, and seems to be a change since D4.
Of
> course, that might well be by design, in which case the CHB thing is
purely
> cosmetic.

Actually it was exactly the same in D4 (including the selectors in the first
column). I can't remember why it is like that, but it must have been
deliberate since there is a comment in the #onDisplayDetailsRequired: method
that specifically describes this behaviour: "If in report mode the column's
get text block is used unless the request is for the primary column and its
text block is nil, in which case the view level block is used"

>
> --------
>
> Also very minor.  The release notes show #821 (cosmetic improvements to
> tab-order in the Create Subclass Dialog(s)) as closed and fixed, but there
> don't seem to have been any changes to the tab order (though the
class-name
> *is* now preselected -- thanks).

Sorry, it seems that the non-refactoring version had been overlooked. This
dialog has been changed anyway, and now includes the ability to choose the
superclass (or more normally to change it from that initially set), this
being useful when adding classes in the System Browser which are subclasses
of classes that are not in the hierarchy for the selected package.

Regards

Blair