Script the Removal of a Block Diagram in Memory

[paul_cardinale]

Is it possible to remove the block diagram of a VI in memory (while leaving all VI references intact)?

[Yamaeda]

I assume you can set the Remove diagram property and Invoke Save Instrument, right?

[paul_cardinale]

---

@Yamaeda wrote:

I assume you can set the Remove diagram property and Invoke Save Instrument, right?

---

Correct.  But after that VI in memory still has it's BD.  It's only the version on disk that has no BD.

[Kyle97330]

Would you be willing to share what your end goal is here?

The need to be able to remove a block diagram from a VI without invalidating existing references seems like a very weird set of requirements must have led you to deciding that you want to do that.

I've having difficulty imagining a scenario where you couldn't use the solution Yamaeda posted along with some sort of semaphore to pause all access to the VI, followed by closing and re-opening the VI reference in question, then using one of any number of methods to replace the old reference with the new, then releasing the semaphore.

[paul_cardinale]

---

@Kyle97330 wrote:

Would you be willing to share what your end goal is here?

The need to be able to remove a block diagram from a VI without invalidating existing references seems like a very weird set of requirements must have led you to deciding that you want to do that.

I've having difficulty imagining a scenario where you couldn't use the solution Yamaeda posted along with some sort of semaphore to pause all access to the VI, followed by closing and re-opening the VI reference in question, then using one of any number of methods to replace the old reference with the new, then releasing the semaphore.

---

I am developing a system that uses activation codes prevent unauthorized use of our applications.  I want it to be very simple for the app developer to include.  I've got that down to just dropping a single VI (Validate Application.vi) onto the block diagram, with the developer making sure that it runs before any UI action (plus issuing activation codes).  Originally that was just a regular VI that had its BD removed.  However there is a some configuration data that needs  to be set; originally I had some inputs that were to be wired into "Validate Application.vi".  But I realized that having those items on the connector pane (or even on the front panel, for that matter) would be a security hole.  So my idea is to make "Validate Application.vi" an Express VI, and have its configuration VI set configuration constants inside "Validate Application.vi" and then remove the block diagram.  However, for an Express VI's configuration VI, the Express VI exists only in memory.  So far everything I've tried doesn't work (see attachment for an example of something that doesn't work).  While I could just leave the BD inside the Express VI, there is still a risk that a developer will convert the Express VI to a regular subVI and save it to an unsecure location.  I've confirmed that it is possible for an Express VI to exist and run without a BD, but I haven't been able to delete one that already exists.

[BowenM]

Have you tried calling the Revert VI Method after saving to disk?

[Kyle97330]

Well, what if you went another layer deeper?

Instead of making the Express VI itself not have a block diagram, do some scripting that creates another VI from a template, does your custom modifications inside it, saves it without a diagram, and then adds that VI as a subVI on the block diagram of the express VI (connecting any wires, etc.) and then proceeds normally from there.  Then if someone does convert your express VI, they still don't have access to the sensitive block diagram nor the custom inputs your developer set up for it.

Also, just as a side note, it does seem to me that you're trying pretty hard to make this super duper simple for developers.  Making things simple for users is one thing, but if this became a slightly more involved process for developers I would hope that the people you trust enough to do development would also be people you could trust enough to do a 2-step or 3-step process instead of a 1-step process to add your authorization VI.

[paul_cardinale]

I've discovered the following strange things:

• The "Revert" method throws error 1073*, despite the fact that the VI exec state is "Idle".
• When a VI ref is to an instance VI, the "Save" method does nothing (and returns no error).
• If I convert the instance VI to a regular VI, "Save" works, but when I try to convert it back to an instance VI, it throws error 1073*, again despite the fact that the VI exec state is "Idle".

* Error 1073: This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode.

[paul_cardinale]

The attached files illustrate my problem.  Run Main.vi.  Why do I get error 1073?

[wiebe@CARYA]

I don't know if it helps, but if you open the reference with Open VI Reference, in stead of using a static VI, you get different behavior.

You get error 1 from the revert.

I tried Application:Open Document, and it gives an error 7. After checking (and some modifications) It seems the Save Instrument doesn't save the instrument.

Often, file name is "Has Express.vi:Instance:0" which isn't a valid path. It would also try to save a clone, while the original VI is in memory.