Error in "The Dolphin Smalltalk Companion"

I believe there is an error in "The Dolphin Smalltalk Companion" in Chapter
4 on the

DriverDialogPresenter>>model
...
    namePresenter model aspectTriggers: #nameChanged. "This line is missing"
....

This line isn't mentioned in the book, possibly because it should be
inserted later on page 67.

Additionally the following method is needed:

DriverDialogPresenter>>nameChanged
    "The first or surname changed, so the name must be retrieved."
    namePresenter value: self model name.

Without this code (which is present in the chapter 4 package on the CD) the
nameTextPresenter isn't updated after changing the text in the
firstnamePresenter or the surnamePresenter.
Nice book though.
Have fun,
-Leo-

"giro" <[hidden email]> writes:

Aaargh, couldn't you have posted this one day ago when I was checking
and rechecking my code to find out why it didn't work :-)


>
> Additionally the following method is needed:

I dont' think so, I don't have it.

>
> DriverDialogPresenter>>nameChanged
>     "The first or surname changed, so the name must be retrieved."
>     namePresenter value: self model name.

Btw, I found out by looking at the chapter source too, but I might as
well have gone to:

http://www.tedbracht.co.uk/ 

where the errata is. Strange that I didn't find a reference to this
page at www.aw.com/cseng, I might have overlooked it but I think I
looked pretty hard for it.

--

Vennlig hilsen

Syver Enstad

Ted Bracht posted some corrections to his book on his site :
http://homepage.ntlworld.com/ted.bracht/id21.htm

----
Dominique Dartois

Hi Leo, Syver and Dominique,

I've asked AW to add the link from their website to mine, unfortunately they
haven't updated it yet.

If you find any other errors or have suggestions for improvement, please let
me know and I'll update the errata.

Thanks,

Ted

> "giro" <[hidden email]> writes:
(Sorry about the alias, my name is Leo)

> Aaargh, couldn't you have posted this one day ago when I was checking
> and rechecking my code to find out why it didn't work :-)

..and I was browsing the pages to see where the missing code was...

> I dont' think so, I don't have it.
You're right. It doesn't need it.
However, my code complained once not having this method. Anyhow, it's
working fine without now, as I expected from the beginning.

> http://www.tedbracht.co.uk/

Thanx, I didn't know about that page yet!

> Vennlig hilsen
> Syver Enstad

Halsningar,
-Leo-

Something I came across later while studying the DSC. If I go to the
View Composer, choose a new dialog instead of shell, and put a Boolean
Presenter (a Radio Button) on the view from Resource tool box, and then
select test from the file menu (F5 doesn't seem to work for dialogs,
only views) push the radio button and dolphin freezes. The only way I
get out of this is to terminate the entire process.

Is this just my image or does anybody else get this behaviour too?




--

Vennlig hilsen

Syver Enstad

Hi Syver,

"Syver Enstad" <[hidden email]> wrote in message
news:[hidden email]...
> Something I came across later while studying the DSC. If I go to the
> View Composer, choose a new dialog instead of shell, and put a Boolean
> Presenter (a Radio Button) on the view from Resource tool box, and then
> select test from the file menu (F5 doesn't seem to work for dialogs,
> only views) push the radio button and dolphin freezes. The only way I
> get out of this is to terminate the entire process.
>
> Is this just my image or does anybody else get this behaviour too?
>
I got the same behaviour (/problem). By pressing ctrl-break I managed to get
into the debugger. That allowed me to see the stack:

