LiveCode Forums.

I have a List of info-fields, each with a button to remove this entry, all created dynamically by script.

The remove button takes the item out of an items array, removes the corresponding field from the card.
Finally of course it should dispose of itself.
This naturally fails with an (Object: stack locked, of object's script is executing) - as the button holds the self destruction order.

Is there a way to acomplish self-destruction other than going to another card and put the cleanup of the list into the preopencard when it is opened the next time?

Put a handler in the stack to remove the button then use "send" to call that handler.

Havanna wrote:I have a List of info-fields, each with a button to remove this entry, all created dynamically by script.
?

Do you have a clever way to dynamically position objects for any device - tablet etc?

I'm still waiting to figure out how to get fullscreenmode "exactfit" etc to work with a scrolling group of objects any phone/tablet size landscape/portrait.

I did experiment using screenrect and then changing the width, height factor of this rect to calc the scroller contentrect for either landscape or portrait.
or set the scaleFactor of stack "Stack" to ... but I didn't resolve it.

Havanna wrote:I have a List of info-fields, each with a button to remove this entry, all created dynamically by script.
?

Do you have a clever way to dynamically position objects for any device - tablet etc?

I'm still waiting to figure out how to get fullscreenmode "exactfit" etc to work with a scrolling group of objects any phone/tablet size landscape/portrait.

I did experiment using screenrect and then changing the width, height factor of this rect to calc the scroller contentrect for either landscape or portrait.
or set the scaleFactor of stack "Stack" to ... but I didn't resolve it.

Havanna wrote:I have a List of info-fields, each with a button to remove this entry, all created dynamically by script.

The remove button takes the item out of an items array, removes the corresponding field from the card.
Finally of course it should dispose of itself.

If the button will ever be needed again in the future beyond that one use, why not just hide it?

FourthWorld wrote:

Havanna wrote:I have a List of info-fields, each with a button to remove this entry, all created dynamically by script.

The remove button takes the item out of an items array, removes the corresponding field from the card.
Finally of course it should dispose of itself.

If the button will ever be needed again in the future beyond that one use, why not just hide it?

This List is a set of "Favourites" without Limitation, so a user can have between no and an "unlimited" number of Entries.
I had a first version with the hide and show approach, but handling of this just looks easier to me when I create and remove the items instead of keeping control over a set of un/-visible objects.

newtronsols wrote:

Havanna wrote:I have a List of info-fields, each with a button to remove this entry, all created dynamically by script.
?

Do you have a clever way to dynamically position objects for any device - tablet etc?

I don't know if that's clever but it mostly works:
I use a handler to determine all relevant layout values and put them into a global array, so I can acces that from anywhere.
This handler is called on startup (and resize)
I set FontSizes and Layout margins and button sizes from here
Position of Objects i find reasonably simple by making "Object type Handlers" like: SetButton ButtonID, tButtonType, tButtonColor, tTextColor
in there I calculate the details from global button size, global button spacing and so on. Also a global "Left" and "Top" value make for a sort of Layout cursor, that gets updated in every "Object Type Handler"

Works quite nicely, but is a lot of codewriting of course, with the benefit of full layout control.
For different platforms and orientations, differend layout basics handlers do the job for me.

on mouseUp
delete button "XX"
end mouseUp

dead easy

mind you a button CANNOT delete itself

Hi Havanna,

make a button the button is gone.

Of course you put similar code into your self-destruction handler.

Kind regards
Bernd

You can also put into the script of the button. The button is gone after mouseUp

The main reason an object can not delete itself is that the code to delete is still running. With "send in time" the code is not running anymore and deletion can happen.

Kind regards
Bernd

bn wrote: The main reason an object can not delete itself is that the code to delete is still running. With "send in time" the code is not running anymore and deletion can happen.

Bernd, that is a very interesting situation, I wouldn't have expected time to make a difference. Instead I thought deleting an object would only be possible from the outside thanks a lot.

Andreas

Havanna wrote:I wouldn't have expected time to make a difference. Instead I thought deleting an object would only be possible from the outside thanks a lot.

Your expectation is spot-on: the "delete" command is being handled by the engine, and with the delay in sending it occurs after the button's own script has completed. So at that point, the actual deletion is being handled outside the button script.