candidus

Depending on your use case, maybe you can use the 3D picture control? Here is a snippet that renders text into a texture, applies that texture to a box object and displays it.

Hi there, here is something I wrote recently and presented on our user group meeting last week. Labricks is a clone of the old-school video game Breakout. I dreamed of programming my own Breakout clone since I first played MegaBall on a friend's Amiga 4000 in 1996 :-) My implementation uses the 3D picture control and classic OOP. Features: - Hall of fame (List of best scores) - Old-school game sound - Random board (level) generation - Generally usable base classes that provide 2D collision detection and rendering The game is playable but not finished yet. Here are some TODOs: - Fix issues regarding collision detection (ball - paddle) - Fix sound delay on Linux - Test it on Mac - Power-ups - Loadable levels - Make it more challenging (e.g. increase the ball's speed over time) Comments are appreciated, have fun ;-) candidus Labricks-20150508-LV2010.zip

I went with option A for one of my projects and I'm still happy with it (admittedly the class hierarchy was not big). Here is another idea: Maybe you even don't need parameter accessors. Make the argument a class that you use as a base for your parameters, let's say Parameter.lvclass. This class has a dynamic dispatch VI, Configure.vi. Derive classes from Parameter.lvclass, overriding Configure.vi. These different implementations of Configure.vi encapsulate the parameter access.

XML can be tricky because it's refnum-based. Use error wires to force the execution order of the invoke nodes. The following snippet adds an attribute "attr"="1" to the <properties/> element.

Hi Bjarne, In all these cases the code runs in different processes and thus in different threads. If you try the same in a single application instance this might result in a deadlock. There is a synchronization object that is thread agnostic: The semaphore. I would use a semaphore of size 1 instead of a mutex.

I'm afraid this can't work. You don't know in what OS thread a particular block diagram section runs. You can't even be sure that the Invoke Nodes WaitOne() and ReleaseMutex() on the same wire are called by the same OS thread. Manipulating OS threads is unreliable and dangerous in LV. Consider using lockfiles or TCP/IP instead.

Try to use an older version of VIPM for Linux. VIPM isn't tied to LV versions. You need, however, a compatible LV runtime engine. The latest version of VIPM for LInux available is 2011 and should work flawlessly.

In one of my projects I have multiple event structures in the main VI, but only one of them handles UI events. The other ones are part of consumer loops that update live image views on the front panel. and moving them into subVIs seems not to be the right option here: I don't want to update my front panel controls via control references where performance is required...

Is DCOM a strict requirement? Otherwise you could use VI server via TCP/IP. DCOM is quite complex to implement and configure, Setting up the network authentication can be really frustrating. Avoid DCOM if you can...

Best resource is indeed MSDN: On http://msdn.microsoft.com/en-us/library/yy6y35y8%28v=vs.110%29.aspx you can find information how parameters are used when working with OLE DB, ODBC or MS-SQL in .NET , ODBC in .NET is provided via ADO.NET which is similar to ADO ActiveX. Most important, you can't declare parameters as @param, you have to use a question mark instead and pass all your parameters in the right order. I stumbled upon that when I had to write a data table editor in C#.

First thing that comes into my mind: struct alignment. LV clusters are byte aligned, the default alignment when working with Visual C++ is 8 bytes. Your DLL vendor probably didn't change that, so you might need dummy elements in your cluster to ensure every data member starts at a multiple of 8 bytes.

As mentioned in the NI forum, the Database Connectivity Toolkit is essentially a wrapper around an ADO ActiveX object. ADO uses an ODBC connection internally and there are syntax differences when using ODBC compared to using MS SQLServer directly: @variable declarations are not supported via ODBC.

Open the library and enumerate its contents:

Here is something that worked for me (admittedly my class hierarchy was not big): - Create the target folder. - From your project, save every single VI of the class in the new target folder via Save as -> Rename. - Rename and save your class in the the target folder. - Save all affected VIs in the project. If you renamed a folder outside of LV it can help to edit the project file manually. And sorry, not renaming can't be a solution. Code that uses wrong type names or function names is bad, IMO. The possibilty to refactor code is essential, especially when you have to maintain a project for a long time or work with legacy code.