09:27:00, 12 February 2002: 'User Interrupt'
Signal>>signal
DevelopmentSessionManager(SessionManager)>>onUserBreak
ProcessorScheduler>>userBreak:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
RadioButton(ControlView)>>defaultWindowProcessing:wParam:lParam:
RadioButton(View)>>defaultWindowProcessing:
RadioButton(View)>>onLeftButtonReleased:
RadioButton(View)>>wmLButtonUp:wParam:lParam:
RadioButton(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
DialogView(View)>>isDialogMessage:
DialogView(ShellView)>>preTranslateMouseInput:
DialogView(View)>>preTranslateMessage:
InputState>>preTranslateMessage:
InputState>>pumpMessage:
InputState>>loopWhile:
InputState>>mainLoop
[] in InputState>>forkMain
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in BlockClosure>>newProcess

 From the 'RadioButton(ControlView) upwards, you can see that the virtual
machine is trying to execute something in reaction to you pressing the radio
button (executing the niladic block). As that block is empty, it ends up in
a loop. And as the dialog sits on top of the other screens, keeping focus,
all the rest is frozen as well.


>
>
>
> --
>
> Vennlig hilsen
>
> Syver Enstad

Hope this helps,

Ted

"Ted Bracht" <[hidden email]> writes:

> Hi Syver,

> I got the same behaviour (/problem). By pressing ctrl-break I managed
> to get
>
> into the debugger.
> Hope this helps,

Thanks, I had forgotten about the Ctrl-Break possibility. Nice to know
it's not my image that is thrashed.

Errata for the DSC book:
It is maybe me, but the container view that I inserted for the Radio
Buttons in chapter 4 had a white background, I didn't see any
reference to how to get it to use the normal system dialog color like it is
shown in the book. Here's how I managed to get a good background
color:
ContainerView
set backcolor aspect to
(SystemColor fromId: COLOR_3DFACE) # stolen from the reference view
container view

PS: You have to import the pool of win32constants to avoid compilation
error when saving it.

--

Vennlig hilsen

Syver Enstad

Syver.

> Errata for the DSC book:
> It is maybe me, but the container view that I inserted for the Radio
> Buttons in chapter 4 had a white background, I didn't see any
> reference to how to get it to use the normal system dialog color like it
is
> shown in the book. Here's how I managed to get a good background
> color:
> ContainerView
> set backcolor aspect to
> (SystemColor fromId: COLOR_3DFACE) # stolen from the reference view
> container view
>
> PS: You have to import the pool of win32constants to avoid compilation
> error when saving it.

You can use:

Color face3d

instead. It's less typing and doesn't require the Win32Constants pool.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Syver Enstad" <[hidden email]> wrote in message
news:[hidden email]...
> Something I came across later while studying the DSC. If I go to the
> View Composer, choose a new dialog instead of shell, and put a Boolean
> Presenter (a Radio Button) on the view from Resource tool box, and then
> select test from the file menu (F5 doesn't seem to work for dialogs,
> only views) push the radio button and dolphin freezes. The only way I
> get out of this is to terminate the entire process.
>
> Is this just my image or does anybody else get this behaviour too?

This is a know problem in 4.0 (recorded as "102: Radio Buttons in a
DialogView cause an infinite loop". It is a manifestation of a bug in
Windows' dialog navigation whereby it can go into an infinite loop sending
WM_GETDLGCODE messages in certain circumstances when it is attempting to set
focus to the 'next' control (or a specific control). It sometimes occurs due
to the absence of a WS_EX_CONTROLPARENT style (which is necessary to allow
the navigation to drill down into nested views), or when the window in
question is active but no control has focus, or (as in this case) when it is
attempting to move focus to the next group, but there is no "group" defined.

You can fix the problem as follows:
    1) Edit the 'CompositePresenter.OK Cancel Button block' in the
ViewComposer. Tick the isGroupStop style of the OK button. Save it.
    2) Edit the 'BooleanPresenter.Radio button' resource in the
ViewComposer. Again tick the isGroupStop style of the OK button and save it.

If you now re-test, you should find the looping behaviour has stopped,
however when adding more than one radio button you will probably want to
remove the group-stop style from all but the first in the group.

Regards

Blair

"Blair McGlashan" <[hidden email]> writes:
<everything I could ever want to know about the dialog preview
problem>

Thanks Blair, most illuminating.
--

Vennlig hilsen

Syver Enstad