Leaderboard

Here is a link to a thread on this topic that you may like to read: http://lavag.org/topic/14759-can-i-override-private-data/

Well you are right that Flatten Variant doesn't work. I was mislead by a quick trial and had no time to verify further as I had to leave for private obligations. However I can't accept defeat so I remembered another post where someone wanted to have an VT_NULL Variant and investigating into the solution I have come up then showed an easy and totally official way to do it. The VARIANT memory layout is fully documented on MSDN and the LabVIEW Call Library Node supports explicitly the ActiveX Variant type. So simply passing the Variant as ActiveX Variant pointer to a C function that looks at the first two bytes in the structure is all that is needed to get at the VT_ values. Enclosed are the VI to create specifically a VT_NULL variant and the VI to read the VT_ type. I haven't entered the entire range of VT codes into the enum and since those codes are in fact not continous it is probably better to use a Ring control instead but that is an exercise left for whomever is wanting to use this VI. Get OLE Variant Type.vi NULL Variant.vi

LabVIEW has no official support for right-to-left languages. I can say that it sort of works with Hebrew (in ASCII) if you know what you're doing, but I haven't tried with Arabic, so I don't know about connected letters. In any case, even when it does work, as soon as you add in anything which isn't part of the R2L set (such as a comma or a hyphen or a number), the display gets reversed. If you're on Windows, you can try using a .NET or ActiveX control and using the rich text box. That should display the text correctly.

LabVIEW will preallocate the array at the max size and truncate as you suspected.

...and also the upcoming version supports many more classes in the Project Windows and the UML Class diagram for the community user.

It took me a little while to understand that "namespaced" meant using the build option "Apply prefix to all contained items" in "Source File Settings" for dependencies in the build spec. Once I made that connection everything makes sense. This isn't really namespacing. This is changing the name of every dependency. So after the build Caller.vi references a class named "namespace.Shared Class.lvclass". Since Callee.vi didn't go through the build, it references the class "Shared Class.lvclass". A VI that has a single input of type "Shared Class.lvclass" is not going to match a strict VI reference with a single input of type "namespace.Shared Class.lvclass" so the open of the reference fails. If you are going to rename the class during the build, then all plugins must be rebuilt against the renamed version. You can't really do that if the renamed version is only present inside the application. There are a few other options though. You could include your plugins in the application build as "Always Included" files. This doesn't create much of a plugin framework, but in some cases that is acceptable. You can make the application build put its dependencies outside the application. Create new destination for a sub directory, then change the dependencies to build to there. Then in your plugin projects (Callee's project) reference these files instead of the original "Shared Class" source. Then when Callee is loaded, it will agree on what all the dependencies are named. This is similar to the solution of creating the shared items as another build, but avoids actually having a separate build step. You can build the shared items as a separate distribution and have both "Caller" and "Callee" projects reference that build output. This doesn't have to be built as a PPL. It could just be a source distribution, but either way it requires a separate project and build increasing maintenance. You can not rename shared dependencies going into the application. For items that will be referenced from plugins, you can add them to the project directly (instead of having them just show up in dependencies) and not have them be prefixed. This also will make it clear which items are valid to be referenced from plugins. That makes it clear to you which items might break plugins if you modify them and easier to tell others writing plugins what things they can reference versus items they should not reference. Many other variations of these themes. To decide which approach to take, I'd want to know what you are really trying to get out of using a plugin approach. Who is going to be building the plugins? Are the plugins supposed to be able to update independently of the application? Should the application be able to update without invalidating the plugins? What VIs/classes used in the application should be able to be referenced from the plugins? What were you trying to accomplish with the name prefixing option?