Testing and debugging Plug-in scripts

[propstuff]

Greeting again,

I've been reading the VS Language guide and looking through the Example scripts on the Site in preparation for starting with Plug-ins.

Plug-in scripts won't run "on their own" in the script window I understand, and fully compiled plug-ins won't run unless they're included in the current workspace.

I've tried running VW sample scripts inside the Plug-in Editor window (as against the VS editor window) but they didn't run in there either. (perhaps I didn't define the Parameters properly?)

How are Plugin scripts tested and debugged before being compiled into PIOs ?

cheers,

N.

[Petri]

I think the above only applies to parametric objects (PIOs) - tools and menu commands pretty much work as palette scripts. (And at least in VW 9, some ONLY work as palette scripts...)

This is not perhaps an orthodox method, but it works for me as comes to PIOs: I use constants in place of parameters, with the same names they will eventually have.

When I'm close, I create the PIO, but the script only consists of a single $INCLUDE, so I can edit the script with BBEdit. (You may need to clear the cache with the NNA script for the purpose; can't remember how it was/is distributed...)

I've tried to use $DEBUG, but I guess I'm not quite clever enough to really utilise it, so I just have to do everything by trial and error...

I don't want to sound patronising, but do try to use subroutines (procedures and functions) instead of spaghetti code. The examples are pretty good guidance in this respect. I wish I had realised this 10 years ago!

[Alexandre Villares]

Hi Propstuff,

Adding to Petri?s wise words.

Scripts created at the Resource Browser, or document scripts, will appear in small palettes called command palettes (Menu Window>Your Document>Command Palette). They will run when you double-click them.

Scripts created at the Plug-in editor, Plug-in Objects or PIOs (.vso) , Menu Commands (.vsm) and Tools (.vst) will have to be added to the Workspace.

HTH,

Alexandre

[ccroft]

Hi There

I work a little dirtier.I "develop" (sounds a little pretentious) everything in document scripts and copy/paste to the plug-in editor. For PIO's I assign literal values to variables and then replace the literals with with the parameters when I set them up.This lets me use variable names that make sense in the code,which may be different from what makes sense in the OIP.

To me the plug-in editor is about interfacing your scripts to the program once you have what you need. This is where the code becomes a PIO,menu command or tool.Working at the script palette lets me quickly run tests and duplicate and save different versions so I can easily recover from bouts of tragic logic.

The drawback,of course, is having to work with such an enemic text editor. It's fine for small stuff,but I find on more complex work that I'm copy/pasting back and forth from BB Edit.

It had occured to me to do as Petri suggests,and now that I know that others do it this way I'll have to try that sometime.

Thanks Petri!

"I've tried running VW sample scripts inside the Plug-in Editor window (as against the VS editor window) but they didn't run in there either. (perhaps I didn't define the Parameters properly?)"

Indeed.If what you are doing is taking a sample script of a PIO and pasting that into the Plug-in Editor you would have to take special care to set-up the params to match the script. If you paste it into a document script you would have to set up variables or constants to replace the parameters.I think a parameter is just a special kind of variable.

Please forgive if I'm stating the obvious.

Charles

[propstuff]

Hi all,

Petri:

You're in Melbourne also I seem to recall(?) -perhaps I'll see you at the VW11 demo next Thursday?

anyway;

you said;

quote:

---

This is not perhaps an orthodox method, but it works for me as comes to PIOs: I use constants in place of parameters, with the same names they will eventually have.

---

So, (for the purposes of development) the dymanic interactivity that would be provided by parameters in the finished plug-in are replaced by static Constants. do I understand this correctly?

quote:

---

When I'm close, I create the PIO, but the script only consists of a single $INCLUDE, so I can edit the script with BBEdit. (You may need to clear the cache with the NNA script for the purpose; can't remember how it was/is distributed...)

---

