[Closed] Determine a Macro's enabled state

yeah… you don’t. If they are your own macros I guess you could point all the usual macroscript events at internal functions which you can then call externally instead…

i.e. “on isEnabled do ( <code> )” would be changed into “on isEnabled do ( <call function with the actual code> )”

Or you could go nuts with…

strStream = stringStream ""
macros.list to:strStream
seek strStream 0
struct macroDef (
	id = -1,
	name = "",
	title = "",
	category = "",
	sourceFile = ""
)
macroDefs = #()
while (not (eof strStream)) do (
	newMacroDef = macroDef()
	newMacroDef.id = (trimRight (readDelimitedString strStream "\"")) as integer
	newMacroDef.name = readDelimitedString strStream "\""
	skipToString strStream "\""
	newMacroDef.title = readDelimitedString strStream "\""
	skipToString strStream "\""
	newMacroDef.category = readDelimitedString strStream "\""
	skipToString strStream "\""
	newMacroDef.sourceFile = readDelimitedString strStream "\""
	readLine strStream
	append macroDefs newMacroDef
)
-- I'll leave opening the source file, scanning for the proper macro definition
-- and getting the icon and/or events out of the source file
-- as an excercise for the reader... as it's insane.

Which will only work if there are no weird signs in the macro script names.
I had a discussion/thread with Paul about this some time ago and this method didn’t work for him since he had some quotes in his names.

Which ultimately leads to the conclusion that advanced macroscript/menu support in max is almost useless or not very robust at best when you want to manage scripts and menu items.

-Johan

Bah, that’s what you get for putting quotes in them Even without quotes it’d be some nasty code, though.

Here’s a question…
why do you need to be able to do that?
and…
wouldn’t the aforementioned ‘call a funtion instead’ be a solution if it concerns your own scripts?

Since most of my tools are in structs I set an active switch in the struct to determine if the tool is running at that time… this will work best if you bind the active switch to a open/close dialog event handler, but could be used with other tools as well… even some global array with an unique name can be filled when a tool is fired… that way adding to the array that can be queried… but I too wonder why you would like to know which tool is used.

-Johan

Hi all! Would have replied sooner, but the work internet is SLOW…

Okay…

ZeBoxx2, that’s pretty much exactly what we are doing already. In fact, in order to get it to work properly, we wrap the macro code in a rollout and trigger the “isEnabled” function manually based on a series of callbacks…which is why I would REALLY like a simpler method (apart from the fact I actually had to write my own macro parser and the hassels involved in dynamically constructing a rollout for each macro … there are just to many issues that could make this siutation blow up in our faces).

We also need support for “any” macro installed on the system…and provide support for macros that aren’t installed (by basically ignoring them)…within our toolbox

It’s been a while since I trudged through the SDK, but I think there is some additional support for macro handling in there…but that’s beyond the scope of this question right now…

The real problem was the callbacks. Having to pretty much monitor every event in max to determine if almost “any” pre-installed macro is enabled or not is, well, painful to say the least…

But with some clever use of a timer, we’ve been able to consolidate the process and improve the speed.

The other problem is if Autodesk decide to change the way that the macro list works…then all our stream parsing routines suddenly go out the window…

Looks like I’ll have to take a deeper look at the SDK again when I have the time…

Cheers
Shane