Change reentrancy Property of a VI from Quick Drop

[MaximeR]

Hi,

I have build a quick drop (see attached file in LV 2018) to set a VI as Inlined. This allow also to toggle back the VI as Re-Entrant. But in this case, when you try to change the VI from Reentrant to Non-Reentrant with the Quick drop this option is not applyed without error.

Is it normal ?

When we do that change from Other VI with VI server it's working.

[Cdkey]

Hi MaximeR,

On this page: https://www.ni.com/docs/en-US/bundle/labview/page/vi-execution-speed.html#d55379e372

it says that we must define the VI as Preallocated clone reentrant execution, so it may come from here.

Have a nice day!

Clement

[MaximeR]

Hi,

Thanks for the remark. In fact LabVIEW Accept Preallocated and Shared when you set manually your VI Inline.

In fact I think that setting the VI in Shared will create an instance for all call based on the principle of inlining code.

But I just did the test, it doesn't change anything because the problem is that I cannot revert the setting with a quick drop. You cannot set the VI to Preallocated or Shared to Non-Reentrant from the Quick drop and you don't have any error.

I think that is due to the fact that the VI is in a particular state when called from Quick Drop but I don't understand Why I don't have en error in this case.

Regards

[wiebe@CARYA]

Does it work outside the QD framework?

---

@MaximeR wrote:

In fact I think that setting the VI in Shared will create an instance for all call based on the principle of inlining code.

---

Inlining is not the same as reentrancy. Reentrancy is required for inlining, so they are related, but definitely not the same principle.

Is the QD Plug in set to "Accept Preallocated and Shared"? I think that is the requirement. If the QD plugin is not set to that (apparently) it's not a valid QD plugin.

[MaximeR]

Hi,

thanks for the reply. I know that reentrancy is different than inlining. My remarks was about the fact that the KB talk about preallocated clone and my VI was setting shared clone. But LabVIEW accept both configuration (in 2018 at least) when you manually a VI as inlined. I was just saying that there is no real sense to be shared clone when a vi is set as inline and I imagine that a VI set Inline + shared have a clone for any instance in any case.

But that is not my problem.

Yest it's working by using another VI to change the property of another one. The problem is inside Quick Drop plugin.

What do you mean by :

---

Is the QD Plug in set to "Accept Preallocated and Shared"? I think that is the requirement. If the QD plugin is not set to that (apparently) it's not a valid QD plugin.

---

I was only building some basics Quick Drop in the past and never heard about this option.

Best regards.

[wiebe@CARYA]

---

@MaximeR wrote:

What do you mean by :

---

Is the QD Plug in set to "Accept Preallocated and Shared"? I think that is the requirement. If the QD plugin is not set to that (apparently) it's not a valid QD plugin.

---

I was only building some basics Quick Drop in the past and never heard about this option.

---

As I understand from the link to the documentation, a QD plug in is required to be preallocated and shared.

As you are using the QD to actually set the reentrancy, I thought there might be some confusion.

I'll have a look at the VI, see what I can find.

EDIT:

Had a very quick look.

I don't thing you're supposed to wrap your scripting in a transaction (undo) in the QD. The QD framework should take care of that (and it does, in my experience). That could cause the error, nested undo actions might act unexpected.

[MaximeR]

Hello,

Sorry but I don't really understand your remark. A Quick Drop Plugin VI doesn't need to be reantrant. Or if it is required, it works without this option and some standard QD are not reantrant (Wire All Terminals.vi for Example).

For the Undo action, as I know, you need to define the action to undo with the property node, again like it is done in other QD available natively in LabVIEW. If you don't use it you cannot undo anything after executing your Quick Drop.

I just test to change the reantrancy of my QD, but it have no effects. I cannot unset the Reentrancy of the calling VI from my QuickDrop.

I will try to ask the question in the Quick Drop Enthusiasts Group. I didn't search for it before posting my question.

Thanks again for your help.

[wiebe@CARYA]

---

@MaximeR wrote:

Sorry but I don't really understand your remark. A Quick Drop Plugin VI doesn't need to be reantrant. Or if it is required, it works without this option and some standard QD are not reantrant (Wire All Terminals.vi for Example).

---

That's what I got from the link that was posted. I'm probably mixing up things.

---

@MaximeR wrote:

For the Undo action, as I know, you need to define the action to undo with the property node, again like it is done in other QD available natively in LabVIEW. If you don't use it you cannot undo anything after executing your Quick Drop.

---

I might be mixing up the QD and right click menu extensions. Those RCM plugins don't need an undo, QD might.

[wiebe@CARYA]

---

@MaximeR wrote:

I will try to ask the question in the Quick Drop Enthusiasts Group. I didn't search for it before posting my question.

---

Please do post links from here to there and from there to here.

I looked into it, I'd say it's simply not possible.

Not sure why, but I'd guess some obscurity in that property that was overlooked. note that this property has been available long before inlining and other properties. It's probably related to the QD running in another context, and that property not being allowed to be changed from true to false in that context. But it's a wild guess.

If I absolutely had to make this feature, I'd try to dynamically start a VI in the user context that executes the change of the property. No idea if it would work, but it seems feasible.

[wiebe@CARYA]

---

wiebe@CARYA wrote:

If I absolutely had to make this feature, I'd try to dynamically start a VI in the user context that executes the change of the property. No idea if it would work, but it seems feasible.

---

It doesn't work. The call makes the QD hang, and task manager has to be used to quit LV...