I'm afraid you've lost me.... {:-(

I've read the section on $INCLUDE about 5 times but I don't know enough to make sense of it. "..instructs the compiler to insert source code from an external file......"

Perhaps I shouldn't read Manuals at night in bed....I've developed "poor reading habits" as they say.

Alexandre,

quote:

---

Scripts created at the Plug-in editor, Plug-in Objects or PIOs (.vso) , Menu Commands (.vsm) and Tools (.vst) will have to be added to the Workspace.

---

I realise this is needed for them to work, but given the "development cycle" involved in my first script recently, I can picture a VW Plug-ins folder littered with the wreckage of mangled PIOs before I get things to function. (not to mention the tedium of adding the plug-in and changing the workspace every time I make an edit!)

Charles;

quote:

---

To me the plug-in editor is about interfacing your scripts to the program once you have what you need. This is where the code becomes a PIO,menu command or tool.Working at the script palette lets me quickly run tests and duplicate and save different versions so I can easily recover from bouts of tragic logic.

---

"Bouts of Tragic Logic"

You should copyright that one; could be a record or book title, (perhaps a biography of any number of Politicians/ Journalists/ Scientists/religious leaders/ Academics/etc etc?)

You (all) seem to be saying that development and debugging of PIOs can be done in the regular VS editor (with various caveats).

What I was thinking of was my first script, which used a lot of rigmarole to draw a polyline. In a PIO this would all be taken care of by GetCustomPath (I think it is).

But this call won't run in a Document VS because it needs the PIO "wrapper" (as it's described as in the manual) to function properly.

How then, would I run and debug a PIO script with one of these types of calls in it?

cheers,

N.

[Alexandre Villares]

Originally posted by propstuff:

quote:

---

Scripts created at the Plug-in editor, Plug-in Objects or PIOs (.vso) , Menu Commands (.vsm) and Tools (.vst) will have to be added to the Workspace.

---

I realise this is needed for them to work, but given the "development cycle" involved in my first script recently, I can picture a VW Plug-ins folder littered with the wreckage of mangled PIOs before I get things to function. (not to mention the tedium of adding the plug-in and changing the workspace every time I make an edit!)

No! It's OK to have some testing stuff in your Plug-ins folder. And you don't have to add many of them to the workspace, one will do. Let's imagine an example:

1. You create a VSO PIO called AA_Test.vso (AA_ will make it to the top of the list), put some draft code inside it and add it to the workspace.

2. Try to insert it on a drawing. It may work, it may not.

3. Edit it. If you feel like it you can duplicate it before you change it (so you can go back if you break something). But you don't need to add each test to the workspace, change and test the same one.

quote:

---

What I was thinking of was my first script, which used a lot of rigmarole to draw a polyline. In a PIO this would all be taken care of by GetCustomPath (I think it is).

But this call won't run in a Document VS because it needs the PIO "wrapper" (as it's described as in the manual) to function properly.

How then, would I run and debug a PIO script with one of these types of calls in it?

---

Do as explained before...

Beware path PIOs are a bit tricky (you actually have to copy or redraw the user given path).

Now includes are not so difficult, it's just a piece of code, a text file, that is included in the main code, and so can be edited outside VectorWorks.

I'll see if I can find something for you on the include cache (so you can edit the code and see the changes in the PIO behavior immediatly).

best rgrds,

Alexandre

[propstuff]

Hi Alexandre,

quote:

---

No! It's OK to have some testing stuff in your Plug-ins folder. And you don't have to add many of them to the workspace, one will do.

---

D'oh!

For some reason I had it in my head that complied PIOs are un-editable. I think I might have been getting confused by trying to look at VW native (encrypted?) PIOs.

quote:

---

Beware path PIOs are a bit tricky

---

I think I might leave those for later and start with... maybe..... a rectangle. ;-)

quote:

---

Now includes are not so difficult, it's just a piece of code, a text file, that is included in the main code, and so can be edited outside VectorWorks.

---

OK, so then the script starts to execute, gets to the $INCLUDE, goes off to where the the Include is living (externally to the VS?) and executes it and then returns to execute the remains of the VS?

I can see this would be usefull in development, and perhaps in the wider world of programming, but in writing VS does it have other particular applications?

N.

[Miguel Barrera]

hi nicholas,

all you have to do is add {$DEBUG} inside the procedure call and also make sure you have in the last line Run(procedurename).

procedurename being the name you assign to the procedure.

After you have added the pio, tool or menu command to the workspace, then run the program. You should get the debug window were you can do a step by step debug or even stop at some point in the program.

good luck,

miguel