TG

QUOTE(evergood @ Feb 26 2007, 09:11 AM) Here is a tip Put that puppy in a shift register (while loop) and use the match string function with the period '.' delimeter to parse out the values then auto index em out as an array. Attach the comparison operator <0 to the index output of the match string function to tell the loop to stop parsing. This is the essense of parsing strings. Unfortunately I don't have an example.

Opps LTR publishing is OOB I never liked em anyway. Sorry LOL

QUOTE(Michael_Aivaliotis @ Feb 21 2007, 09:03 PM) jlokanis \ Could you post that again I think the LLB is corrupted somehow. I could not launch or load it. Thanks

QUOTE(Aristos Queue @ Feb 16 2007, 10:22 AM) Thanks Aristos Your answer is what I was looking for even if I did not realize it right away. It not good practice to use a control outside its protection scope anyway. I just hate realizing that my original design won't hold up as the APP complexity grows. I need that type definition outside the class so, I'll just make it public and get on with it. JR

QUOTE(tcplomp @ Feb 15 2007, 03:20 AM) I hope you get a good answer to this one Ton. I have encountered this too. The encapsulation paradgim in LabVIEW whereby all private data is accessible only by members of the class is a good idea, but how does one deal with public type definitions which may (by design) include some of these types in them as the structures develop in complexity? It can get rather complicated. I have actually changed the scope of some of my private elements to public to get around it (rather dirty I agree) Im sure there is a better way, but being in a little over my head I have not the time to find the correct solution (if there even is one.)

Boy that is a nice example Jimi. Elegant and educational. Actually I do not think it is that far off from what I need to do. I have many questions about this example because I am still playing (eternal) catchup but I'll keep it short. In the (specilaized for binary file version) Dymanic Vi "Open file.VI" I notice the embeded file reference to the open file. Now if this "by value" class object were to branch I assume refnum would be copied along with it but would still be valid (provided the file were not closed by some buggy code running somewhere else), thus any copy of the class could be used to get at the data in the open file as long as refnum was valid (I understand this may be risky but what is the alternative I have no idea). SO the Q is the following: How could I do the same thing except instead of an external data file, what about creating a reference to the class itself and inserting this reference into the original class object? In other words how to simulate "by ref" behaviour for any given "by value" class. I can see (in my mind) that this is probably common technique for simulating by ref access to the class object, however inheritance looks murky to me with respect to simulating byref behaviour. I saw your examples in Refactoring the ReferenceObject example in LV 8.2 Im wondering if the example you showed is the way to handle inheritance with "by ref" behaviour?

Goal: Create A ref to a 'dynamically' constructed class instance plus support for inheritance My project involves automating a process that uses many serial instruments, actuators, sensors etc. My boss wants me to "do it with objects this time" because we expect to be maintaining this for years to come and also we will use parts of it for future projects etc. Because some of the classes will support serial instrument and Field point calls I (think?) I'll need to refer some of them by (simulated) reference. I might need to refer to all of them this way. Various control loops will be used. Speed is not really an issue to be concerned about, except in reading serial data in real time from say, one or two instruments. Inheritance is being used (I prefer to stay in LV8.2 and not use outside party toolkit for serial device classes.) Enough of the lead in . Here is the question'(s). Aristos Queue provided the coolest example of (a factory pattern?) A solution to a problem posed By Lee Robertson that can work in a built app. It uses coercion to do some cool stuff with classes. It works by simulating instantiating an object dynamically using VI server. By loading a VI "default data" with the desired class inside it and a generic class as the output terminal. I am amazed at how simple this is. I took the liberty of reposting the example code. http://forums.lavag.org/Need-help-with-inh...tion-t4033.html http://jabberwocky.outriangle.org/ Factory_UsingVIs.zip Here is the essence of the thing. The inside of the call by ref node contains (essentially) the code below except for a mod I added in pseudo code. To make a long story short I want to embed a reference queue to the object in the actual object. Q is he following: Would it be possible to "pseudo constructor' the object before it is passed out to the generic terminal and could we give it a reference to itself as shown in the pseudo code below? If I go down this road what kind of trouble should I expect? If so why would it not work, and what would be required? IF it DID work how could it also support inheritance? There

