Class Testing

Dear smalltalkers,

I want to prototype in the future using smalltalk, but therefore I
absolutely needs capacities to log classbehavior in separate logs.

So what I did was creating my own TranscriptShell derived class
ClassTestLog, but things don't turn out easy at all.

Look and see for instance the following:
logWindow := TranscriptShell showOn: (String new).

 "now log some messages"
starttime:= Time now asSeconds.
Time new printOn: logWindow.
[Time now asSeconds - starttime < 10 ]
whileTrue:
[
(Delay forSeconds:1)wait.
Time now printOn: logWindow.
logWindow cr;flush.
]

This simply WAITS for the whole loop to execute, THEN shows the
whole bundle of messages. I think that has to do with the streams, Am
i right ?
And how should I go about if I simply want to show one message each
second ?

Rick

Rick,

> This simply WAITS for the whole loop to execute, THEN shows the
> whole bundle of messages. I think that has to do with the streams, Am
> i right ?
> And how should I go about if I simply want to show one message each
> second ?

I think it's more to do with the fact that you are executing the delay in
the main windows process - therefore preventing it from doing anything else
until the block ends.

What you should do is fork off another process to run your block and let the
main process get on with the job of running the image (including updating
the Transcript).

How? Just wrap you block in another block and send it the #fork message

logWindow := TranscriptShell showOn: String new.
[starttime:= Time now asSeconds.
Time new printOn: logWindow.
[Time now asSeconds - starttime < 10 ]
    whileTrue:
        [(Delay forSeconds:1) wait.
        logWindow
            print: Time now;
            cr]] fork

or, slightly rewritten for clarity (IMHO), the equivalent

logWindow := TranscriptShell showOn: String new.
starttime:= Time now asSeconds.
[[logWindow print: Time now; cr.
Time now asSeconds - starttime < 10]
    whileTrue: [(Delay forSeconds: 1) wait]] fork

Ian

Thanks Ian,
Forgive me for being so ignorant,
but what if I want to stop logging when the view is destroyed ?
I was using TranscriptShell isOpen but that doesnt give boolean ?
Debugging there becomes extremely difficult for me.. ?
Code below barks anyway..
Rick

logWindow := TranscriptShell showOn: String new.
"start new process"
[
"see if a logwindow attached
logWindow isNil ifTrue: [ self error: 'No log'].
" as long as the logwindow is open give a message every 1000
milliseconds that we have a vehicle .."
[log isOpen] whileTrue: [ (Delay forSeconds: 1000) wait.
log isOpen ifTrue: [self show: 'Vehicle detected.'] ]
 ] forkAt: (Processor userBackgroundPriority).

Thanks for your time looking into this too..
Point stays that either I am stupid, while years of cpp experience
encapsulating that fact..:-) or documentation is a little low..

Rick



On Sat, 2 Dec 2000 09:34:19 -0000, "Ian Bartholomew"
<[hidden email]> wrote:

Ian,
Correction on the post before..

Oops,
Ian perhaps I am getting a little to lazy now.
I solved the problem already, because I discovered that the
TranscriptShell has a VIEW which can be asked if it is open!
What you could try is to tell me if there are more hidden things like
this in TranscriptShell....
Anyway thankx for helping out,
Rick
for the record:

logWindow := TranscriptShell showOn: String new.
[
logWindow isNil ifTrue: [ self error: 'No log'].
[log view isOpen] whileTrue: [ (Delay forSeconds: 1) wait.
log view isOpen ifTrue: [ logWindow show: 'Vehicle detected.';cr] ]
] forkAt: (Processor userBackgroundPriority).

Rick,

Which version of Dolphin are you using, 2, 3 or 4. It might make a
difference when answering any further questions.

> but what if I want to stop logging when the view is destroyed ?
> I was using TranscriptShell isOpen but that doesnt give boolean ?
> Debugging there becomes extremely difficult for me.. ?

?. #isOpen is only implemented for Views so sending #isOpen to a Presenter
(TranscriptShell), or even an instance of a Presenter, won't  work. You
would need something like

s := TranscriptShell show.
s view isOpen

But that causes a problem in V4 which will be the subject of another post

> Point stays that either I am stupid, while years of cpp experience
> encapsulating that fact..:-) or documentation is a little low..

