RE: stopping a process

["Erik Nauman" <ENauman@xxxxxxxxxxxxxxxx>]

This is perfect, thanks. It helps me understand a lot more about MicroWorlds. 
Actually the button is clicked on by the user and set to "once" so the 
parallel processes problem isn't occurring. I'm sure the processes panel would 
have gone berzerk with that. That's great to know about SET and GET.
Erik

-----Original Message-----
From: mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx on behalf of Alain Tougas
Sent: Thu 3/22/2007 4:03 PM
To: mwforum@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Subject: RE: stopping a process
 
Hi!
That's easy:
set "button1 "on? "false

In fact, the primitives SET and GET allow you to do almost everything a
mouse can do.

But I just had a scary thought. if you're asking how to turn this button
off, it must be because it is ON, right? It must be ON because you've set it
to Forever mode, right? If so, it means that you are repeatedly creating
these When deamons, which is an error in the logic. When a when event is
turned on, it is turned on. Redoing the "turning on" is firstly not useful,
and secondly, it can really overdo it in terms of creating parallel
processes.

Good luck, keep posting!

Alain

-----Original Message-----
From: mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Erik Nauman
Sent: March 22, 2007 3:49 PM
To: mwforum@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Subject: RE: stopping a process

Aha! Since the when processes are started by a button press, the way to stop
them is to unpress the button. Does anyone know the command for that? I can'
t find it in the help. You can clickoff a turtle, so can you pressoff a
button?

Erik

  _____

From: mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Alain
Tougas
Sent: Thursday, March 22, 2007 1:15 PM
To: mwforum@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Subject: RE: stopping a process

Hi there,

This reply is not the "solution" to your issue, just some light to shed on
it.

I did try
when [1 = 1] [fd 10]
then
cancel [1 = 1]
while looking at the Process tab (you DO need to look at this tab of your
playing with When), and I could see the process being turned on, then off.
So in that sense,  I'd say that your approach should work. Just make sure
that your "cancel" instruction DOES get executed. Just to make sure, you may
want to add an instruction such as "announce [I got killed]" right after
your cancel instruction. That will be a proof that it got executed.

Secondly, make sure that the input for Cancel is absolutely identical to the
one used for When. Use copy/paste to play safe with this. Looking at your
original message, it looks like you're doing the right thing.

Finally, knowing how "costly" this feature is, I would avoid "abusing" it.
Try using "when this, do that" in the turtle's backpack instead. Generally
speaking, it does the job better. So answering your question: yes, these
When processes will adversely affect your project. At 48 processes running,
it should already be the case.

Sorry if I can't say more right now - I would need more info to go further.

Ciao,

Alain

-----Original Message-----
From: mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:mwforum-admin@xxxxxxxxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Erik Nauman
Sent: March 22, 2007 12:47 PM
To: mwforum@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Subject: stopping a process

I'm making a project with several pages and on one page a procedure has a
lot of "when" processes starting such as this:

when [touching? "comb "suitcase]
[comb, setsize 30 valise, insert "| comb|]
when [not touching? "comb "suitcase]
[valise, top
      search "| comb| cut
      comb, setsize 40]

Then a button gives the command to go to another page and at that point I
want those processes to stop (there are 48 "when" processes on the page) to
free up memory for the rest of the project. I've tried a lot of variations
of using this command:

cancel [touching? "comb "suitcase]
cancel [not touching? "comb "suitcase]

in various places and the "when"s just won't stop. Anyone have any ideas?
Maybe having those processes running during the rest of the project won't
adversely affect subsequent processes in the end.

Thanks,
Erik Nauman