Mostly minor findings

Hello,

Open workspace, select Workspace/Definitions... and enter, as selector,
one space. SmalltalkSystem>>promptForSelector:caption:allowWildcards:
will walkback trying to access first character of that string after
stripping blanks.

In CHB and SystemBrowser, when you are on 'variables' tab and there is
no variable selected, context menu has the Browse/Readers and
Browse/Writers enabled. Both of them walkback when selected.

Does 'Push up' refactoring work, when asked to push method up to Object
class ? It takes a very long time to do that.

In CHB select some method and then right-click on another one in method
pane. The right-click, even though it changes selection, does not update
method source pane.

I might have mentioned that before, but shouldn't 'File/New' option
of Active-X Control Browser be called 'File/New...' ?

In a class directly inheriting Object write method with the following
code: "[^self isNil] value not". It's result will obviously be "false".
Now, select "self isNil" and request "Inline Message" refactoring.
The method changes to "^false not", which is incorrect.

Write unary method and perform "Add Parameter..." refactoring to add one
parameter. After refactoring, undoing it will clear method source
pane.

After drag-and-drop of method from MethodBrowser to workspace, Edit/Undo
in that workspace is still disabled.

Create new class with instance variable 'x' and method #foo. In CHB
display #foo, switch to 'Variables' tab and drag the 'x' variable
into some workspace. #foo will be copied instead.

Open 2 CHBs. Create new class A inheriting Object and B inheriting A.
Add #foo method to the class A. In one of CHBs select class B and ask
for displaying inherited methods. Now, from the other CHB request
removing class A. You'll get a walkback because of assertion failure in
PackageManager>>onSystemClassRemoved:.

Open ClassHierarchyDiagram. Double-click somewhere on background. You will
get a walkback from MoenTreeView>>selection.

Open ViewComposer and, without creating any window, execute File/Test.
It will walkback after sending #hasVisibleStyle: to nil.

Open ViewComposer, create shell window and then delete it. Try to create
another shell window - ViewComposer will complain about changes that where
not saved, but You will not be able to save them, since there is nothing
to save (and File/Save is disabled).

I don't understand, why stripping of menu items in ViewComposer's
MenuComposer was implemented. It should be possible to use MenuComposer
just to create structure of menu, without having to rename all the items
to prevent them from stripping. Besides, I just know that some day I'm
going to need menu command with name starting with 'untitled '.

In ViewComposer, after editing context menu of some view, the Delete
command for subviews is disabled in all menus except for the context menu
of ViewHierarchy.

In CHB, if you try to create a class by selecting 'New...' command from
context menu of class hierarchy pane and that menu was opened by
right-clicking on an empty area (not a class name), prompt will ask for
name of new subclass of nil, but the class will not be created. Also, if
you do create new subclass of nil by typing-in it's definition on 'Class
definition' pane, it will show up in class hierarchy view, but you will
not be able to add subclasses to it.

If you open two ProcessMonitors (after switching-off "reuse if open") and
in workspace execute '[[] repeat] fork', then press Ctrl-break to abort
it, both ProcessMonitors will list that process as dead and will keep
reference to it for as long, as both are opened (closing one of them will
remove dead process from the other one). Now, if you try to inspect that
process by selecting Inspect from context menu, it might be difficult,
because selection under context menu disappears during refresh.

I know that this goes into the
"- Doctor, it hurts when I do that. - Then don't do that"
category, but if you try to inspect Main process in ProcessMonitor, you
will get 'Recursion too deep' walkback from Aspect class>>display:on:,
after which Dolphin becomes unstable.

When is 'Refactorings' submenu of context menu in method source pane of
CHB enabled ? It seems to be disabled even though Method/Refactorings of
main menu is enabled.

#([]) in method causes invalid access to memory location from compiler.

