How to efficiently use Visual Studio with Vegas script writing

RedRob-CandlelightProdctns wrote on 11/4/2021, 4:46 PM

So -- I setup my Visual Studio debugger menu as guided in the VEGAS Pro Scripting FAQs.

All is working just peachy... except... a few things are a PIA:

every time I run the script for debugging it has to launch a new Vegas instance, go to scripts, run the script. is there a way to avoid it having to close and re-open Vegas each time?
every time it launches Vegas to debug, I get an error message that Vegasaur needs to be registered. Note I do NOT get that error when I just launch Vegas directly.
after my code is done running Vegas is still up -- cool, right? not quite. The windows within Vegas don't all work or appear proper (e.g. half the stuff is missing in the Preferences dialogs in Vegas). Is this normal?

Would appreciate any tips to optimize the process.

Comments

william-j wrote on 11/4/2021, 6:02 PM

Let me put in a word. Although it's not a good way, I'm doing it at present.

According to the standard method and jetdv video, as you said, you need to generate a class library and open it through the Vegas command line. However, a New Vegas instance will be opened, and Visual Studio's "terminate" command will also end the process of Vegas. I always need to wait for a very long time for the Vegas startup screen every time I debug the code because of my poor computer configuration. So I'm not used to this method.

As a workaround, I'm currently starting with a new project in Visual Studio. Then create a new CSharp source file in the project and a hard link (mklink /h) to the source file in the Vegas script folder so that the files in both folders can be modified at the same time. Then you can start the script in Vegas's menu options. However you can't debug your code. I'm now stepping up the troubleshooting process by inserting some "MessageBox.Show" methods at specific locations.

Anyway, I don't think my way is a good one.

RedRob-CandlelightProdctns wrote on 11/4/2021, 6:08 PM

Anyway, I don't think my way is a good one.

Ha! Funny man... 😀

I've written some scripts just using a text editor in the past and run through vegas, which is essentially what you're doing. I suppose you're still getting the benefit of the VS code editor and if you include the Vegas references then you can explore classes and such -- a vast improvement to a "dumb" editor.

But yeah.. for me, being able to dig into objects and check their values is really really helpful. So I suppose that's a tradeoff.

wwaag wrote on 11/4/2021, 8:16 PM

@RedRob-CandlelightProdctns

My suggestion for debugging. Forgot about using the Visual Studio debugger. Like you've discovered, it's a PIA for those very reasons. Although you don't get nice debug info, I find it a lot more convenient to simply build the script and copy it to your desired location by adding the proper post-build command line. (I use a private script menu folder although you can just use the Vegas script menu folder. It just depends on how you want to launch your scripts for testing.)

Here's the important thing. Add the following to your script code:

vegas.UnloadScriptDomainOnScriptExit = true;

This unloads the scripting domain once the script exits. Once done, you can keep your test Vegas project open and simply rebuild your script each time you make a change. Once you have a new build, just run the script--no need to close Vegas and re-launch. An added advantage (probably more important) is that Vegas often keeps the values of your variables in memory and fails to re-initialize properly once the script is executed again unless the script domain is cleared.

In lieu of using the debugger, just add a lot of try-catch regions and make use of MessageBoxes (probably my most useful debug tool).

Just a suggestion.

RedRob-CandlelightProdctns wrote on 11/4/2021, 8:21 PM

@wwaag thanks for that input. Any thoughts on the Vegasaur launch error? Probably just a side effect of launching via the debugger, but it's a PIA

wwaag wrote on 11/4/2021, 8:30 PM

I had the same problem with Vegasaur--that was part of the reason for just abandoning the use of the debugger. Life is simpler and it's much, much faster than having to reload Vegas each time.

Note that this only works for scripts. If you are creating a true extension (Custom Command), you will have to close and relaunch Vegas each time you want to try a new build. You can build it OK, but you can't copy it to the extension location since it's open in Vegas.

jetdv wrote on 11/5/2021, 8:12 AM

@RedRob-CandlelightProdctns, I've found that when using Visual Studio 19, the VEGAS windows are not drawn correctly. When using Visual Studio 15, they are! So I don't know what changed between the two.

You DO need to exit and restart VEGAS each time because, otherwise, VEGAS will keep the file open and you can't create the new one. For most of my "scripts", I just run the .CS file directly. Then you don't need to restart VEGAS each time and can just save the changes, pop over to VEGAS, and go to Tools - Scripting - Run Script, and then pick that .CS file. In most of my tutorials you see me doing it that way. However, you don't get the debugging tools when doing that. To use the debugging tools, you'll need to exit and restart VEGAS each time.

For a Custom Command, you MUST exit VEGAS each time and restart it with a new build. There's no way around that as VEGAS will keep the Custom Command locked.

Howard-Vigorita wrote on 11/7/2021, 12:49 PM

Here's the important thing. Add the following to your script code:
vegas.UnloadScriptDomainOnScriptExit = true;
This unloads the scripting domain once the script exits. Once done, you can keep your test Vegas project open and simply rebuild your script each time you make a change. Once you have a new build, just run the script--no need to close Vegas and re-launch.

I place a line like that (but prefixed by "myVegas.") at the end of my form function and it works as described like a charm.