Wish list for new properties/methods

[ESST]

My apologies for having been unclear.

These are Methods, properties and events relevant for scripting that I would like to have access to. I realize that event was not listed in the first post, however, I decided to include them.

VI activation is an event that triggers when a different VI gets focus in the dev environment. It can be seen in "scripting.vit" from http://decibel.ni.com/content/groups/labview-apis/blog/2009/06/15/getting-started-automating-develop... As far as I can see it has only scripting related uses, as I can use events of the VIs in question within a regular application.

"BD selection Change", would be an event that triggers when the user changes which nodes are selected in a block diagram. I do not have an example of this, only a memory of having seen it on a forum.

Access to system window references. Very poorly worded I agree. I meant access to Labview system windows. Something along the lines of “All VI's in Memory”. I would like for my scripts to be able to take into account open project windows, lib managers and so forth.

The scripts I’m working on  where I see a use for these items, is a Quick Drop like script (I love Quick Drop, but I would like a version more suited to my way of working), and a script for navigating open Labview windows(I work with too many windows open, and spend allot of time looking for the correct VI).

Espen

[AristosQueue (NI)]

The input structure is used only to supply the type of the wrapper structure. No attributes from the input structure are copied to the new structure. It is a poor UI, IMHO, but like so much of scripting, someone needed it and it worked for their use case. I would have preferred an enum of structures, but that would have either required a huge amount of work to make sure it got updated when new structures were added to LV or it would have become one of those forgotten dusty corners of the code. (Actually, ideally, I would like the input terminal to be polymorphic, then we could just pass a refnum constant of the desired structure type, but we don't have polymorphic terminals on property/invoke nodes.) Think of the source struct as nothing more than the palette selection. That's why my code snippet creates a new structure, uses it for the Enclose Structure command and then deletes the structure. That's just me getting rid of the temporary.

[AristosQueue (NI)]

You have all the documentation that any internal developer has. *ahem*

[AristosQueue (NI)]

Ah. I thought you were asking for a new method, not exposure of an existing one. Thank you for clarifying.

[AristosQueue (NI)]

Gotcha.

We differentiate methods/properties that allow scripting -- i.e., the programmatic creation of VIs -- from those that allow editor extension -- ie, starting VIs running that modify the LV editor environment itself. There is a constant concern (legitimate, in my opinion, although perhaps overstated) that we could expose the ability to use LV to create a competitor against LabVIEW, so every piece that allows more plugability, extension and modification of the LV environment gets special scrutiny. Your requests are now on the wish list... no promises.

[PJM_JKI]

Some scripting operation do tend to take a lot if times and I would like to see a Diagram.DeferDiagramUpdates similar to Pnl.DeferPanelUpdates.

Note: There is that property called App.DeferDrawing (), but it is not really user friendly and it has some side defect when turned back on (for instance the run arrow is not always redraw properly).

PJM

[Jim_Kring]

I just posted this, yeterday: Any way to defer Block Diagram drawing/updates?

[AristosQueue (NI)]

I explained the problem with having such an option in this post:

http://decibel.ni.com/content/message/6419#6419

Short story: drawing is not the problem; the logic of "what does it mean to script a VI" is the problem.

[DFGray]

Much of the time taken for scripting is type propagation (I cannot remember whether we expose turning this on/off or not).  However, you can speed scripting up quite a bit by simply not showing the block diagram while you are scripting.

[Kamocat]

I'd like to create a selection (from one node to another that relies on data from the first) by providing the refnums of those two nodes.

(I noticed that many methods rely on things being selected, so it'd be nice to programatically make a selection.)