Howbeit your comment is most greatly appreciated most gracious crelf 'San'. You are only too kind. Been studying all of the examples provided by all of you guys here. It's amazing (at least to me) how much utterly high quality stuff is in here! (I know I know I already love LAVA

Dan, I too am (roughly) in the same boat as you, so my help may not be optimal but since I understand how you feel I will include it anyway, even though it may not seem very elegant. Im just an engineer not a software programmer, using LabVIEW since version 1.0 but never had time to get too serious with it. I would throw together some code for a prototype instrument developed "in house" and when it gave the result we wanted I was done with it. No formal studying no pHD in computer science. Typical old dog newcomer. Never learned to go further with it. Personally My biggest challenge was to understand the mechanics of how LabVIEW implements inheritance. I agree good books must be studied to understand OO concepts but then... after this is done how to implement these in LabVIEW 8.2? It is one thing to understand the concepts of abstraction, specialization and encapsulation but quite another to "see the mechanics" of how these concepts are implemented in LabVIEW 8.2. I would critique NI for not supplying more meaningful example code to look over and study. Sometimes an idiot like myself needs to see 3 or 4 examples from varying perspectives (and comments everywhere ) to begin "getting it". Dont forget LV was developed primarily for guys like me who for one reason or another are not computer science professionals. I've been studying the mechanics of how LabVIEW implements inheritance for quite some time now. BTW the LAVA forum posts are quite advanced and are filled with tremendously useful information! These guys are the "Top Guns" in the industry and I am quite greatful they are willing to "show off" their talents. I do not believe there is a better place to study LabVIEW OOP in all its flavors then right here at this FORUM. it is not however, for the weary of heart. It is taking me some time, studying and reasoning, to begin understanding how all of this is supposed to work IN LabVIEW 8.2 but I am beginning to "get it", thanks to LAVA. I agree the supplied help, (while adequate once an understanding is already achieved) does little to show some of the finer points that are absolutely pivotal to understanding the "mechanics" of how LabVIEW implements inheritance. For example, The concept of "dynamic dispatching" and the "over ride" node is not mentioned as much as I think it should in the help documentation for newcomers and old dogs. Also, I see no way to determine if a VI has dynamic dispatching terminals except to open it and look at the terminals. A clue would be to see that many VI's have the exact same name, etc etc but the point to make here is the following: Sometimes you need to just see ALL the code executing in one place before your eyes. In the beginning I found the following technique helpful to me. Your milage may vary. Open the supplied Automobile exapple in the help documentation. Open all the VIs front panels and block diagrams. Change all the FP Icons to show the terminals then reduce the FP as much as possible so it takes only a small portion of the block diagram underneath. Try to get every block diagram reduced enough so that ALL of them are visible in the desktop. Save each as you change it. (You most likely will want to return to this several times until you "get it".) When all are positioned pretty much as in the supplied picture save it all then put all of them in execution highlighting then run the main VI and watch how the data moves. With this aproach I was able at least to begin "seeing the mechanics" of how LabVIEW implements inheritance and encapsulation. Because I am an old dog it was necessary for me to "see" ALL the code in one place executing again and again. I agree a reasonably simplified example would do a lot but several showing the same behavior from different perspectives would be far better. This is one thing that NI seldom does. The shapes example (especially the presentation) is very good. Download File:post-2402-1169313605.zip

Hehe You know I am not even remotely yet a contributor to this forum, but I've been studying you guys and Goop for more than a few days (most of it right here in this Forum.) All I can say is Please keep up the chatter! The more you guys talk the more I begin to understand how all this works. Thanks!

Hi Aristos Queue Forgive Aristos, Forgive me for barging in on this old thread. I've been trying to read along with this old conversation for study purposes. The examples you specified above, could they be found anywhere as I'd like to look them over. (I am having trouble getting access to them here) Thanks in advance, John PS: Thanks for sharing, You guys are amazing! Well I just figured it out Duh! No need to help thanks!

Thanks a bunch Jim, I'll be reading. BTW your "LabView for Everybody" book is the best. I already have it quite scarred with coffee stains and scuff marks. Most of the NI material is very good too but I havn't seen it all combined together as well as this book is. Only complaint is it' a (huge!) hard cover animal.

