Exec.PrefSys & ExecPriority Error 1000

[joshua.l.guthrie2.civ]

Any quick ideas why the following would generate an error 1000?

I'm not seeing any thing in:

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/properties-and-methods/vi-server/vi/execpr...

or

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/properties-and-methods/vi-server/vi/prefer...

That makes these property set's taboo.

If it matters, the VIs being opened are reentrant and are from a packed library.  The function works fine w/o the set properties (prefSys, priority) code.

Thanks, because I'm sure this is obvious and I'm missing something.

[Andrey_Dmitriev]

I don't see any problem with simple test:

Your issue lies somewhere else.

Two things you should keep in mind:

1. The Execution:Preferred Exec System property is not settable when the VI is running (this property is writable only when the VI is in edit mode) and is read-only in the Run-Time Engine.

2. Error 1000 usually occurs when a property is called in an inappropriate state or when the Run VI method is called before the first call has finished executing. Ensure that your VI is not running at this moment.

[rolfk]

Another suspect is the word “packed library”! A packed library contains fully compiled VIs, usually even without diagram. These properties require recompilation of the VI to work properly, something a VI in a packed library can’t do.

i’m sure these properties are not settable in a build application and a packed library is in this context also a build executable. It is not possible to recompile a VI in a packed library even if the diagram wasn’t removed during build for some reason.

[joshua.l.guthrie2.civ]

Don't see how the VI could be running.  I'm not calling it anywhere else, and the set properties is well before the "run VI"...

I'm scared it was a packed VI thing.  I was hoping LV was making a copy of the precompiled code and just setting a flag or something...  However, I do save the block diagrams on the .lvlibp's..  I wonder what are the mechanics of how all that works is..

Well crap, I guess the best I can do is to monitor/read these properties and throw a custom error if they are not set correctly...

[joshua.l.guthrie2.civ]

---

@rolfk wrote:

Another suspect is the word “packed library”! A packed library contains fully compiled VIs, usually even without diagram. These properties require recompilation of the VI to work properly, something a VI in a packed library can’t do.

i’m sure these properties are not settable in a build application and a packed library is in this context also a build executable. It is not possible to recompile a VI in a packed library even if the diagram wasn’t removed during build for some reason.

---

Reckon it's worth requesting the documentation of these properties to be changed to reflect this?

[joshua.l.guthrie2.civ]

So... along these lines.. if I make a VI re-enterant (pre-allocated) and compile it into a packed library, does it do something stupid like open up a whole new copy of the entire packed library or is it smart enough just copy just that VI (given it was compiled with that option)?

[rolfk]

---

@joshua.l.guthrie2.civ wrote:

---

---

Reckon it's worth requesting the documentation of these properties to be changed to reflect this?

---

Sure you can request anything, except that this is a major change to a lot of things. Basically, in addition to the categories:

Available in:

- runtime

- realtime

- remote access allowed

- settable when running

- loads frontpanel

- loads block diagram

- need to authenticate

- must wait on ui ready

-  available with control VIs

- available with global VIs

- available with strict typedefs

- available with polymorphics

there has to be a new category

- settable on build artefacts (exe, packed library)

For most things this would however echo the settings of

- available in runtime engine, (especially when it says "yes, read only")

But there are potential differences, some properties are simply completely unavailable in the runtime engine since they are not included at all in it as they were considered undesirable. As long as they do not try to change things in a resource that is in a read only file container such as a packed library, they work fine in the development system.

Error 1000 is also a fairly generic error, when VI server simply can't do something, so this is another indication that this error is likely not even explicitly handled. Such a change would take quite a bit of effort, including reviewing all of LabVIEW for other similar occurrences, and then updating the documentation of 1000s of properties with this new category.

So yes, a noble request, but likely not something going to happen anytime soon.