Leaderboard

I put together a series of articles while working on an AF 101 presentation for our local CLD summit. Check them out and let me know what you think or if you have any questions/improvements. Part 1 – The Background Part 2 – The Actor Part 3 – Launching and Communicating Part 4 – Being Productive With Actors Basic Walkthrough – Creating a Logger

Stop using the 0x40 pool option. You don’t want a reference to pool of clones. Try just 0x8.

Does anyone have a solution to detecting where a drop occurred on a target tree control? I'm already familiar with the 'Point to Row Column' method. However, that only returns the row of the item you mouse is hovering over during the drop. See, when a user moves his mouse around, a line is shown exactly where the insert will occur. However this line location, between rows, is not available from what i can see. Regardless of where the line is drawn, the 'Point to Row Column' method returns the mouse hover location instead.

Another question James, this one is more academic. I'm trying to maintain zero-coupling between my actors, and in the current situation I have two independently designed actors called View and ConfigData. ConfigData stores and retrieves the application information from file, including an array of a cluster that contains two elements: the Title (string) and Path (path) of the most recently opened Projects. View actor hosts the User Interface and customises the menu to show the four most recently opened projects, stored internally as an array of Title strings. Whenever the application opens a new Project it must inform ConfigData of the project name, and if this results in a change to the arrayed list of recent projects then the revised list must be shared with View so that it can be ready to show the latest information at all times. So, there are numerous options available for sharing the revised list between ConfigData and View, but I want to maintain zero-coupling - that is, View cannot know of the existence of ConfigData, and likewise ConfigData cannot know of the existence of View. I can use the Observer-Notification registry in ConfigData actor to push updates out, and subscribe to these in View as events. But something else needs to create this binding because these actors can't know of anything outside of their simplified existence. In steps the launching actor Main. Main launches View and also ConfigData and can establish a communications link between them such that changes in ConfigData are immediately sent out on the Observer register to subscribed View. But their datatypes are different, so they can't simply pass the information between themselves because ConfigData's cluster array isn't the same as View's string array. To maintain zero-coupling I cannot simply change one of their datatypes, so there needs to be some conversion of the data somewhere between. (Actually, it probably helps in this example to consider these two actors as something much bigger, with far more complex data payloads to share. That way the simple answer to change one to match the other cannot be recommended). I see from the Messenger Library there are Translator methods, which can cause messages between actors to be mutated, and the data payload adjusted. How do you properly use these to morph the outgoing message from ConfigData into a suitable message for View? I expect that getting Main to establish this translation link will mean both View and ConfigData remain zero-coupled, and also Main doesn't have to maintain a role in the communications whenever a message is passed, which is good for performance of Main. The key for me here is: 1. View and ConfigData must remain zero-coupled (the ideal for any system of reusable actors) 2. Prevent the need for the parent actor Main to be continuously aware of and monitoring the communication path, translating the payload data each time and distracting it from it's primary duties. If I understand Translate properly, it looks to me like an excellent way to establish links between zero-coupled actors without having to establish a route through a parent actor, or any other actor. But maybe there's a better/simpler way?

3,6,9 Due to data dependency and loop iteration, the calls are sequential. Since the subVI must be a shared clone, only 1 clone is ever needed and thus 1 data space.

Not sure how 0x8 and 0x40 options interact, but with 0x40 you are creating three shared clone pools, so the answer would be three values between 1 and 3, depending on how LabVIEW assigns idle clones in the pool. With just 0x8, you’re making three clones, and the answer is [3,3,3].

With the load option as 0x48, that means your Sub.vi is going to have to be set for shared clone reentrant execution, so I'd say you'll get [3,6,9].

I have created a new package with an updated version of the OpenG ZIP library. The VI interface should have remained the same with the previous versions. The bigger changes are under the hood. I updated the C code for the shared library to use the latest zlib sources version 1.2.8 and made a few other changes to the way the refnums are handled in order to support 64 bit targets. Another significant change is the added support for NI Realtime Targets. This was already sort of present for Pharlap and VxWorks targets but in this version all current NI Realtime targets should be supported. When the OpenG package is installed to a LabVIEW 32 bit for Windows installation, an additional setup program is started during the installation to copy the shared libraries for the different targets to the realtime image folder. This setup will normally cause a password prompt for an administrative account even if the current account already has local administrator rights, although in that case it may be just a prompt if you really want to allow the program to make changes to the system, without requiring a password. This setup program is only started when the target is a 32 bit LabVIEW installation since so far only 32 bit LabVIEW supports realtime development. After the installation has finished it should be possible to go in MAX to the actual target and select to install new software. Select the option "Custom software installation" and in the resulting utility find "OpenG ZIP Tools 4.1.0" and let it install the necessary shared library to your target. This is a prelimenary package and I have not been able to test everything. What should work: Development System: LabVIEW for Windows 32 bit and 64 Bit, LabVIEW for Linux 32 Bit and 64 Bit Realtime Target: NI Pharlap ETS, NI VxWorks and NI Linux Realtime targets From these I haven't been able to test the Linux 64 Bit at all, as well as the NI Pharlap and NI Linux RT for x86 (cRIO 903x) targets If you happen to install it on any of these systems I would be glad if you could report any success. If there are any problems I would like to hear them too. Todo: In a following version I want to try to add support for character translation of filenames and comments inside the archive if they contain other characters than the ASCII 7 bit characters. Currently characters outside that range are all getting messed up. Edit (4/10/2015): Replaced package with B2 revision which fixes a bug in the installation files for the cRIO-903x targets. oglib_lvzip-4.1.0-b2.ogp