Forgive me if this is obvious, but I have struggled with the help file in 8.2 and could not find a way to add code snippets into my pallet. Actually the whole concept of how palletes are set up is a bit mysterious to me. I did it once in 7.1 but can't remember how, thus my brain has gone to sleep on this one. Is there anything good to read on this for 7.1 and 8.2 before I start corrupting my LV installation Thanks in advance!

crelf For simple projects this software might be just what I need. I heard a rumer that you work for VIE Can you put me in touch with pple who could give me some more info on this UML modeler and also does it include the GOOP toolkit? If so Much appreciated John PS still waiting for my PAYPAL EUN from my CC statement

WHat UML tools are used by you LV fanatics here I been looking around for something free that would be enough for my needs ( which isn't really too much.) but most of the web pages are cluttered with all kinds of ads etc.. Question is what is a good gen purpose tool for a newbie to UML Say less than 100 bucks? I'll take free too if its available. Thanks guys

Hey thanks Mike and Crlef Always good advice and information here!

That Goop eval copy. Is that an Eval copy of the expensive one from Endevco? IF its shareware Id like to get it too Thanks Duh! I just woke up a little. I can see its a new release Thanks!

Well, it is not really a struggle. Id just like to see if the State machine I am curerently using is good enough for general purpose work or is there a better flavor out there. Ive always had a bit of a snag when it comes to how to handle errors in a state machine. I wonder if this architecture is the best. PS: Forgive me if I posted this in the wrong forum.

You can change the color of a block diagram, sequence structure, case structure etc Select the color you want the front panel first then Press CTRL E to bring up the block diagram The tool is available for a color change at least once on any structure you wish.

This topic is intriguing to me. What could this LV2 semaphore be used for Whats the hook? Is it the global access to a consisiently valid semaphore?

Greetings Lava pple I am also very new here and hello to all. Been using LabVIEW since it first came out on the Macintosh. Nevertheless, my level is ~intermediate mostly because I usually just write little apps for local purposes then move on to other work that needs to be done and also because I am addmittedly lazy.. Maybe someday I could do this for a (real) living but for now I have to use LV cause its for beginners and it saves me time on doing simple stuff. Still I appreciate this FORUM even though the exosure it only 3 or 4 days now. Yall got some pretty sharp guys here. :thumbup: Thanks for letting out some of the secrets TG PS: Oh BTW since I am so new I wanted to change my call sign and maybe find a pic. I think I can figure out the second but the name is always gonna be my full name? Since its early can I re-enter myself?.

My initial experience with LV8 was very bad. It was not seamless. I tried to install it on a machine that is not normally connected to the internet and runs a robot. That caused all kinds of problems. NI said it could be done over the phone but the activation code they gave did not work and I had different opinions from NI as to why. Then I connected the internet and tried to install again and made real mess of things. Of course some of it may havce been me but who knows. I had to uninstall it and re-install about 4 NI packages then pray to get the original app working again. The Rs232 mapping was totally screwed and I could not justify taking several days to look for solution. After losing so much time and productivity talking to NI and whatever and finally said "sorry this one is not gonna fly on this app." Call me when its fixed." NI tried to help but I do not think they could duplicate my setup closely enough to give it a real try. Im sure its better now and its too bad really, some of the new stuff would be really helpful but it is definately not for the faint of heart. Ill try again soon but must be better prepared for such major changes in the environment. TG

didierj Thanks for taking a look at this! I think that error was my own silly fault but if it isn't you may have solved very tough problem for me as in how to compile app that can launch many instances of VI's that run independently. I actually didn't test the example first (Sorry , I assumed it would fail since it is very similar to the other one I am struggling with) . Now to find what is wrong with my code. I guess I should go introduce myself at the front first since Im about 3 days new. (Kind of liking this place more and more.) Very grateful for your response didierg

Hello great ones. I am new to Lava and I am absoultely on a time crunch for this option. (Intermediate level expertise in LV) The Q is how to compile this example without getting to get "Property Node (arg1)" errors in the executable? LV7.1 :headbang: I know it has something to do with closing the reference but am unable to get a clear understanding of what to do about it, since it works perfectly in the LV environment. Anyway, any tips would be appreciated so far my own feeble attempts to get this info have not been very succesful. I know there are good tutorials on this somewhere out there... Thanks in advance! TG

Thanks, I didn't think of that one. Who knew