self halt in a #printOn:

Hi,

I want to find out how to modify the way an object is displayed in a
listbox (the books in the MVP NightSchool sample). Since by default it
seems to display whatever #printOn: does,  I inserted a 'self halt.'
in Book>>printOn.

As soon as the 'breakpoint' was reached and I asked to run the
debugger, the system froze. I tried again and got the same result.

Is it a bad idea to do a halt inside a printOn method or what? O:-)

Thanks

Fernando,

> As soon as the 'breakpoint' was reached and I asked to run the
> debugger, the system froze. I tried again and got the same result.
>
> Is it a bad idea to do a halt inside a printOn method or what? O:-)

There are a few places where inserting a halt can cause problems, and
#printOn: can be one of them.  When you reach the breakpoint and start the
debugger one of the first things it tries to do is display information about
the object that contained the breakpoint - using the object's #printOn:
method.  This causes another breakpoint ... I'm sure you get the picture :-)

> I want to find out how to modify the way an object is displayed in a
> listbox (the books in the MVP NightSchool sample).

The easiest way is probably to add a temporary method that replicates
#printOn: and use it to test your changes.  Call it from a workspace ....

b := Book title: 'ABC'.
s := String writeStream.
b myPrintOn: s.
s contents inspect

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian, Fernando,

> The easiest way is probably to add a temporary method that replicates
> #printOn: and use it to test your changes.  Call it from a workspace ....
>
> b := Book title: 'ABC'.
> s := String writeStream.
> b myPrintOn: s.
> s contents inspect

Defining (if only temporarily) a #debugPrintString should also allow
debugging #printOn:.

As for modifying the way things appear in lists, #getTextBlock is
probably the best way to go.

Have a good one,

Bill

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

On Sun, 06 Mar 2005 18:03:29 -0500, Bill Schwab
<[hidden email]> wrote:


>As for modifying the way things appear in lists, #getTextBlock is
>probably the best way to go.

I'm not sure how to use it, could you give an example?

Thanks

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

> I'm not sure how to use it, could you give an example?

A number of the Dolphin views [1] use a block [2] to define how certain
operations [3] are to be performed.  One of them specifies how an object is
to be displayed, this is known as the #getTextBlock.  The default
implementation is normally to use the object's #printString but you can
change the block to display anything you want.  For example

l := ListPresenter show.
l list: (Array with: 1@2 with: 3@4 with: 5@6).

will show a list with three points displayed using their normal #printString
format.  If you now evaluate

l view getTextBlock: [:object |
    object y printString , '<>' , object x printString]

you will change the list's #getTextBlock and the points will be displayed
using the new format.

[1] Various Lists, Trees, StatusBars and their associated bits and pieces
(like ListViewColumn)

[2] Note that you can use any object that responds to the #value: message -
that's why the default is not a block ...

(ListPresenter show) view getTextBlock

answers a class, BasicListAbstract, and that has a class side #value: method
that answers an objects #displayString:   Instances of Message (or is it
MessageSend?) can also act as substitutes for a block.

[3] like  these, but note that not all views support all (or many) of these

#getTextBlock - answers the text to be displayed
#getImageBlock - answers an image to use
#getContentsBlock - how to get the correct contents.  Used in ListViewColumn
to extract the correct part of an object to display in each column.
#sortBlock - defines how to sort a list

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.