Starting another Revit session and interacting with it

[Anonymous]

Something I've been wanting to achieve for awhile is the ability to start a separate Revit session behind the one that I'm working in so that an addin can be allowed to execute a task while a user can stay productive. You can only go make some coffee so many times in a day.

For now, the only way that I've found to start a separate Revit session is to have a command that uses Process.Start(path to Revit.exe version)

This achieves having two Revit sessions active, but at this point I'm up against a wall since the API can't do much with the new session as a Process (with an Id at most)

At the bare minimum, all that I really need it to be able to do is:

• Start a new process (Revit session)
• Open a file
• Execute a command or PostableCommand in the new Revit session

It would be ideal, however, if I could actually identify each session and interact with them.

Has anyone had any success with concepts like this?

[Anonymous · Accepted solution]

I never did this but I do think it is possible. you will need to create 2 add in. With runs at start up and one run when user press the button. When the user press the command. Write a script that will write the file name you want to open into a text file and then you trigger start revit. At startup, read the text file and open the revit you list in the text file. Then run command after file is open. This may or may not work but I would approach your problem this way.

[Anonymous]

Yeah, I considered setting something to execute on Revit initialization, but I would need that to only execute if the session were started by this command. Not from normal Revit loading.

So if there's no way to do what I described in the OP, I was thinking something similar to your idea, since I suspect that the addin will be sequestered to the session that it was executed in. But you know, in case this isn't true, I need to get my mits on that.

[Mustafa.Salaheldin]

You can do it using Journal files. Just start Revit from prompt or as a process from your add in and provide the Journal file as an argument.

[tshunau]

Just delete the text file once you finish.  That way when you start revit, that file will not exist.   

[Anonymous]

Mustafa, thank you for the advice. This got me much closer but the Journal files are concerning me. The function that I'm trying to establish right now is this:

• User presses button in the ribbon to start scrubbing the file down to minimal views, sheets, assemblies, families, etc. (For coordination meetings and sharing)
• Addin copies the current file so that the copy can be trimmed down.
• A search replace runs against the journal file to swap filenames and destinations.
• This process will take awhile, so another Revit session starts up with the journal file as an argument. This works.
• Journal file is beside the manifest, allowing a second command of mine to run in the new Revit instance which finishes the job. Everything saves and closes down.

However:

If Revit decides to be obnoxious on a specific project with prompts about unmanaged links, or upgrading the model, or an addin failing, the journal will fail. (Very inflexible so far)

Perhaps I could code exception handlers into it, which means I'll have to brush up on my VB again. I did read from The Building Coder about many of the drawbacks concerning Journal scripts, including Autodesk not supporting them. We do want this process to be future proofed as best as we can get it, but if it can be made to work for now, I think concessions will stand for awhile. 🙂

[Anonymous · Accepted solution]

After having issues with the journal script, I doubled back to test your method tshunau, except I had an idea.

ApplicationSettings.

I have a boolean shared across the project called "scrubStart". From the first instance, I make the file copy and toggle that boolean to true, then save it.

If this boolean is true, I use the ApplicationInitialized event to open the copied project for scrubbing in the new Revit session.

Once the scrub is done, it flips the boolean back to false again.

Think this one is solved unless anyone has warnings about this that I'm not seeing.

[tshunau]

cool, keep me posted. 

[Mustafa.Salaheldin]

Ok you can use the Failure Processor event handlers to suppress any messages that will fire up when Revit starts. I know this will take extra work but I think Journal files are a strong tools that Autodesk shall develop more even it is not recommended for  now.

[Mustafa.Salaheldin]

The only concern with the ApplicationSettings method is when Revit crashed and didn't set the toggle back. This will require you to edit it manually.

[Anonymous]

tshunau,

I've done a lot of testing and am giving it to users today. The Application Setting method has not caused any issues so far, but Mustafa is correct in his concerns. You have to account for when, or if, Revit will crash.

I have it set so that if the variable is flipped on, it still will not proceed to scrub unless the file that I saved as the scrub file path (also an application setting) is opened. And only that file can be scrubbed.

So the greatest risk we face right now is Revit automatically opening the scrub file and starting to process it. Which is manageable. I saw this as easier to deal with than all the Journal backup files and the file management that this entailed, along with failure handling. But I do think that journal scripts had potential to really ease this process along had they been a bit more robust and supported.