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).Render_Effects
I don't know if this is written correctly
12 December 2008, 01:43 AM
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?
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.