You can write the DLL in any .NET language. Pass the Vegas object from your .js file to the DLL.

Also, you need an .xml file to tell scripting where to find your DLL.
http://www.ayizwe.net/VegasScripts/FAQ.html#1.6

That was my first impression too. Give it some time and you'll find out it's a fantastic program.
It has the objects you're looking for under the 'Tools tab', the feature-tour on their website will help you out.

It’s been a while since I developed QuickPan but here’s what I did. I wanted a GUI and have no patience for the trial and error of using Notepad and a compiler. SharpDevelop doesn’t support building JScript GUI’s so I wrote the GUI in C#. That was the only reason I used C#. When and if SharpDevelop supports JScript.NET GUI’s I’ll just use that.

In SharpDevelop, I just created a Window Forms Project and developed and tested the GUI as a standalone windows program. Then for the final build, I went into Project Options, under Configuration->Release->Code Generation I changed the Compile target to Library. This makes it build a DLL instead of an EXE. Then just call your DLL from your JScript or VB.NET script in Vegas.

While you can’t run your JScript in SharpDevelop, the syntax highlighting and auto formatting in the editor still works fine.

~jr

> Where are the check boxes, text boxes, command boxes, etc.... to draw on the form?

At the bottom of the left pane are tabs. (they don’t really look like tabs but if you look past the bottom of the pane you’ll see them). If you click on the last one to the right (i.e., the 4th one from the left) the pane will change to a list of tool tabs (which look more like buttons) select the one that’s labeled Windows Forms . That has all the widgets to use on your form.

~jr

Thanks Johnny. Got the tools to appear (I have to turn OFF viewing tools and then turn it back ON for some reason). However, it DOES appear to be working.

There's still a lot of limitations in the drawing that I took for granted in VB. But it DOES help to quickly draw the screen and present C# code. Plus, it's really close enough to be converted to JScript fairly easily.

This is how I've worked too, and it works fine, only a few problems: in version 99b of SharpDevelop (that is for download at this moment) importing picures in a form doesn't work properly. Look for the discussion about this in the #develop forum for workarounds (they are a bit complicated). Apparently the bug is fixed in the new sourcecode version. Also: 99b is a beta and not entirely stable on my system, and there are some things that just don't work. But alltogether it is a great help to get Vegas scripts to a higher level.

Ed,

I would think in your case you’d want to go the other way. i.e., move more of your code to C# by passing in the Vegas object from a minimal JScript. I understand you’ve used some kind of obfuscation in your JScript to protect it from being viewed and copied. I would think compiled code would provide even better protection for you. Just something to consider.

~jr

Is that really good protection? Sharpdevelop has a Disassembling-option, it seems it can convert a dll to C#.

Disassemblers have been around forever. The process is called “reverse engineering”. They cannot get the original source code back, especially if you compile with optimizations on. They can, however, produce source code that will work. The problem is it is very difficult to follow and the original logic flows are gone because only the optimizations remain. This would be a lot of work to go through just to steal Ed’s trade secrets.

I’ve not seen Ed’s obfuscated code, but it is source code that is executable none the less. I have taken obfuscated Java code in the past and made readable code from it, so using compiled code is at least as good as what he’s using now. The reason I say it’s actually a little better is because his code is a plain text file which anyone can read and compiled code requires that you at least install some programming tools and know what you’re doing to reverse engineer it. That makes it tougher to view.

We’re not trying to copy protect the code here. We’re just trying to make it difficult for prying eyes to steal ideas from it easily. (i.e., keep the honest people honest)

~jr

What you say is true for normal  i386 executables, but dotnet is a completely different beast. The source code is available in compiled files, and there's no good (read cheap) way around it. Obfuscating helps to a degree, but obfuscated code can still be recompiled.

You should have a look at the obfuscated code in excalibur, it's done with jsobfus and is totally unrecognizable. It carries it's own encryption-code or something like that. A pity it's so expensive (something around $ 250).
The other java obfuscators i've seen all have to leave a lot of the structure and variable/function-names visible.
But isn't the main advantage to put a lot of the code in the dll the speed-improvement you get with pre-compiled code?

> The source code is available in compiled files

Wow, I didn’t realize .NET stored your source in executables. I know they have an intermediate format that was language neutral but storing source is crazy.

> But isn't the main advantage to put a lot of the code in the dll the speed-improvement you get with pre-compiled code?

Because the scripts are so small, it’s a trade-off between the time it takes to load the DLL and the time you save executing the code. Once the script engine is loaded, it’s probably faster to execute the source than call a compiled module that must be loaded.

~jr