Misc

The SB doesn't use the configurable fade factor for its hierarchy view.

------------

MethodBrowser has deprecated method #methodList[:], but in fact the method
used to be called #methodsList[:]  (with an 's').  Oh, and the class comment
still refers to the old method name.

------------

    (IDispatch createObject:'Scripting.FileSystemObject') displayString

answers '(member not found)'.  Similarly,

    (IDispatch createObject:'Scripting.FileSystemObject') drives
displayString

answers

     '(Invalid number of parameters.)'

------------

Debugging something from a workspace (F11) leaves the workspace inactive and
unselectable  while the debugger's running.

------------

I have one tool which uses an embedded MethodBrowser.  It is initialised in
the tools #model: with code like:

    | list |

    list := self model ...<some derived list>...
                "list is an OrderedCollection in a special order,
                not easily expressible as a SortedCollection"

    self methodsPresenter beNotSorted.    "don't discard the initial order"
    self methodBrowserPresenter list: list.

where #methodBrowserPresenter is the instance of MethodBrowser created in my
#createComponents, and which links up to sub-views of mine named 'methods'
and 'source'.  And where #methodsPresenter is implemented as:

    ^ self methodBrowserPresenter presenterNamed: 'methods'.

(I'm sorry, that's a bit confusing).  Anyway, before beta3 this worked OK,
but now the list is getting sorted when the view is first shown.
MethodBrowser>>onViewOpened now tells itself to #beSorted:.

How do I now get the effect I'm looking for, of opening a MethodBrowser on a
list of methods without rearranging them please ?

------------

It doesn't seem to be possible to set the properties of a package's image
stripper from the "properties" PAI in the PB.  The changes get made but are
just discarded.  I'm not sure if this is intended to be possible, anyway.
It *is* possible to do the same things from the Lagoon wizard, and from the
PAI invoked by it's "custom options" button.

    -- chris

Chris

Thanks for the bug reports. They will appear in my consolidated report once
I have entered them all.

You wrote in message news:[hidden email]...
> ------------
>
> Debugging something from a workspace (F11) leaves the workspace inactive
and
> unselectable  while the debugger's running.

This is (indirectly) by design. In b3 shell's are disabled while a command
initiated from them is running (see Shell[View]>>performCommand:), therefore
the workspace (its shell) would have been disabled when the 'Debug-It'
command was actioned.


Regards

Blair

Blair,

> > Debugging something from a workspace (F11) leaves the workspace inactive
> and
> > unselectable  while the debugger's running.
>
> This is (indirectly) by design. In b3 shell's are disabled while a command
> initiated from them is running (see Shell[View]>>performCommand:),
therefore
> the workspace (its shell) would have been disabled when the 'Debug-It'
> command was actioned.

Is there any chance that #debugIt from SmalltalkWorkspace could be made an
exception to this rule ?

I find it a bit of a nuisance not to be able to interact with the other
objects living in a workspace while I'm debugging one of them.  A similar
small problem appears with nested debuggers -- i.e. debugging an expression
from inside a debugger makes that debugger useless for the duration.

It *looks* (i.e. I've tried it and after a full 30 seconds, nothing seems to
have broken) as if something as simple (and ugly) as adding:
    self topShell view enable.
to SmalltalkWorkspace>>debugItIfFail: would do the trick.

> Blair

    -- chris