Ryan Podsim

I'm wanting to create a VI that will add a predefined set of Registry entries to the Installer build spec for a project. Previously we have entered these items by hand through the build spec properties, but would like to speed up the process and reduce errors. I have found the Set Tag and Set XML Tag methods for a build spec, but that doesn't seem to work right. I can create the tags for the RegDest.dirName and RegDest.parentTag, but can't figure out how to get a new RegDest.dirTag; as it seems to be some special code. Without that code, I seem to be unable create the entries correctly.

Does anyone know of some hidden built-in VIs that can create the registry entries for Install specs? or how I can generate the special Code for RegDest.dirTag?

Here is a sample from the lvproj file of a valid spec (i.e. created by hand)

<Property Name="RegDest[0].dirName" Type="Str">Software</Property>                                  	<---- part of default Spec

<Property Name="RegDest[0].dirTag" Type="Str">{DDFAFC8B-E728-4AC8-96DE-B920EBB97A86}</Property> 	<---- part of default Spec

<Property Name="RegDest[0].parentTag" Type="Str">2</Property> 					   	<---- part of default Spec

<Property Name="RegDest[1].dirName" Type="Str">BEI</Property>

<Property Name="RegDest[1].dirTag" Type="Str">{D462230D-D253-433D-9A2C-E694E552E45B}</Property>   	<---- special code!!!!

<Property Name="RegDest[1].parentTag" Type="Str">{DDFAFC8B-E728-4AC8-96DE-B920EBB97A86}</Property>

.....

<Property Name="RegDestCount" Type="Int">5</Property>

[/CODE]

One of the main reasons I like the terminal style is I can identify a terminal at a glace. Where as with the icon style, I have to think for a second to differentiate between a terminal and a subVI. I suppose, if I use the icon style that would become easier with time.

I prefer the small terminals.

I do find it interesting that one of the first items covered in LabVIEW Core 1 is "Here is how you turn off the large icons."

Actually the P/C pattern, since it uses a queue for communications. doesn't really support multiple control any more then a Notifier would. In both you still have the multiple to single implementation, but with a Queue (hence a P/C) you are restricted to a single consumer, where a M/S is not (through the use of the notifier being * to many). So I suppose the main difference between the two are the M/S can support multiple Slaves but the P/C can support multiple producers.

An example for a P/C would writing to a File. You might have multiple locations in your program that want to right information to a file (IE a log file) so a P/C style implementation would be appropriate. But for a test you might have multiple inputs (IE User interface, DAQ, power, ...) that could interfere with the running of the test, in which case you might want to use a M/S style implementation. Its not uncommon for a single program to use both methods. If fact I use and combination of two on a regular basis.

My understanding is, in the Master/Slave the Slave only cares about the most recent command the Master sends, hence it can miss commands. Where as, with the Producer/Consumer the Consumer CANNOT miss commands and and therefor must be buffered. The P/C also assumes that Consumer can process commands Faster then the producer can create them. If the reverse is true than the problem of the infinite buffer becomes an issue, as your would eventually run out of memory.

In my opinion the M/S works best for UI type implementations and the P/C works best for DAQ type implementations. Personally I don't use the M/S.

Just a note:

The LabVIEW Mobile Module only works with a Mobile device running Windows Mobile 5.0, Windows Mobile 6.0, or Pocket PC 2003. as per LabVIEW 2010 Mobile Module Readme

I think the PDA module might have supported Palm OS but don't know for sure.

Are you changing the code at all? If not, then there is no need for each child class to have that VI, just call the parent VI.

I'm about the same SuperS_5, gaming has taunt me how to cover a full keyboard with one hand, even the big split keyboards (which I love ). I used to use a track ball for years, but thumb muscles finally decided they didn't like it, so now I just use a regular optical mouse. Though, I do use a high precision mouse at home. (still trying to figure out to convince the boss to buy me a $150 mouse for LabVIEW. ) My really don't like using LabVIEW on a laptop or a track-pad. Oh and single low res monitors just make me cringe. I usually have to many VIs open at once, so I love screen space. I'm a bit spoiled with my Dev Machine, dual 23" wide screens.

