Jump to content

Can't get errors avay


Recommended Posts

Hello. I can't resolve errors in this class-library. Would anybody explain me what to do to avoid errors?

I thank you, Eugen

Please open with LV 8.5

I want to add:

this is my library, which I use in my projects. And now I want to offer this for free download. It work in my LV8.6 and in all of my projects, but if I publish it in a extern directory (and saved for 8.5) LV says there are errors: owning library has locked VIs. Is there a difference between LV8.5 and LV8.6 in using classes or is there a a problem with paths?

Link to comment

Ok :thumbup:

In the future I will show on this setting (so either dynamic or reentrant). But I don't understant why it work in LV 8.6. I mean I use this library in many of my current projects.

Anyways, thank you for your answers.

Hm...

Very strange... I think this property will not be saved with VI. Can anybody confirm this?

Link to comment
  • 2 weeks later...

QUOTE (Eugen Graf @ Dec 8 2008, 07:11 PM)

Sorry, I read the post again, so dynamic VI can't be reentrant. I have to define all VIs as static. No problem, but I would disable this property (selection) if I would be NI.
Dynamic dispatch VIs cannot be reentrant only in LV8.2. They can be reentrant, with shared clones, in LV8.5 and later.

QUOTE

Would anybody explain me why I should share clones? Why
LV
doesn't lock this setting in a VI even if this setting creates such errors?

I've answered the first question elsewhere and perhaps someone can find a link to the explanation. But as to your second question --- why doesn't LV lock this setting? because when I implemented reentrancy for dynamic dispatch, I just didn't think about it. I'll go file a bug report to myself and perhaps someday that will get changed. Thanks for the suggestion.

Link to comment
  • 2 years later...
I'll go file a bug report to myself
I am closing this CAR as Not A Bug. I realized later that changing this conflicts with our UI guidelines that we established for LV classes. A VI that is static dispatch could have the unshared clones setting enabled and then the user could change it to be a dynamic dispatch VI and then to unbreak the VI would change the settings to use shared clones. Likewise, a VI that is currently shared clones and dynamic dispatch could need to be changed into a static dispatch VI with unshared clones. When there are two directions for setting a pair of settings, we do not want users to have to change them in a particular order (i.e., graying out one setting until you fix the other one) because the direction is arbitrary: should we gray out turning off dynamic dispatch as long as the VI is sharing clones? If the options are mutually exclusive, that would force users to have to turn off reentrancy entirely, then go change from dynamic to static dispatch, then come back and switch on the right form of reentrancy. Also, with the gray out, there's no place for users to learn why the option is grayed out.

For LV classes, we have tried very hard to instead follow a policy of breaking the VI when settings conflict and giving a thorough error message to explain the conflict, rather than trying to force any particular order for configuring your VI or class. Therefore, I am closing the CAR.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.