Protocol browser.

Hi.

  Just curious about a piece of GUI in the Protocol Browser.

  When you open it and choose a protocol, in the rightmost pane you get a
list
of all the classes 'implementing' this protocol. This list is displayed in a
tree view
control but in which top level items don't have their little boxed
plus/minus icons
displayed for showing all of their child classes (hasLinesAtRoot tree view
property) . This gives the user no visual clue that the child classes can in
fact be
displayed here.

  As it is, the user can display child classes by either using the right
arrow on
the keyboard or double-clicking the item and have it expand but then the
class
browser windows pops up.

  Could the top level items in this control have their little boxed
plus/minus sign
displayed by default?

  The original class hierarchy browser tree view control didn't need
hasLinesAtRoot set as the user could expand the root element by
double-clicking it (which can be considered an 'intuitive' mouse interface),
but
here double-clicking does something else.

  Hope this helps,
    Jurko

"Jurko Gospodnetiæ" <[hidden email]> wrote in message
news:c1cq1h$6q4$[hidden email]...
>   Hi.
>
>   Just curious about a piece of GUI in the Protocol Browser.
>
>   When you open it and choose a protocol, in the rightmost pane you get a
> list
> of all the classes 'implementing' this protocol. This list is displayed in
a
> tree view
> control but in which top level items don't have their little boxed
> plus/minus icons
> displayed for showing all of their child classes (hasLinesAtRoot tree view
> property) . This gives the user no visual clue that the child classes can
in
> fact be
> displayed here.
> ...
>   Could the top level items in this control have their little boxed
> plus/minus sign
> displayed by default?
> ...

This is really a cosmetic bug in the TreeView when in #hasLinesAtRoot=false
mode. From our bug tracking system:

#1454: Tree with hasLinesAtRoot=false should expand root entries on restore
from saved image

Release Notes:

"This enhancement modifies the behaviour of the TreeView when
#hasLinesAtRoot is false such that when its contents are refreshed from its
model it will automatically expand all roots. This can be observed in, for
example, a new Class Hierarchy Browser which would previously open
displaying only root classes (e.g. Object), but which will now have those
root classes expanded to show first level subclasses. Similarly in the
System Browser when switching between packages the hierarchy tree will be
expanded, rather than displaying only Object as was usual in the past. In
general this increases the usability of the tree in hasLinesAtRoot=false
mode. See also #813."

Patch available from: http://object-arts.com/Lib/Update/Dolphin/5.1/1454.st

You might also want to install #1466 (URL formed using the same pattern as
above), which removes the lines at root from the view composer where they
are no longer required. This installs the new View Composer 'Vertical view',
but you can switch back to the horizontal view through the system options if
 you prefer the old style.

Both of these patches will be included in Patch level 4 (PL4). PL4 is a work
in progress, but details of available patches are listed at:
http://object-arts.com/Lib/Update/Dolphin/5.1/PL4.htm
These can be downloaded individually by forming up a URL as above. They
should, however, be regarded as hotfixes at present because they have not
been through full testing yet.

Regards

Blair

Blair McGlashan wrote:

[stuff deleted]

> Both of these patches will be included in Patch level 4 (PL4). PL4 is a
> work in progress, but details of available patches are listed at:
> http://object-arts.com/Lib/Update/Dolphin/5.1/PL4.htm
I just looked at the available patches and did not see an expected
enhancement of DBResultSet>>size. The actual implementation is rather slow
for Sybase databases. The size method should cache its size!

Best regards
Andreas

"Andreas Wacknitz" <[hidden email]> wrote in message
news:c1ditt$1gq4ad$[hidden email]...
> Blair McGlashan wrote:
>
> [stuff deleted]
>
> > Both of these patches will be included in Patch level 4 (PL4). PL4 is a
> > work in progress, but details of available patches are listed at:
> > http://object-arts.com/Lib/Update/Dolphin/5.1/PL4.htm
> I just looked at the available patches and did not see an expected
> enhancement of DBResultSet>>size.

You can only reasonably expect to see patches for reported issues. If its
not in our change tracking system, then it won't get patched. Things get
into our change tracking system when someone reports them, or when we
ourselves notice them.

>...The actual implementation is rather slow
> for Sybase databases. The size method should cache its size!

The size of a result set is not necessarily constant, depending on the
cursor type and isolation mode. Its true that DBResultSet could cache its
size in some instances, but not always*. On the whole we suggest avoiding
the use of #size because it could be very slow to calculate it even once. To
this end DBResultSet overrides a number of methods that would otherwise use
#size (e.g. #collect:). If you are using DBResultSets in conjunction with
generic components that send #size it is probably worth considering copying
out the data first.

*It is not likely that we will make this change ourselves, as we will only
be making bug fixes and minor enhancements to DB Connection now. We
recommend using ADODB for new DB work.

Regards

Blair.