ADVANCED: How To Call The Mac OS Directly From LabVIEW Part II: Converting Data for Ease of Use
See Part I of this series for the obligatory warning about using the Call Library Function Node.
Let's look at some examples that shipped with LabVIEW 8.0. In vi.lib/Platform, there is a VI, Mac Key Modifiers Down.vi. This VI wraps a call to GetCurrentEventKeyModifiers. Like TickCount in Part I, this function just returns a UInt32,
We could, just like in TickCount, return the UInt32. There are two reasons, in this case, not to. We're writing LabVIEW code and we are writing Mac code. Both reasons encourage us to make the interface more elegant. If you look at Table 2-1, you can see the C defined constants, but that doesn't help us much in LabVIEW. So if you look at Events.h you can see the rest of the constants. You can see that the keyboard bits don't start until bit 8 (cmdKey[Bit]).
So we take the output from the Call Library Function Node, and connect it to Number To Boolean Array primitive (Programming -> Boolean). Then we use an Index Array primitive (Programming -> Array), and grow it. We set the first index to 8 (bit 8) and the rest will be sequentially bit 9, 10, etc. We can then create a cluster indicator on the front panel that has all the boolean values we need.
The version of this VI that shipped with LabVIEW 8.0 used a cluster constant to wire into the Bundle by Name primitive (Programming -> Cluster & Variant). I have since decided on a better way. You can control-click (right-click) on the newly created indicator terminal and select Create -> Local Variable. Then control-click (right-click) on the new local variable and select Change To Read. Then wire the output from the local variable into the Bundle by Name primitive's input cluster. This way if you change the indicator, you do not need to change the constant, it makes the code more robust.
And there you have it, we have made a more usable interface for the data returned from a call to the OS. In part III, we will go more in-depth on data types passed into and out of the Call Library Function Node.
Let's look at some examples that shipped with LabVIEW 8.0. In vi.lib/Platform, there is a VI, Mac Key Modifiers Down.vi. This VI wraps a call to GetCurrentEventKeyModifiers. Like TickCount in Part I, this function just returns a UInt32,
We could, just like in TickCount, return the UInt32. There are two reasons, in this case, not to. We're writing LabVIEW code and we are writing Mac code. Both reasons encourage us to make the interface more elegant. If you look at Table 2-1, you can see the C defined constants, but that doesn't help us much in LabVIEW. So if you look at Events.h you can see the rest of the constants. You can see that the keyboard bits don't start until bit 8 (cmdKey[Bit]).
So we take the output from the Call Library Function Node, and connect it to Number To Boolean Array primitive (Programming -> Boolean). Then we use an Index Array primitive (Programming -> Array), and grow it. We set the first index to 8 (bit 8) and the rest will be sequentially bit 9, 10, etc. We can then create a cluster indicator on the front panel that has all the boolean values we need.
The version of this VI that shipped with LabVIEW 8.0 used a cluster constant to wire into the Bundle by Name primitive (Programming -> Cluster & Variant). I have since decided on a better way. You can control-click (right-click) on the newly created indicator terminal and select Create -> Local Variable. Then control-click (right-click) on the new local variable and select Change To Read. Then wire the output from the local variable into the Bundle by Name primitive's input cluster. This way if you change the indicator, you do not need to change the constant, it makes the code more robust.
And there you have it, we have made a more usable interface for the data returned from a call to the OS. In part III, we will go more in-depth on data types passed into and out of the Call Library Function Node.
posted by Marc | 1:29 PM
0 Comments:
Post a Comment
<< Home