SelectionChangeEvent>>newSelection

Hi Blair,

SelectionChangeEvent>>newSelection (and #oldSelection too) will answer the
event (vs. nil or throwing an exception) if the collection is empty.  Not
sure if that's a bug or a feature??

BTW, I just noticed ListModel>>updateItem:[*] - THANKS!

Have a good one,

Bill

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

Bill

You wrote in message news:akl79i$1ju4bq$[hidden email]...
>
> SelectionChangeEvent>>newSelection (and #oldSelection too) will answer the
> event (vs. nil or throwing an exception) if the collection is empty.  Not
> sure if that's a bug or a feature??
>

I don't think so:

    event := SelectionChangeEvent new newSelections: #(); oldSelections:
#(); yourself.
    event newSelection "Ctrl+D = nil"
    event oldSelection "Ctrl+D = nil"

Can you explain when/how this occurs?

Regards

Blair

Blair,

> I don't think so:

I'm starting to think you're right.  ^aBool ifFalse:[ xyz ] isn't a
construct I typically use, and it looked like it would fall through.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:aklt0i$1k7fds$[hidden email]...
> Blair,
>
> > I don't think so:
>
> I'm starting to think you're right.  ^aBool ifFalse:[ xyz ] isn't a
> construct I typically use, and it looked like it would fall through.

Think of #ifTrue:/#ifFalse: as a message send like any other rather than a
control structure. All messages must return a value, so the same is true of
these, even though they are inlined by the compiler. In this case the return
value in the case of a missing branch is nil in Smalltalk-80, though I
believe the ANSI standard leaves it unspecified in order to allow for
optimization (incorrectly in my view).

Regards

Blair