Minutia

Hi Blair,

The method comments below contain the phrase "modifies the and answers the
receiver".  The receiver is modified in each case, but, these methods answer
the new elements instead of the receiver.  Part of me hates to bother you
with these things...

Have a good one,

Bill



!Collection methodsFor!

addAll: newElements
 "Include all the elements of the <collection> argument, newElements, as the
receiver's elements.
 Answer newElements.
 Note that this modifies the and answers the receiver, not a copy.
 newElements can actually be any object which understands #do:."

 newElements do: [:each | self add: each].
 ^newElements! !
!Collection categoriesFor: #addAll:!adding!public! !

!SequencedGrowableCollection methodsFor!

addAll: newElements
 "Include all the elements of the argument, newElements, as the receiver's
elements.
 Answer newElements. Note that this modifies the and answers the receiver,
not a copy."

 ^self addAllLast: newElements! !
!SequencedGrowableCollection categoriesFor: #addAll:!adding!public! !

!ListModel methodsFor!

addAll: newElements
 "Include all the elements of the <collection> argument, newElements, as the
receiver's elements.
 Answer newElements. This implementation is not particularly efficient since
it falls
 back on adding the new elements one by one. This is to ensure that the
#add:atIndex
 notifications are correctly triggered.
 Note that this modifies the and answers the receiver, not a copy."

 newElements do: [ :each | self add: each ].
 ^newElements! !
!ListModel categoriesFor: #addAll:!adding!public! !

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:9ad1vs$4o5n6$[hidden email]...
>
> The method comments below contain the phrase "modifies the and answers the
> receiver".  The receiver is modified in each case, but, these methods
answer
> the new elements instead of the receiver.  Part of me hates to bother you
> with these things...

Thanks Bill. Errors in comments are still errors, just in the "cosmetic"
category, and consequently these probably won't be patched until the next
release.

Regards

Blair

While refactoring (i.e., getting it right the Nth time), I came across
these minute modifications to the base classes that might be worthy of
incorporation into Dolphin:

If you have a focussed TextEdit presenter anywhere and a menu or toolbar
item responding to #pasteClipboard, the command will be enabled even if
the underlying control is in read only mode and thus will not accept
pastes.  The following two methods can be used to fix this.


TextEdit>>queryCommand: aCommandQuery
        "Enters details about a potential command for the receiver into
aCommandQuery"

        | command |
        super queryCommand: aCommandQuery.
        command := aCommandQuery commandSymbol.

        "This is the change."
        command = #pasteClipboard ifTrue: [
                aCommandQuery enabled: self canPaste.
        ].

        (#(copySelection cutSelection clearSelection) identityIncludes:
command)
                ifTrue: [
                        aCommandQuery
                                receiver: self;
                                enabled:  self hasSelection.
                                ^true].

        (#(find findReplace) identityIncludes: command)
                ifTrue: [aCommandQuery enabled: self textLength>0. ^true].

        command == #findNext ifTrue: [
                aCommandQuery enabled: self findDetails notNil].

        command == #apply
                ifTrue: [aCommandQuery enabled: self isModified].

        command == #undo
                ifTrue: [aCommandQuery enabled: self canUndo].!

TextEdit>>canPaste
        "Answer whether the presenter can paste from the current contents of
        the clipboard."

        ^self isReadOnly not and: [ Clipboard current isTextAvailable ]! !


The findDetails: method of TextPresenter is incomplete.  I believe this
is used to support the find and replace dialogs.  One possible
implementation is as follows:



ValuePresenter subclass: #TextPresenter
        instanceVariableNames: 'findDetails'
        classVariableNames: ''
        poolDictionaries: ''!


TextPresenter>>findDetails
        ^findDetails.!

TextPresenter>>findDetails: anArray
        "Sets the findDetails instance variable to anArray. The Array has four
elements:
        (findWhatString, isForwardsBoolean, isCaseSensitiveBoolean,
isWholeWordBoolean).
        Ignored at present."

        findDetails := anArray.! !


Although Bill's point is very minute, I think the one I sent in back in
September has it beat:


In the method comments for the class AdvApiLibrary, there are (Character
codePoint: 160)'s included in the text.  This is preventing some of my
tools from working properly and it may not be ANSI-conform.  I think
that the comments must have been copied in from a different source.  Now
you know.


However, it's not a prize I want to keep.


Keith Alcock



Bill Schwab wrote:

Keith

You wrote in message news:[hidden email]...
Thanks these have been recorded as defect numbers 175 and 176 for inclusion
in the next Live Update.

> Although Bill's point is very minute, I think the one I sent in back in
> September has it beat:
>
> In the method comments for the class AdvApiLibrary, there are (Character
> codePoint: 160)'s included in the text.  This is preventing some of my
> tools from working properly and it may not be ANSI-conform.  I think
> that the comments must have been copied in from a different source.  Now
> you know.

Sorry this got overlooked. Now we have a much better bug tracking system
this should be much less likely to happen in future. This is now recorded as
defect 177.

Regards

Blair

Keith,

> While refactoring (i.e., getting it right the Nth time),

You have an off by one error here: at least in my experience, it's never
right until the (N+1)th iteration :)

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]