Simple Question: How to delete objects in a group?

[Cheong]

Hi readers,

I create a group using script and then add objects in it.
Then when I restart the app I want the objects in the group to be deleted and recreated.
How do I delete objects in group but keeping the group?

[MaxV]

Using this code you can select what you want to delete and what to maintain (you can use your group name, instead of 1):

########CODE#######
put the number of controls of group 1 into temp
repeat with i=1 to temp
put the name of control i of group 1 after listContr
put CR after listContr
end repeat
repeat for each line tLine in listContr
if the last word of tLine is not (quote & "grElement" & quote) then
do "delete " & tLine & "of group 1" #this is to avoid syntax errors
end if
end repeat
#####END OF CODE#####

in order to create something in a group just use something like:

Code: Select all

create button "example"  in group "my_group"

[dunbarx]

Hi.

Try this as an experiment. On a new card, make four buttons. Group any three of them, and name the group "xx". In the ungrouped button script:

Code: Select all

on mouseUp
   repeat with y = the number of controls down to 1
      if the short name of the owner of control y = "xx" then delete control y
   end repeat
answer the name of group 1
end mouseUp

Craig Newman

[sritcp]

Craig:

As an aside, I see that there is no direct way for a control to delete itself.
It needs to initiate a handler elsewhere, as in a card script.
The button script:

Code: Select all

on mouseUp
   send "killMeNow " & the short name of me to this card in 0 sec
end mouseUp

There needs to be a handler in the card script to do the deed.
Assisted suicide, I guess.

Regards,
Sri

[dunbarx]

, I see that there is no direct way for a control to delete itself.

Yep. No control with a running handler can delete itself. Even if a handler passes control to another handler, that handler cannot delete the calling handler in the calling control.

Craig

[sritcp]

No control with a running handler can delete itself.

Yes, that's why I guess "send in 0 sec" works, since the original handler ends when (before?) it sends the kill signal.

Regards,
Sri.

[dunbarx]

On a card make a button. In the button script:

Code: Select all

on mouseUp
   startDelete
end mouseUp

In the card script:

Code: Select all

on startDelete
   if the optionkey is down then exit startDelete
   put random(999) 
   delete button 1
   send "startDelete" to this cd in 30
end startDelete

The code fails at runtime. You cannot pass the buck.

Craig

[sritcp]

No, but the other way (that is, putting "send in 0 sec" in the button script) works! That was my point.

Make a button named "Test" and put in its script:

Code: Select all

on mouseUp
   send "startDelete" to this card in 0 sec
end mouseUp

Put in the card script:

Code: Select all

on startDelete
   delete button "Test"
end startDelete

Now click the button "Test"; harakiri !!

Regards,
Sri

[dunbarx]

Hi.

Hmmm.

The "send in time" command seems to allow (direct?) the button handler to "complete". So the calling object's script is no longer running when the card script fires and runs.

If you step through, you can see it, even though the explicit timing "0 sec" is wrecked. Simply "sending" in equal to simply calling, so the "in time" is what changes the way LC manages the sequence. This could be either a powerful feature, or just an anomaly that might trip you up if you are not aware of it.

Your vote?

Craig

[dunbarx]

Hi again.

Here is a great example of what you found. This is from another thread I was on (HELP CREATE TIMER) in this forum. The OP wanted a countDown/countUp timer. I told him to make a buttona and a field, and place something similar to this in the button script:

Code: Select all

on mouseUp
      countDown "0:05"
end mouseUp

On countDown var
    if the optionKey is down then exit countDown
      set the itemDel to ":"
      put var into fld 1
   switch
      case  var = "0:0"
         countUp var
         break
      case item 2 of var = 0 and item 1 of var <> 0
         put 60 into item 2 of var
         subtract 1 from item 1 of var
         break
   end switch
           subtract 1 from item 2 of var
      send "countDown" && var to me in 60
end countDown

On countUp var
    if the optionKey is down then exit countUp
      set the itemDel to ":"
      put var into fld 1
   switch
      case item 2 of var = 60
         put 0 into item 2 of var
         add 1 to item 1 of var
         break
      case item 2 of var <> 60
         add 1 to item 2 of var
         break
   end switch

-- send "countUp" && var to me in 60

  wait 60
   countUp var
end countUp

As written, with a "wait" and a "hard" call to the handler "countUp" it works. But comment out those two lines, and uncomment the "send..." line, and the "countUp" handler does NOT fire, rather the "countDown" handler fires, and continues.

This is perplexing to me, and I thought I knew something about how xTalks work. Please check it out. I feel like sending this in as a bug report, but I have a feeling it involves something I am missing, all that xTalk stuff notwithstanding.

Craig

[jacque]

A "send" command without a time attached executes immediately inside the handler like any other command or function. The calling handler then resumes where it left off.

Sending in time puts the command into a queue. The calling handler completes and then at the next idle the queue is checked to see if any pending messages should be executed. Sending in 0 will execute the command immediately because zero wait time is "now". Since the original handler has completed, deletion of its object is possible.

It's actually possible to send a message in -1 time units which will force it to the top of the queue if there are two events scheduled for the same time, but that's a very rare situation and I've never needed to use it. It could be useful in some heavy networking scripts though.

[jacque]

As written, with a "wait" and a "hard" call to the handler "countUp" it works. But comment out those two lines, and uncomment the "send..." line, and the "countUp" handler does NOT fire, rather the "countDown" handler fires, and continues.

This is perplexing to me, and I thought I knew something about how xTalks work. Please check it out. I feel like sending this in as a bug report, but I have a feeling it involves something I am missing, all that xTalk stuff notwithstanding.

Not a bug, it's the structure of the script. Countup is blocking, it calls itself recursively. Because it was triggered from countdown, when the recursion ends, control is returned to the countdown handler which then places a message in the queue for countdown to run again in 60 seconds.

A better way to structure the script might be to use a flag to indicate the direction and use a send in time command for both directions. That would avoid the block, which as written will prevent any user or background actions for as long as the timer is running.

[Simon]

Back to Cheong's original question...
Once in a standalone if the stack was last saved without the group and the objects they wont show up on restarting the app.
Simple

Simon

[sritcp]

Not a bug, it's the structure of the script. Countup is blocking, it calls itself recursively. Because it was triggered from countdown, when the recursion ends, control is returned to the countdown handler which then places a message in the queue for countdown to run again in 60 seconds.

Yes, it is working exactly as one would (should?) expect. If you step through the code:
When var hits 0, countup is called. It increments and then "sends in 0 sec" a countup recursion with var =1.
This is queued, while countdown resumes. But, it resumes with var = 0, and goes on decrementing it to -1, -2, -3, etc. interminably.
If you press the Option key, Craig's code will exit the countdown recursion and go to countup that is waiting in the queue.
This will take the var = -3 (say) that came out of the countdown process, and start incrementing interminably, until Option key is pressed.

All's well, except for the fact that the queued countup had a parameter value of var = 1, but instead it uses the output of countdown, that is var = -3 (or wherever you ended the recursion).
This tells me that the parameter is not evaluated when it is sent but when it is executed. Didn't know that!

Regards,
Sri

[dunbarx]

Jacque.

Makes sense. I got stuck thinking that in-line execution ought to rule, but of course there are "layers" of control among several handlers.

I had a flag, and it worked fine. I was fooling around with Sri's "send in 0 seconds". The point is not that 0 seconds executes at once, rather that "send in time" works as you said, releasing control back to the calling handler.

All is well...

Craig