Yair

Any Ideas?

No, I'm pretty sure what you're describing should work. The only things I can think of are either that you have a bug or that .NET behaves differently.

The only thing I can suggest at the moment is the same thing that Rolf did (assuming it's possible in your case) - check the reference inside the LV2G and if there's an error, get a new reference.

Good point. I know that LV aligns to 1 byte on Windows, but I don't know what the C++ code does, so I'll be sure to look at it tomorrow. Hopefully that's the the issue.

I'm working with a C++ programmer and trying to get some data into LV. We've looked at the examples for PostLVUserEvent() both on NI's site (here) and on LAVA and managed to get events in LV.

The problem is that the event data is a struct with a DWord and a few floats or doubles and for some reason when we try to create an equivalent LV cluster (a U32 and SGLs or DBLs) the first integer gets through fine, but the floating points values are completely meaningless.

We also did a quick test with a cluster with just three INTs and we still only get the value for the first one - the other two are always zero.

I don't have the code at the moment (and it's too messy anyway at the moment), but does anyone know what would be the correct C/C++ code to get the event reference from LV (although that part seems to work fine) and to send an event of a struct with a few scalars (preferably with doubles as well)?

If you call the init case in the new hierarchy, you'll get a new reference, which is owned by the new hierarchy, and presumably replaces the original reference, since you only have a single shift register to hold the reference. Once the hierarchy goes idle, the new reference is automatically cleared and you get your error.

...my top-level application calling this LV2G is always running.

It doesn't need to just be "calling" the VI. It has to be the first one calling the VI, because the hierarchy which controls the lifetime of a reference is the hierarchy it was created in.

Another option which might be relevant is that somewhere you close the reference explicitly.

Ah, yes, I keep forgetting about that trick. In any case, as you both said, the event is still exposed and I don't think a better case could be made for not exposing the reference than for limiting it (and it has some other issues).

Now that the discussion has been turned around to this, I remembered that there was already an idea along these lines in the IE. A quick search brought up this, which hardly anyone (including me) voted for. What does that mean? I don't know, but it's another thing to think about.

Wrapping the register for event in a safe class is not an issue. You wrap it in a class and create a method that wraps the register for events node. The only issue with preventing access to the user event refnum is that the event handler frame has access to the refnum. Seems like the feature there should really be the ability to specify at event creation that the handler should not have access to the refnum. This avoids the Registration-Only user event and means your wrapper is free to expose whatever subset of user event functionality is appropriate for your use case (register-only, generate-only, register and generate).

The DVR is a harder problem. The only way to effectively wrap that currently would be to make your safe class have a method that takes a strict VI ref and calls it inside the structure. This would be more acceptable if LabVIEW had some sort of closure/anonymous VI. Giving this the DVR syntax would require a class to define border node behavior for the inplace element structure.

That's interesting, because I see it in exactly the opposite way - the event registration node HAS to be associated with the specific event structure (because the event registration refnum is strictly typed and holds all the events and because splitting the registration refnum to more than one structure creates undefined and buggy behavior), so you have to provide the event reference (or create a member VI for every single type of event structure which will ever be used by someone who uses the event, something which is obviously impossible). Since you have to do that, locking the event reference makes sense and solves the basic issue.

For the DVR, it should be theoretically simple to create a member VI for any type of interaction you want to allow with the DVR, such as this VI which adds:

There is one additional option - rather than restricting this to registration-only events, we could introduce a new Set Reference Permissions node, which will allow you to set specific permissions for a reference:

This would cause subsequent nodes to return errors if they do not have those permissions.

Of course, such a change is considerably more extensive and I don't see it happening, because we do have another solution (one which is also arguably better).

First, Welcome to LAVA.

Second, The properties of the subVI should definitely be remembered in the application if you customized them. Assuming things are working correctly, you should only see something like this under specific circumstances:

1. The main VI is also modal. This shouldn't actually make difference, because if both are modal, the subVI should "win".
   
2. You change the properties of the VI in code.
   
3. You changed the properties of the VI when building the application. This also doesn't seem likely, because it would require explicit actions, but it's also something I would check. It should be found in the Source Files Settings page of the app builder. Selecting the VI and clicking the customize button allows you to change these settings for the build, but again, that should not be needed.
   

I would suggest you check all of these to see if they apply. If not, uploading the code should help, or you could also try starting from scratch (e.g. create a new build spec just to test this).

You bring up a good point which I haven't considered originally, which is that closing the reference is not the only way to abuse it. Other VIs can do all kinds of things with it once they have it and there is no way of creating a single API to define all the restrictions you would want to place.

You're probably right that user events are the only API really affected by this (DVRs could also be, since they also use a structure, but it should probably always be possible to create a member VI which will do the deref-reref actions and have the external VI call that).

I'll consider it some more, but if I'll post anything, it will probably be a request for the register-only event reference. Of course, for something like that you need to ask how the reference is destroyed (e.g. maybe it can only be destroyed when the "real" reference is closed).

