Notifications
Clear all

[Closed] render effect deletion detection?

I have a scripted render effect that can have its active state toggled via e.g. a toolbar button.

When the render effect is deleted, I want to update the toolbar button, to make sure it doesn’t display as active / a dialog control to reflect the indeterminate / deleted state.

However, I’m not quite spotting how I might do this reliably and immediately.
[ul]
[li]The scripted plugin’s ‘on deleted’ call does not get called immediately[/li][li]A change handler’s ‘when <effect> deleted’ call does not get called immediately[/li][li]No other general event callbacks are called when the effect is deleted[/li][li]None of the parameters happen to be get/set at the time of deletion (to give a hacky way of updating)[/li][/ul]Short of setting up a timer that checks whether the effect is actually still in the list… any suggestions?

4 Replies
 JHN

You have probably already looked in this, but doesn’t

on
isChecked do <expr>

in the macroscript work out for you? It is there for the reason you want I think.

-Johan

Do you want to disable the toolbar button :

local stat = true
	on IsEnabled do ( try(isValidObj (getEffect 1))catch(false) )
	on isChecked do
	(
		stat		= not stat
		try (setActive (getEffect 1) stat)catch(stat=false)
		stat
	)

or without try/catch
isValidObj (refs.dependents rootNode)[1].Render_Effects[1]

I don’t know if this is written correctly

Hi guys,

Thanks for the replies

‘on isChecked’ is indeed what I am already using, and works well.
The unfortunate problem is this:

  1. the isChecked code is only run if/when the toolbar is updated.
  2. I can force an update using ‘updateToolbarButtons()’, that will cause isChecked to be run.
  3. I know when to force an update by… er… by uhm… apparently not by the ‘on deleted’ event, nor a ‘when <effect> deleted’ changeHandler – that is to say: not immediately so, as these are not triggered at the moment the render effect is ‘deleted’.

Basically, I’ve got the ‘on deleted’ event calling updateToolbarButtons() already, but near’s I can figure, the end-user could be staring at a checked-state toolbar button for hours as long as there’s nothing causing the ‘deleted’ render effect to be -actually- deleted (e.g. by a gc()).

Or as I explained it to a friend of mine…

I’m not usually one to bump a thread, but… any further thoughts out there?