It has already been reported, but I'll have to second the request of
previous poster. The fact, that compiler in 5.0 mangles comments and
strings with diacritic ("national") characters is a bit of a problem. I
have quite a lot of Polish text in some of my code and would rather avoid
loosing that. It did work in previous versions, by the way. I guess I can
work around that with some pre- and post-processor to compiler, but since
there might be others in similar situation, it would be better to have
that working out-of-the-box.

Artur Zaroda
[hidden email]

Artur

Many thanks for all your bug reports, they are all recorded and will appear
in the list at:

http://www.object-arts.com/Beta5/Defects%20reported%20in%20D5%20betas%20(Lis
t).htm

I'll just comment on a couple of them

You wrote in message
news:[hidden email]...
> ...
> Does 'Push up' refactoring work, when asked to push method up to Object
> class ? It takes a very long time to do that.

It does work, but it will indeed take a long time to push something up into
Object (not a very likely refactoring in practice), because it does an awful
lot of work with all those subclasses. In fact it will parse every method in
the system at least once. If you interrupt it with Ctrl+Break
you'll get some idea. It occurs to me that in beta 2 it might not be
displaying the wait cursor for the whole time, at least if you have been
prompted at all, but this is certainly not the case in our current image
since we have revised the wait cursor management. It could probably do with
a progress dialog.

> In CHB select some method and then right-click on another one in method
> pane. The right-click, even though it changes selection, does not update
> method source pane.

The source pane will eventually update when the context menu is closed (as
I'm sure you've noticed), but it is nevertheless odd. The Method Browser
does not do this, so it must be something to do with the CHB. We'll look
into it.

> ...
> In a class directly inheriting Object write method with the following
> code: "[^self isNil] value not". It's result will obviously be "false".
> Now, select "self isNil" and request "Inline Message" refactoring.
> The method changes to "^false not", which is incorrect.

That's a bug report for Don & John. I'll pass iton.

>
> Write unary method and perform "Add Parameter..." refactoring to add one
> parameter. After refactoring, undoing it will clear method source
> pane.

Yes, because the selection is lost when the method is deleted. I'm not sure
it is necessarily feasible to do anything about that, but I will record it
nonetheless.

>
> After drag-and-drop of method from MethodBrowser to workspace, Edit/Undo
> in that workspace is still disabled.

I'm not sure it is feasible to do anything about that either, since the undo
is implemented by the Windows control and it probably doesn't regard the
programmatic insertion of text as an undoable action.

> ...
> I don't understand, why stripping of menu items in ViewComposer's
> MenuComposer was implemented. It should be possible to use MenuComposer
> just to create structure of menu, without having to rename all the items
> to prevent them from stripping. Besides, I just know that some day I'm
> going to need menu command with name starting with 'untitled '.

:-). I suppose you are right, but I'm not sure why you would want to create
just the structure?

>
> In CHB, if you try to create a class by selecting 'New...' command from
> context menu of class hierarchy pane and that menu was opened by
> right-clicking on an empty area (not a class name), prompt will ask for
> name of new subclass of nil, but the class will not be created.
>...

That doesn't reproduce for me now, but there has been some work in that area
of the system since the release of beta 2 (there is now a 'Create Subclass'
dialog in place of the 3 prompters).

> ....
> When is 'Refactorings' submenu of context menu in method source pane of
> CHB enabled ? It seems to be disabled even though Method/Refactorings of
> main menu is enabled.

The refactorings all operate on the current selection, so if there is no
selection in the workspace then it is not enabled (though maybe it would be
better if it auto-selected the word under the cursor). Also if the method
has been modified it is disabled.

> ...
> It has already been reported, but I'll have to second the request of
> previous poster. The fact, that compiler in 5.0 mangles comments and
> strings with diacritic ("national") characters is a bit of a problem. I
> have quite a lot of Polish text in some of my code and would rather avoid
> loosing that. It did work in previous versions, by the way. I guess I can
> work around that with some pre- and post-processor to compiler, but since
> there might be others in similar situation, it would be better to have
> that working out-of-the-box.

