That's not the line giving you trouble - it's trying to create the
menu, which wants to "belong" to a window. Change that to a dialog for
now, and the problem will go away.
This is a discussion on Menu glitch with VW 7.4nc - Smalltalk ; I'm currently tutoring an OO programming unit at Monash University (Australia) and we're using VW 7.4nc. The worksheets we're using for the tutes haven't been changed since the last time I tutored this unit, in 2003, but we're using the ...
I'm currently tutoring an OO programming unit at Monash University
(Australia) and we're using VW 7.4nc. The worksheets we're using for the
tutes haven't been changed since the last time I tutored this unit, in
2003, but we're using the latest VW - and perhaps there lies the problem.
The students have been having problems with one of the worksheets
covering menus and dialogs, and I've been at a loss to explain to them
why the following code is not working.
My thought it that it's a minor glitch in VW, possibly one which is only
evident in the context of workspace code, with the menu needing to
attach itself to the current window, and somehow selecting the (just
dissapeared) dialog box as its target - but perhaps the examples are
using a now outdated style?
The following code works fine in the workspace, until you uncomment the
4th line of text.
------------------------------------------------
| number menu operation |
number := 5.
"uncomment the next line to cause a walkback"
"number := (Dialog request: 'pick a number' initialAnswer: '') asNumber."
Transcript show: 'Number entered is ' , number printString; cr.
menu := Menu labels: 'double\halve' withCRs values: #(#double #halve).
operation := menu startUp.
operation = #double ifTrue:
[Transcript show: number printString , ' times 2 = ' , (number * 2)
printString; cr.].
operation = #halve ifTrue:
[Transcript show: number printString , ' divided by 2 = ' , (number /
2) asFloat printString; cr.].
------------------------------------------------
Thanks for any wisdom -
Steve
That's not the line giving you trouble - it's trying to create the
menu, which wants to "belong" to a window. Change that to a dialog for
now, and the problem will go away.
jarober@ wrote:
> That's not the line giving you trouble - it's trying to create the
> menu, which wants to "belong" to a window.
Yes - that was my interpretation of the problem too. That's was I was
trying to convey with "with the menu needing to attach itself to the
current window, and somehow selecting the (just dissapeared) dialog box
as its target" - though perhaps not clearly enough.
> Change that to a dialog for
> now, and the problem will go away.
This is just example code though, not part of a project, so I don't need
the problem to go away - I just want to be able to answer my student's
plaintive cries of "why doesn't my code work".
I presume it's a bug in VW - perhaps thread related, a missing
semaphore? - but I'm ready to be told I'm calling methods in a way that
is now obsolete, and that there's a better way to achieve the same effect.
I've just been poking around, and have made a sort of fix:
In Menu->startUp, after the 2nd line,
activeController := Window activeController.
add the following line:
(activeController isNil) ifTrue: [activeController := Window
allGeneralInstances first controller].
and the problem goes away. I don't, however, know if this is a true
bugfix, or if I've just dodged the race condition which caused the first
bug, which will reappear under different timing conditions on another
computer.
Also, while I was looking around that area, I noticed that
Menu->startUpAt: aPoint
does nothing but call
Menu->startUp
and shed a tear for the poor little Point, which goes into the method
with such high expectations, only to be ignored. It must be terrible to
have your dreams smashed like that. "What's the Point?" it must say to
itself, "What's the Point?".
Steve
Steve,
take a look at Menu>>startUpForView: aView, in the GF/ST Base parcel.
I added it as a fix to GF/ST for this reason. A little pushing got it
incorporated into the version of GF/ST in the distribution, I think
since 7.1.
All the best,
Steve
"Steve Taylor" <smt2@ozemail.com.au> wrote in message
news:ci08g.600$S7.324@news-server.bigpond.net.au...
> jarober@ wrote:
>> That's not the line giving you trouble - it's trying to create the
>> menu, which wants to "belong" to a window.
>
> Yes - that was my interpretation of the problem too. That's was I
> was trying to convey with "with the menu needing to attach itself to
> the current window, and somehow selecting the (just dissapeared)
> dialog box as its target" - though perhaps not clearly enough.
>
>> Change that to a dialog for
>> now, and the problem will go away.
>
> This is just example code though, not part of a project, so I don't
> need the problem to go away - I just want to be able to answer my
> student's plaintive cries of "why doesn't my code work".
>
> I presume it's a bug in VW - perhaps thread related, a missing
> semaphore? - but I'm ready to be told I'm calling methods in a way
> that is now obsolete, and that there's a better way to achieve the
> same effect.
>
> I've just been poking around, and have made a sort of fix:
>
> In Menu->startUp, after the 2nd line,
>
> activeController := Window activeController.
>
> add the following line:
>
> (activeController isNil) ifTrue: [activeController := Window
> allGeneralInstances first controller].
>
> and the problem goes away. I don't, however, know if this is a true
> bugfix, or if I've just dodged the race condition which caused the
> first bug, which will reappear under different timing conditions on
> another computer.
>
> Also, while I was looking around that area, I noticed that
>
> Menu->startUpAt: aPoint
>
> does nothing but call
>
> Menu->startUp
>
> and shed a tear for the poor little Point, which goes into the
> method with such high expectations, only to be ignored. It must be
> terrible to have your dreams smashed like that. "What's the Point?"
> it must say to itself, "What's the Point?".
>
>
>
> Steve
>
>