The first option is obviously wrong because you have decided to learn
Smalltalk - a very smart move <g>

The second point is more valid but is something that becomes a little less
of a problem once you have got past the initial hump in the
Smalltalk/Dolphin learning curve (and I accept it is a biggish hump).
Learning to use the image and environment as documentation is a very
important step that takes some time to appreciate.

The main problem is that Smalltalk and (proper) OOP is different and takes
time to learn. For someone like yourself who has a good knowledge of other
high level languages (being kind I'll include C++ in that category)
unlearning some of your existing knowledge can be just as difficult as
learning the new stuff.

> What you could try is to tell me if there are more hidden things like
> this in TranscriptShell....

Lots and lots - but they are not things that you can just sit down and
learn, there are too many of them. It goes back to the previous point I made
about using the image as documentation. All you need to know (speaking on a
very general level) is what sort of thing each class or class hierarchy in
the image is used for and have a rough idea on how they all fit together.
Once you know that you can use the browser tools (including the Debugger
which is much more important in this area than you might think) to look in
the image for likely methods that might be what you want.  Method categories
and comments, along with well named methods, can usually be used to narrow
down a search quite quickly.  The more common and well used ones you
remember, the rest you look for.

I'm not saying it's easy, it takes time to get used to, but it's worth it in
the end!!

> logWindow := TranscriptShell showOn: String new.
> [
> logWindow isNil ifTrue: [ self error: 'No log'].
> [log view isOpen] whileTrue: [ (Delay forSeconds: 1) wait.
> log view isOpen ifTrue: [ logWindow show: 'Vehicle detected.';cr] ]
> ] forkAt: (Processor userBackgroundPriority).

Presenter>>hasView can be used in place of View>>isOpen to check if the
TranscriptShell instance is still open so you could trim it down a bit -

logWindow := TranscriptShell showOn: String new.
[[logWindow hasView]
    whileTrue: [(Delay forSeconds: 1) wait.
    logWindow hasView ifTrue: [
        logWindow show: 'Vehicle detected.';cr]].
    MessageBox notify: 'Log closed'] forkAt: Processor
userBackgroundPriority

Regards
    Ian

On Sat, 2 Dec 2000 22:19:07 -0000, "Ian Bartholomew"
<[hidden email]> wrote:

I have the free version ( 3.0) so that won't be a problem:-)

Well we will see, usually those things show up when you start using
GUIs.. For instance can you tell me by head what you are going to do
if you want a spreadsheet output, with column headers name|
description| values | and without numbered rowheaders ?

Just one of those things...

>
>The main problem is that Smalltalk and (proper) OOP is different and takes
>time to learn. For someone like yourself who has a good knowledge of other
>high level languages (being kind I'll include C++ in that category)
>unlearning some of your existing knowledge can be just as difficult as
>learning the new stuff.

Probably not. VC is our main environment and will be that for a while
I guess, but smalltalk can be used imho for prototyping and sort of
"testing" the OOA and Design fases..
With a smalltalk prototype I want to say:  well the design can work:
see..".Or " the design would work that scenario this and that way..."
 

This is no good. I think i just passed the syntax barrier of
smalltalk, but even for someone fluent in OO en VC you need
documentation!

BTW how to use the debugger in processes. Every time I use a fork the
debugger barks at me, or at least its not possible to debug single
statements inside the block thats forked...

Or rights smalltalk has a framework right ? Is there somewhere some
high level design documentation about that framework  ? ( More details
then the original smalltalk book, which I am reading, is required
there)

And how about windows GUI ? Does Dolphin have a framework like MFC
there too ?  And is that complete ? And documented ? Or is it more
like VBs GUI elements( most of the time you want something in those
elements it simply is not possible...)

>
>I'm not saying it's easy, it takes time to get used to, but it's worth it in
>the end!!


Ofcourse. Let alone I have no longer to take part in discussions why
responsibity modeling is preffered over datamodeling..

So the system pattern is MPC, that I have understood. Then there is
the part about models, for which I should have some time to get it
read and understood, but I still have my doubts about the GUI
framework, just because MFC is made/updated by the same guys making
the OS.

Or can we say that smalltalk solutions have a little less tendency to
get GUI bloated ?

Regards,

Rick