Script the Removal of a Block Diagram in Memory

[paul_cardinale]

---

@paul_cardinale wrote:

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

---

Oops.  There were some mistakes in the code to convert from regular to express.  Here's the fixed version.

Still haven't figured out why error 1073 is happening.

[paul_cardinale]

I think this is impossible.  It appears that when LV converts a regular VI back into an Express VI, it needs to do some edits; but that is impossible if the BD is gone.

An alternate solution could be just to lock the Express VI so it can't be converted into a regular VI.  Might be possible with Basic Object Flags, but I'm afraid of those.

[FireFist-Redhawk]

Couldn't you just put the authorization VI into a PPL so it's pre-compiled and thus has no BD?

[paul_cardinale]

---

@FireFist-Redhawk wrote:

Couldn't you just put the authorization VI into a PPL so it's pre-compiled and thus has no BD?

---

No.  That would be equivalent to what I started with.  The options would be on the FP, and thus exposed to hacking.

[wiebe@CARYA]

An XNode might provide more options then an Express VI.

I'm still not exactly sure what your plan is.

I think you want to put a VI on the BD, so that when the calling VI is loaded, the BD is removed or not, depending on some authorization criterium? 

[paul_cardinale]

---

wiebe@CARYA wrote:

An XNode might provide more options then an Express VI.

I'm still not exactly sure what your plan is.

I think you want to put a VI on the BD, so that when the calling VI is loaded, the BD is removed or not, depending on some authorization criterium? 

---

Here's my plan:  The underlying code checks the authorization and allows the top level VI to run or not (closes the top FP if not authorized).    That code is in a VI without a BD.  But it is wrapped in code that has 3 boolean options that affect the applicability of authorization.  I want to protect those booleans from hacking, thus I don't want them on the conpane or even on the FP.  Making that wrapper VI an Express VI allows me to have those booleans be constants that are set when the developer drops the VI on the BD.  This is pretty good security, but still leaves open a possible hole: If a developer converts the Express VI into a regular VI, it becomes hackable (if it still has it's BD).  Since I can't expunge the BD from the instance of an Express VI, my next idea was just to make it impossible to convert the Express VI into a regular VI.  I've now created a special purpose XControl that detects when its owner has been converted from an Express VI to a regular VI, the converts it back; but I'm not sure I want to go that route.  I'm thinking of a run-time approach instead of an edit-time approach: Just have the low level authorizing VI check whether it's been called by an instance VI, and if not, decline permission to run.

[wiebe@CARYA]

The 3rd party licensing toolkit does something similar (break VI execution based on some parameters).

Perhaps studying that mechanism will reveal some tricks? Perhaps it's just a WoT though...

[paul_cardinale]

Here's what I ended up with.

[wiebe@CARYA]

---

@paul_cardinale wrote:

Here's what I ended up with.

---

Note the Save:ToBuffer method... Saves you a save.

(QD "Save:To Buffer", CTRL+SHIFT+B on a VI method)

[paul_cardinale]

---

wiebe@CARYA wrote:

---

@paul_cardinale wrote:

Here's what I ended up with.

---

Note the Save:ToBuffer method... Saves you a save.

(QD "Save:To Buffer", CTRL+SHIFT+B on a VI method)

---

Yes, but since this will go in deployable code, I try to minimize my use of brown.