My question is "Why do want your Parent Class Project to see your Child Class?" Are you using the child class in the project? Do you just want to see what children are available? (If so, Why? and what if it's 100 children?) The structure is setup such that the Parent does not know about it's children unless they are actively loaded (i.e. used in the project). The Find->Children only works within the project context, if you were to do the same action in you child project on the parent class you would find the children

When you say,

Because of this my dynamic vi's don't work.

what do you mean? Which class are using? If you using the parent class then the Dynamic Dispatch will call the parent VI's. If you are using a child class then it will call child override VI's and you would see the child in hierarchy. If you could post some sample code or even screen shots that would help to solve your issue.

The graph you shown is a Waveform Chart and does not have cursors. You need the Waveform Graph to use the cursor functions.

Private data of a class cannot be overridden, only functions.

In your second example you have a parent Vehicle class with one element Numeric (I'll represent it as Vehicle:Numeric). Then you created a Child (Car) that adds the element Numeric (Car:Numeric). So when look at the instance of Car it has two elements Vehicle:Numeric and Car:Numeric. When you are calling the Parent function of Car to increment Numeric, the parent function is incrementing Vehicle:Numeric since that's the element it knows about and is told to increment. If you want to increment Car:Numeric then you need a Car function.

Note: Since the Data is private to it's class if you want Child classes (or anyone else) to have access to the private data, you will need to implement access functions.

I noticed that as part of the solution you used the FP.NativeWindow. Is that one of those super secret properties? cause I can't find it anywhere in the listing.

Not quite sure if this is what you looking for, but check out the CI.CountEdges.Term property of DAQmx Channel. It gives you the ability to change switch terminal the Counter uses.

Actually, the Shift Right with Carry is O(1); since all processors (to the best of knowledge) have a shift instruction making it a single instruction (perhaps 2, if you include the register check), rather then the 3 from you version. As for a memory efficiency, I'm pretty sure that no data copy is made since the shifted value is not used. Feel free to benchmark it, I found that the Shift Right with Carry had a 2x improvement using a 64bit Integer. Though unless your doing millions of Is Odd evaluations the calculation time is insignificant. I just don't see a reason to have an OpenG function for this operation, since the Shift Right with Carry in already available.

I included the VI I used for the benchmark.

Is Odd.vi

Yes, that's the node I ment. Working with LabVIEW FPGA I make use of that function all the time. The same node is also useful for divide by 2, along with the shift left with carry for multiply by 2 .

How about use a shift right? The output is then "Is Odd?"

That was my question... Why do they need to return different types. (though, it would be nice to be able to force the dynamic dispatch to a specific child. ( hmmm need to look at the Idea Exchange).. (on a side note why isn't the idea exchange www.ni.com/idea?))) So many possibilities.. which one to choose... i can't fault the current implementation, but I would like the ability to Auto Cast (ie. wire a specific child to a parent wire) so that I could place a child function on a BD and not break my code (I bet there are reasons for this, but it would be nice if say the call function output a failed cast.... ( hmmm like the to specific class) but then that would require functions to have an error out.... dang it.. decisions... hmmm maybe some sort of Exception implementation? It would be nice if we have the option to include the error cluster in VIs and if an Exception implementation occurred then it would be places on the error wire? Dang It.... I don't really want that, but it's a possibility especially, with "out of memory errors"...

Hmmm... on a side note; why can't I capture out of memory errors? (Idea link to come soon)

I'm afraid i don't quite understand what your trying to do. I haven't looked at the LabDog API, but I'm wondering why you can't use the Dynamic dispatch functionality of the LVOOP classes? it might help if you had made you examples use the same case.

If your updating UI elements (ie: controls) you could use Control refs inside the message class function instead of having to cast to a specific class.

Cool. Just got it working.

For all you iPad/iOS users out there. I discovered that the posting feature of the LAVA forum does not work with the Safari browser, but it does work with Opera mini. Don't know if there is anyhing that can be done about it, but thought I'ld put the info out there.

Going to have to try that when I get home from NIWeek.

Have you tried using the FP.IsFrontmost property of the popup?

As PYLB posted, you can but all array elements will have the same Item names for the listbox. To my knowledge all array elements must have the same properties outside of there value. I don't think it's possible to have listboxes with different items.

As far as "is it possible?" Yes, it is possible. Think your biggest hurdle will probably be an IT issue. First you will need a computer to act as a server that can be "seen" by the Internet, so security will be a concern. Additionally the suitcase system will need access to internet(which you said it had), but there might be security concerns on your customer side, especially if you are using their network and connection. Outside of access, visibility and security; the internet is no different to a program then any in-office network.

How much data are you talking about? A few bytes or a few megabytes every few minutes? If it's a few bytes then you might want to look at web services for the posting new data to the server. If it's more, then look at standard TCP/IP or NI-PSP for data transfer. Depending on the number of deployed systems you have, you might want to think about bandwidth requirements, how many simultaneous connections you want to handle, and how you will deploy the new system.

Another option would be to use the Picture plot functions. That would enable to you as many graphs as you want. It would a little more complex on the coding side and you do loose the zoom and pan functionality on the built in graphs.