View Full Version : render effect deletion detection?

12 December 2008, 12:28 AM
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.

The scripted plugin's 'on deleted' call does not get called immediately
A change handler's 'when <effect> deleted' call does not get called immediately
No other general event callbacks are called when the effect is deleted
None of the parameters happen to be get/set at the time of deletion (to give a hacky way of updating)
Short of setting up a timer that checks whether the effect is actually still in the list.. any suggestions?

12 December 2008, 08:39 PM
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.


12 December 2008, 11:03 PM
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)
or without try/catch
isValidObj (refs.dependents rootNode)[1].Render_Effects[1]

I don't know if this is written correctly

12 December 2008, 01:43 AM
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...

basically I wrote a bit of code that 'lives' inside of 3ds Max.. that bit of code can be turned on/off via a button..
I want to make sure that when the user deletes that bit of code - killing it - makes sure that button goes to an off (or indeterminate) state
problem is.. when the user deletes the code, it's not killed. it's merely put into a comatose state from which it cannot recover %)
and I am not spotting any way to detect the code slipping into that coma.
I can detect when it finally dies, but that's not much use when that means the user can spend 30 minutes looking at a button thinking the code is alive, but not seeing it do anything (because the bugger's in a coma)
- (friend) what makes it go from coma to death?
a random 3ds Max event that basically makes 3ds Max visit each coma patient, pronounces them braindead and unplugs them from the machine.
- (friend) can you force it to visit each 'coma patient' as it were?
I can - but then I'm just back to the problem of being able to know -when- to make 3ds Max do its rounds; if I knew that, I wouldn't have a problem, as I could then just as easily run the code that toggles the button.

01 January 2009, 01:19 AM
I'm not usually one to bump a thread, but... any further thoughts out there?

CGTalk Moderation
01 January 2009, 01:19 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.