|
|
|
Tell us what you think of the site.
|
Autodesk Media & Entertainment User Community
|
Autodesk® 3ds Max®
|
|
Autodesk® Maya®
|
|
Autodesk® Softimage®
|
|
Autodesk® MotionBuilder®
|
|
Autodesk® Mudbox™
|
|
Autodesk® ImageModeler™
|
|
Autodesk® Sketchbook® Pro
|
|
Autodesk® Smoke on Mac®
|
| Callbacks. How to determine if a specific one exists - best practice?
|
|
|
There doesn’t appear to be a simple way to determine if a specified Callback is currently installed inside Max.
There is only one “inspector” function (callBacks.show) and that simply lists them to the Listener - no usable value is returned as the result is always “OK” regardless of whether the function actually displays anything or not.
The obvious answer would be a Global variable, created and initialised to a known value by the callback itself and therefore “testable” by any script which needs to know about that specific callback. I’m not a fan of cluttering up Max with globals if I can avoid it, so I’d prefer a “better” way (if there is one).
A less obvious mechanism would be to mess with the Listener:-
Set the Insert point at the end of any existing text and note its position.
Execute a callbacks.show <type> <id>.
Set the Listener selection from the stored position to the end, and grab the selected text.
Inspect that text for the ID.
This would work, but is rather messy and long-winded just to obtain a Yes/No result.
If anyone has any better ideas then I’m all ears ;)
Note 1. The callbacks are startup/shutdown, not scene or object specific, therefore “persistent globals” and “custom attributes” are not appropriate.
Note 2. No .net solutions please.
Max 4.2 through 2013.
XP-64 (SP2)
NVidia 9800GTX-512 (Driver 266.58).
Core 2 Quad Q6600 2.4GHz, 8Gb Ram, DX9.0c.
|
|
|
|
If you use unique IDs to your callbacks, the next function is ok.
Yes, I know, this is very slim help.
fn doesCallbackExist type id = (
clearListener()
callbacks.show type id:id
setListenerSel #(0,-1)
(getListenerSelText()).count > 0
)
doesCallbackExist #preSystemShutdown #test -- false
callbacks.addScript #preSystemShutdown "goodbye()" id:#test
doesCallbackExist #preSystemShutdown #test -- true
callbacks.removeScripts #preSystemShutdown id:#test
doesCallbackExist #preSystemShutdown #test -- false
Max 9 through 2009, XP-Pro x64 SP2
ASUS EAH3450 Series (Driver 8.470).
Core 2 Duo E8400 3GHz, 4Gb Ram, DX9.0c.
|
|
|
|
|
Yep - that’s pretty much what I had envisioned. Only thing is that it destroys the current contents of the Listener - and you can never guarantee what a user is doing when they run a script, hence my slightly “messier” method earlier. Both would work, as would a global variable - shame there isn’t a built-in function to do this - it must surely be a common probem.
Author: Steve_Curley
|
| Replied: 17 May 2011 10:12 AM
|
|
|
|
|
Slightly modified, returns the listener contents,
(
fn doesCallbackExist type id = (
setListenerSel #(0,-1)
local oldText = getListenerSelText()
clearListener()
callbacks.show type id:id
setListenerSel #(0,-1)
local res = (getListenerSelText()).count > 0
clearListener()
setListenerSelText oldText
res
)
doesCallbackExist #preSystemShutdown #test -- false
callbacks.addScript #preSystemShutdown "goodbye()" id:#test
doesCallbackExist #preSystemShutdown #test -- true
callbacks.removeScripts #preSystemShutdown id:#test
local res = doesCallbackExist #preSystemShutdown #test -- false
res
)
But we all agree the management functions for callbacks are very thin.
-Johan
|
|
|
|
|
|
|
Had a play with this, but of course that final “OK” messes with the very thing we’re trying to preserve, especially if I try to reselect any existing selection and/or reset the “insert point” back to what it was.
On reflection, I think this method, though it certainly does work, may not be best approach - see the post by Anubis below (and my reply to it).
Thanks for the suggestions though, and yes - callback support does need some attention ;)
Author: Steve_Curley
|
| Replied: 17 May 2011 08:30 PM
|
|
|
|
Steve_Curley 15 May 2011 07:19 AM
Note 1. The callbacks are startup/shutdown, not scene or object specific, therefore “persistent globals” and “custom attributes” are not appropriate.
Note 2. No .net solutions please.
Alternative storing of globals is saving them to text file.
Max 9 through 2009, XP-Pro x64 SP2
ASUS EAH3450 Series (Driver 8.470).
Core 2 Duo E8400 3GHz, 4Gb Ram, DX9.0c.
|
|
|
|
|
|
|
Yes - a definite option as the script will already be storing settings in an .ini file (probably 3dsMax.ini). Only potential issue is if the callback is active but the .ini has been removed (not unheard of with 3dsMax.ini ;) )
Installing a callback “over the top” of an existing one simply replaces it, I think, so that may not be a problem. What would be is that under those circumstances the script would think the callback was not installed and therefore not offer to uninstall it. I’ll have to think about that one, but overall a good idea. Cheers :)
Author: Steve_Curley
|
| Replied: 17 May 2011 08:00 PM
|
|
|
|
|
|
|