Breaking the wire at edit time was my original idea, but it's not feasible, as the problem is not with the wire, but with the reference, and the reference can be transported using other means (locals, globals, etc.). That leaves a run-time check.

Anyone else?

OK, I added an idea for this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-property-to-guarantee-that-the-front-panel-of-a-VI-will/idi-p/1779268

In order for the function to decide that the reference was created within the class, it would to check every single member VI to see if had an input of this reference type

No, it just needs to log which VI creates each reference (something which may well already happen today, since LV knows which hierarchy owns the reference).

I think that the simpler (albeit more tedious) solution would be to never expose an elementary reference type; you'd have to always wrap it in a cluster or class.

But what if you want the library to provide an event people can register for? You can't expose that as anything other than an event reference.

As for the external reference pushed into the library, it wasn't created by the library and therefore would not be protected by this option.

Actually, those are move one. Move all the way require Shift as well.

I want to post the following idea to the IE, but before I do, I would like some feedback.

There are times when we might want to expose a reference from inside a library (e.g. a queue or an event which will provide some data to someone), but doing so allows the non-member VI to close the reference:

In some cases this can be avoided (e.g. in the queue case you can output an object and a wrapper around the dequeue primitive, so that the caller doesn't have the queue reference and can't destroy it), but this can't be always avoided (e.g. the event reference).

For such cases I would like to propose that libraries gain a new option:

When this option is checked, any function which closes a reference (close reference, close file, release queue, etc.) will check if the reference was created in a member VI and in that case will only close the reference if it is called from a member VI. If it's called from another VI, it will not close the reference and will instead return an error. This will allow libraries to guarantee that references that they created remain valid as long as they don't close them explicitly.

A couple of comments:

1. The example shows a class, but this should probably apply to all classes. At least XControls can probably gain from this.
   
2. Named references will behave like other references, so if you open two references to the same notifier, one inside the library and one outside it, the one opened outside it can be destroyed by anyone (although I'm not sure how the Force Destroy input should behave in such a scenario. Does anyone have thoughts on this?).
   

What do people think of this?

Your image wasn't attached, but in general, the Z-order of front panel objects is controlled by the reorder button:

So just select the decoration and then move it all the way to the back.

Like asbo said, you need to open the VI. Looking at it now, I can see that arg 8 is flow control.

NI has a Modbus library for LabVIEW - http://zone.ni.com/devzone/cda/epd/p/id/4756

You'll need to find the relevant registers and coils for the device yourself in the device documentation.

The error comes not from the VI itself, but from the property node inside the VI. The arguments in the property node go from top to bottom (i.e. the top argument is argument 1). You can count down to 8 to see what's the property that's returning the error (although I don't know if that will help you. USB to serial adapters are notorious for having problems and it's possible you might need to reinstall its driver or get another one).

I have no experience with something like this, so there may be better ways, but if you open the log window, you can select multiple revisions (using the Ctrl or Shift keys) and then right click and copy to the clipboard. I believe this copies all the relevant data to the clipboard, which you can then parse and re-format using LV.

Having to do workarounds like this makes me wonder why a VI property isn't added to force a FP to be included.

There's certainly no technical reason. I'm guessing that no one ever thought of it, because usually it's not needed (i.e. either the VI doesn't need its FP or it has the FP included due to the normal configuration of the code, such as having the FP set to open when called).

The build configuration dialog does allow you to override the remove-FP setting for every VI, but I don't like that, because it's very hidden and you have to set it for each build separately. If you add an idea for such a VI property to the IE I would certainly vote for it.

So instead of creating a implicit property node or control reference constant to get a panel included in a build, you could hide the panels scroll bars.

With one important difference - it's much easier to document why you have an unused property by placing a comment next to it than to safely document why the scroll bars are hidden (safely = in a way which will make it unlikely that someone will accidentally change it).

See this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-property-of-Method-to-indicate-if-an-input-of-a-sub-VI-is/idi-p/926281

False is indeed correct*

That said, If you create a static property node for a control on the front panel, the front panel will always be loaded. This has actual value because when you build an application, the default behavior for most subVIs is to have their front panel removed and there are certain VIs where creating a property node is the easiest way to force LV to keep the FP.

* Although, with the history of the CLAD questions, it's quite possible that the expected answer is not false because of what's in the second paragraph

So the answer to my question (from the UI's loop perspective) is "I send the request when the user clicks the image, but since I only use the result later, I can keep moving on". This simplifies the issue I had, because the system doesn't need to know something is going to happen in advance - the request is only sent after the user clicked the image.

There's still something I don't understand about your original example - when does the UI loop send the request for the updated data? Since we can assume the MC loop will handle it "instantly", the request can't be made a long time before you need it, because you want updated data, but it also can't be made too late, because that's exactly what you wanted to avoid, so how do you know when to send the request? Where would it fit into the code? It's easy to request the data when the code starts running or when you actually need the data, but I'm having a hard time imagining a piece of code that says "I know I'm going to need the position data 5 seconds from now, so I'm going to ask for it now", since code is generally not aware of upcoming events or states unless you would add a special "pre-check" event/state/whatever which will be responsible only for this.