I don't want to extend enums at runtime but at compile time. Here is my use case: I have a class DeviceContainer.lvclass that manages objects of type Device.lvclass in a map. DeviceContainer.lvclass has a dynamic dispatch method GetDeviceByID() . It takes a parameter of type enum DeviceIDEnum.ctl and returns a device object. I chose enums over rings because the name strings are part of the typedef and the case structure handles them nicely. So to speak, I use an enum as a collection of string constants. DeviceContainer.lvclass has child classes. Every child class supports a different set of devices but at least the one defined by the base class. That means I have to override GetDeviceByID() to support another enum type and now things get complicated: I don't want to modify DeviceIDEnum.ctl of the base class. My current workaround is to pass the enum as a variant and define the appropriate enum for every child class. Enum classes could help here: First, the ID parameter of GetDeviceByID() is of type DeviceIDEnum.lvlass . The parameter is type safe and extensible now, I can pass any child class of DeviceIDEnum.lvlass . Second, no mdification of the original DeviceIDEnum.lvlass is required. I can inherit from it. OK, while I'm writing this I get the strange feeling that I'm thinking way too complicted...

I'm thinking about extending enums in a type safe manner: The enum is stored as a variant member in a class, EnumBase.lvclass . EnumBase.lvclass provides three methods: public GetValue() protected SetValue() public GetEnumTypeName() A concrete enum class is derived from EnumBase.lvclass and must provide getters and setters for the enum type. We can extended such an enum class by inheritance. Getting the right enum value requires two steps: First we have to use decide which getter must be used, depending on the return value of GetEnumTypeName() . Unfortunately we must use strings here. Then we can call the appropriate getter. Any comments appreciated! ExtensibleEnum.zip

I don't think that lvlibps include dependencies from vi.lib (haven't verified it, though). The contents of vi.lib should be the same on all machines, missing parts probably indicate missing device drivers or addons.

Checkout both revisions into different directories (both directories must not be in LV's search path) and use different project files to avoid conflicts. For example: Directory TestProjectA contains Library_rev1000 and project file TestProjectA.lvproj Directory TestProjectB contains Library_rev1001 and project file TestProjectB.lvproj Another approach could use lvlibs that are named by revision, e.g. Library_rev1000.lvlib and Library_rev1001.lvlib but then your users must relink their tests everytime your library revision changes. I doubt they will like that...

Abstract classes and final methods are supported, a static dispatch VI is very similar to a final method. But interfaces would be really nice. Another idea: Duck typing. If we could cast between objects that provide the same public methods but are otherwise unrelated we wouldn't even need interfaces :-)

Another thought: Some problems the Disruptor pattern solves in Java we don't have in LV, e.g garbage collection issues. It could however be worth trying to implement it in LV because we were able to build a producer/consumer architecture that doesn't suffer from stalling when producers and consumers run at different speeds.

I just watched the LMAX presentation and found it quite impressive. However, I don't think this architecture will increase performance when used with LV: The parallelism of LV doesn't help us here. As I understand the Disruptor pattern, RingBuffer access must be sequentially, there seem to be good reasons to access it from only one thread.

Hi folks, I recently thought much about error handling. Here is my current approach. The idea is simple: There is a base class, ErrorInfo.lvclass, that is flattened to string and wrapped in the source field of an ordinary error cluster. Child classes of ErrorInfo.lvclass can provide any error properties you need. The example contains a class ExtendedErrorInfo.lvclass that has two properties, severity and timestamp. Some details are inspired by posts here on LAVA. Any comments appreciated :-) candidus ErrorInfo-20130624.zip

This might be a shutdown issue of your component. If it didn't shutdown yet and you try to reopen it all kinds of evil things may happen. I don't think this is a LV related issue. Here is an ugly idea how to solve it: Do some tests how long a proper shutdown takes and add an appropriately long delay before returning from your VI. IMHO any other approach would involve external code.

First I thought A), then I switched to D) XControls are great but they have their limitations. I've written some XControls over the years I don't want to miss anymore. But I also remember situations where subpanels did a better job and were easier to maintain. If you need the same custom control with some logic behind it frequently in your project then an XControl is probably a good choice.

Yes. There's only reentrancy if you explicitly make your method VI reentrant. In many cases this might not be a problem, though. What are you trying to accomplish?