I'm thinking the answer to this is 'no' but I'm looking for a workaround. We have a couple of thousand files we'd like to parse for concurrent verts and I thought I could use mgExecute to do it. Problem is that doesn't look like it works unless there's actually a file open on the desktop. So just doing an mgOpenDB and then doing an mgExecute doesn't seem to work.
Is there a workaround to this? Anyway I can do an mgOpenDB and force the file to be open on the desktop instead of just in memory? Or an equivalent to mgExecute that works in memory only? We also need to parse for concurrent faces and a bunch of other things and it seemed much more do-able to be able to leverage all the existing Creator tools ...
You are not able to open files onto the desktop (only in memory) and the mgExecute command works on the desktop. However, this is what Batch Run Script was created for. Have you tried to use it?
Chris - we don't have the Pro licenses so we don't have access to the batch-run function. I've written around it in my scripts by using python os calls to build file lists and then sequentially open each one in memory and work on them like that, but for this particular task I fell at the first hurdle because mgExecute only works in the editor environment.
Ok, I understand now. Unfortunately there is no workaround. mgExecute works only on DBs open on the desktop, and python cannot open a DB on the desktop. It seems like your options are to re-write the Creator tools you wanted to use, or see if you can get a pro license.
Sorry, I wish I could help you more.
You've discovered the "essence" of mgExecute (which is no ordinary OpenFlight script function). It can only be used inside of Creator (won't do anything in your stand alone script) and by definition works on the "top" (or current) database open on the desktop. Unfortunately there are some technical (and logical) reasons why what you are trying to do (open a database in memory and run mgExecute on that database) is just not possible.
1) If you had a database open on the desktop and a database open in your script (via mgOpenDb) and your script called mgExecute, which database is mgExecute intended for? Since you cannot explicitly specify that (through a parameter to mgExecute, for example) mgExecute has no choice but to always choose the database that is open on the desktop..That is just how mgExecute works. So even if we allowed you to run mgExecute on open databases in memory, how would we resolve this ambiguity? To avoid that, mgExecute just always works on the "top" (or current) database on the Creator desktop.
2) Many tools you run using mgExecute require objects that are only available through Creator (select list, current palette items, etc) and make no sense to a database that is open only in memory (with mgOpenDb). Consider the "Insert Color" tool. It applies the current color on the color palette to the items on the select list. Diving deeper into the "select list"... When you mgOpenDb a database in memory, the notion of the select list does not exist there. The select list has no representation in the database, it only has a representation in Creator. Same thing with Current Texture or Current Color in the respective palettes (and also many other things like "modeling parent", "modeling mode", etc). Those things mean nothing to the database (that information is not stored with the database or in its scene graph). If you tried to use these things on a database open with mgOpenDb, you would find they just don't work. That is because these things only mean something in Creator on databases that are open on the desktop. There are objects in the Creator desktop that you can only connect to via mgExecute.
So you might ask... then how does Batch Run Script do this? It does not simply call mgOpenDb on each database and run your script (like you are trying to do). It does some special things behind the scenes with Creator. It "opens" the database and "connects" it to the desktop (but skips making a window for it) and then runs your scripts on that "hidden" desktop window. That is why, unfortunately, you cannot write around this limitation. There is no function you can call to do this hybrid "open" on the database that Batch Run Script can do.
Note however, you can still call any other OpenFlight script function in your scenario. You just can't invoke a Creator tool on a database open in memory only.
Hope this makes sense.
Steve - makes a lot of sense - thanks. I'd sort of figured that out via empirical testing but it's nice to see a more official explanation :)