Hmmm, that is interesting. The compiler's syntax colouring has not been
changed at all since D4, so that would suggest it is something to do with a
global setting saved down with the RTE. You might not expect this to be a
problem, since the whole text of the source pane is replaced, but the RTE
seems to maintain some global font table that pops into the RTF whether one
likes it or not (and as such it is mightily difficult to get rid of). If
that extra stuff includes a specific charset setting, then perhaps that
would explain it.

Regards

Blair

Hello,

On Fri, 15 Feb 2002, Blair McGlashan wrote:

I've worked things out. It turns out that the same happens to 4.0 on XP.
I'm sorry, I should have checked that before posting.

All I had to do, was set 'Language for non-Unicode programs' option
(which is supposed to do something to menus and dialogs) to 'Polish',
and then change the "Script" of default font for Workspace and
SystemFolder from "Western" to "Central European".

While investigating this I've spotted a couple of things:

""""""""""

Depending on "Regional and Language options", RichTextEdit>>plainText
and RichTextEdit>>plainText:from: may give different results. For example:

rte:=RichTextEdit show.
rte text: #[185] asString asRichText.
rte plainText

could be different from:

rte plainTextFrom: rte textRange first to: rte textRange last

This explains, why sometimes "national" characters work, when they are
compiled in text of method and don't, when inside expression compiled
in workspace. It has nothing to do with compiler, it's just that
RichTextEdit control sometimes decides to read diacritic characters
as question marks.

As a work-around, one may remove RichTextEdit>>plainTextFrom:to: and
use TextEdit>>plainTextFrom:to:, which might be slower, but seems to
work just as well.

""""""""""

Executing 'Compiler syntaxColors: Compiler defaultSyntaxColors' in fresh
image changes the way methods look (larger font), which means, that
defaults are, by default, not set.

""""""""""

I've notices that View>>showShell does:

shell := ShellView show extent: self defaultExtent.

instead of:

shell:=ShellView new create extent: self defaultExtent.
shell show.

Is there a reason for that ?

""""""""""

"RichTextEdit show" does not execute RichTextEdit>>onViewOpened.

""""""""""

Artur Zaroda
[hidden email]

"Artur Zaroda" <[hidden email]> wrote in message
news:[hidden email]...

 [re: Loss of national characters compiling in workspaces]
> I've worked things out. It turns out that the same happens to 4.0 on XP.
> I'm sorry, I should have checked that before posting.
>
> All I had to do, was set 'Language for non-Unicode programs' option
> (which is supposed to do something to menus and dialogs) to 'Polish',
> and then change the "Script" of default font for Workspace and
> SystemFolder from "Western" to "Central European".
>

I think we should put that in the FAQ on the Wiki.

That is unfortunate, however the RichTextEdit control has caused us no end
of problems (it does seem to be very buggy), so I am not entirely surprised.

> As a work-around, one may remove RichTextEdit>>plainTextFrom:to: and
> use TextEdit>>plainTextFrom:to:, which might be slower, but seems to
> work just as well.

Yes, unless the RTE contains a couple of megabytes of text!

>
> """"""""""
>
> Executing 'Compiler syntaxColors: Compiler defaultSyntaxColors' in fresh
> image changes the way methods look (larger font), which means, that
> defaults are, by default, not set.

Thanks #650 and fixed.

No, it is all wrong (it also loses focus, and doesn't set the extent
correctly. It should be sizing the shell so that its client area is the
defaultExtent of the enclosed view, and only showing the shell as the very
last step. #649, and fixed.

> "RichTextEdit show" does not execute RichTextEdit>>onViewOpened.
>
> """"""""""

#onViewOpened is sent from the Presenter side, and is not triggered off a
Windows event. This means it is not sent when Views are acting as their own
Presenters. This is a inconsistent, and we need to think about what it
should do/how it should be done. #651.

Regards

Blair