Yair

If you're not using any of the DSC features, you should consider using Datasocket or the shared variables themselves to connect directly to the OPC server. That would require changing the code, but should not require any run-time licenses.

OK, for this one NI needs actual feedback. Which is better? .........or......... Should the index inputs on LVOOP array element accessors be required? Read the comments there and then vote (or not): http://forums.ni.com...d/idi-p/1851907

The compiler can't realize this (because the control might be controlled externally, for instance by the Set Control Value method), which is why NI used this method (converting constants to controls) to maintain backward compatibility when you upgrade code from before this optimization was added to the compiler (which was LV 8.0, if memory serves).

Cross-posted here - http://forums.ni.com/t5/LabVIEW/Database-Errors-after-switching-to-MS-SQL-Express-Database/m-p/1844547/message-uid/1844547#U1844547 I'm with asbo - search for the exceptions online. Also, you could try wrapping your DB actions in non-reentrant VIs, so that they don't execute in parallel, but that's just a broad statement.

There is another thing hiding in here - NI has a relatively new tradition of holding annual CLA summits, which are supposed to be both free and advanced (but you have to be a CLA to attend). My understanding is that this is exactly the kind of thing you want and will allow you to interact with other CLAs. I believe the next one is in a couple of months, so I don't know if you'll have time to certify before that, but if you do, you should probably take that into consideration as well.

AQ, I think the problem is that you're misunderstanding what Jon wants - he wants to find the specific class on a wire in another VI, since this is supposed to be an edit-time scripting tool. For that, he needs the actual value in the wire.

For that you need the actual value on the wire, which I'm pretty sure is not exposed through VI server (probably since before the retain values option was introduced this was considered to be dangerous, because it meant LV could not safely reuse buffers and after the option was added no one bothered to add such a property).

For those who haven't seen it, Norm's tool is here and there's also a link for an idea to make this easier, so you should go vote for that.

See? you're already becoming a user. In the past you would have use "the long run" for 10 years, so that's already an improvement. But seriously, I'm sure LV R&D has enough smart people in it and it matters less exactly where you are as long you do something productive and keep being involved with the community (and ideally if you can get others to be involved as well). Personally, I really welcome this change to LV that you're describing and I think that it's excellent that NI is putting efforts into making this transition organized and structured. I'm hoping that because of this change, LV 2017 will see considerably more improvements compared to 2011 than 2011 has compared to 8.2. The only criticism I have is "why so long?" (I am a customer, after all).

I just added an idea to have this as a native option - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-option-to-open-LVOOP-accessor-VI-from-the-property-node/idi-p/1832349

It's not coincidence. Look one post above yours.

Not that I really want to get involved, but since you dug it up - in this video you don't just take the class name. You rely on every class inheriting from constant to have "constant" in its name, which could fail (for instance, knob and digital inherit from numeric). This could also be a problem with other classes which are called constant but don't inherit from constant, but that's presumably not an issue, because at most the cast will fail.

You should be able to neutralize that fairly easily, by using the same trick you used - cast a constant LVObject to both classes to get the default value of each class and use that default value for testing. This will complicate the diagram, but it's still more explicit (which means safer, at least in my book) than the comparison method.

I understand how the code works. My theoretical case was of two different classes which have the same default data. Like I said, IF the equality primitive only checks the data (and I don't know if it does) then this case will return a false positive. There might also be other potential failures. I don't care about the equality. My suggestion was to only check the error (which is why I believe this should be more robust, as this is a casting mechanism, not a comparison mechanism). But again, I didn't test this, so we need some actual code.

I'm not sure if your method fully works, because if the equal primitive only compares the data, it will presumably also return T if you have two different classes with the same data (which is obviously not something which is likely to happen). In any case, I can think of another option where the code is simpler - Call PRTC twice, just like in your code, but instead of using a constant as the input, use 2 as the input for 1 and 1 as the input for 2 and then check the error. If neither has an error, that should mean they're of the same class. I didn't test this, but I believe it should work, because that should be the only case where you can successfully cast both to each other.

Jon isn't one of the CCT developers. That would be Ton (mostly) and me.

I don't know what that question means. I suggest you start a new thread with proper details of what you want and what you already tried. Images also help.

I don't know that one (and it doesn't actually matter where in the file you place the line), but if it does what I think it does (not show tip strips when you hover over terminals of VIs, primitives and nodes), I would suggest setting it to True, as I at least find that behavior to be very useful.

The IDE doesn't provide a UI for disabling this, but there is an INI key which works. Add the following line to the LabVIEW.ini file and restart LV: showTipStringsOnDiagram=False

I certainly didn't run into specific problems with this and I'm guessing Norm hasn't either. The point was that not all references behave the same and it's not a given that the R4EN returns a new reference if it's called in the same subVI without a reference input. It probably does, but unless it's documented, it's something which is suspect until demonstrated otherwise. There are certainly examples of nodes which don't return a new reference (or at least one example - generate occurrence always returns the same reference).

The output of the Register for Events node (R4EN) has to go to a single event structure. If you connect that reference to more than one event structure, you're going to get undefined (=weird) behavior, such as events being processed by multiple event structures or by none at all, without any predictability. What Norm was saying is that you can't necessarily trust that if you put the R4EN in a subVI that you will get a separate reference each time the VI runs. Maybe you would, but without testing it thoroughly you can't be sure. This is made much worse if you take the reference and save it, because then you increase the risk of using it with more than one event structure, a danger which doesn't exist if the R4EN is wired directly to the structure. If you want more details, you can look at this old thread - http://forums.ni.com/t5/LabVIEW/Register-for-events-causes-freezes-if-used-in-more-than-one/m-p/497567#M237840

Well, we discussed it here in the past, although I have to admit I never had the need to use something exactly like this in a production app, so all the stuff there is just quick and dirty experiments. I haven't looked at the entire discussion there now, but if memory serves, the two interesting points you can find there are the basic difference in calculation (it was the ratio of the control relative to the panel as opposed to constant margins, although I'm not sure what the implications of each are) and that there is an example of a generic (but undocumented) resizing method (which is probably the same code LV uses when the user manually resizes a control).

I get the feeling that when we tested earlier in the week, there was some mix up when we working back and forth, because one of the older DLLs which was supposed to have an int and didn't work, was actually returning float data, so when I replaced the I32 with a SGL, that code started to work fine.

OK, I'm not sure why, but he says that now it seems to be working regardless of which packing he sets. Here's an example which includes an 8.6 VI, the C++ source and a DLL compiled in Visual Studio 2008. This seems to work fine, but, as I understand it, isn't essentially different from what we did earlier in the week, so I'm not sure why it didn't work then. When you run the example, you should get a running counter in the int and 1.1 in the other two. Thanks. DLL LV Event.zip

It is indeed VC++, so the alignment may well be the issue. I relayed the info to the C++ guy and hopefully by tomorrow I should have an answer. AQ, I think he simply copied the example code and then added the struct, since the second parameter for the function is supposed to be LV data. In the case of the test code with the ints, it looks like this: typedef struct _EventSend { _EventSend() { dwMask = 0; iA = 0; iB = 0; } DWORD dwMask; int iA; int iB; } EVENT_SEND; EVENT_SEND eventF; // snip... //The code is actually supposed to work with several devices, so we keep several event references in an array PostLVUserEvent(*(lvUserEventRef[iDevice]),(void *)&eventF); } [/CODE] Once we get it working, I'll get him to create example code which (if you want) I can then send you so that you incorporate it into the original document (or I can add a comment there with a link).