TG

Opps

LTR publishing is OOB

I never liked em anyway.

Sorry LOL

QUOTE(Michael_Aivaliotis @ Feb 21 2007, 09:03 PM)

Please submit to the http://forums.lavag.org/downloads.html' target="_blank">code repository.

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)

Why is it dirty? You want them to be public then make them public. If you don't want them to be public, why are you putting them on the FP of VIs outside of your library? If you want a datatype that keeps its insides private, that's what LabVIEW classes are for. But if you use a typedef, you darn well better have the rights to use *all* of that typedef because all of it is hanging out in the open.

File the bug report if you want, but it'll get closed "Not A Bug." :-)

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)

Consider the following, you have a library that has private controls. For use inside other VI's you construct a typedef .ctl that contains some off these controls and make the typedef .ctl public.

Now if you use this typedef inside another VI/Ctl the VI/CTL will be broken since it refers directly to the private members :thumbdown: . I was hoping that the public .ctl refered to the private members allowing a good use to these items....

Does anyone have an idea why? and how to bypass this.

The error:

This VI cannot access the referenced item because of library access scope. Private library items can only be accessed from inside the same library or libraries contained in that library. Protected library items can only be created inside LabVIEW classes and can only be accessed from inside the same LabVIEW class or LabVIEW classes inheriting from that class.

Ton

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.)

I wrote you an example that uses LVOOP class plugins to access different kinds of data files. Our real system is somewhat more complicated. The plugins in the attached example are opened at run time and correct plugin is automatically selected based on the file extension. I wrote two plugins, one for text and a second for binary data files. The text plugin uses queue based reference and the binary files uses native LabVIEW file reference. Of course the text file could use native LabVIEW file reference but I thought the example is more educative if I use queue based reference in the other plugin and you John also mentioned that you'd like to use queue based references. Open the File.prj project file and take a look at the two examples within.

Download File:post-4014-1169410820.zip

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

I wouldn't be so hard on yourself there John - you're certainly throwing around advanced terms like a pro!

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

Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....

thanks

Dan

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

amen to that!

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!

You don't prevent the coercion! You embrace it!

I've been meaning to post these for the last couple days, but I haven't gotten around to it. There's a write-up that goes with them, but it isnt' ready yet. But take a look.

This is the original solution that doesn't work in a runtime engine:

http://www.outriangle.org/jabberwocky/Fact...ingClassRef.zip

This is the modified solution that should work in a runtime engine:

http://www.outriangle.org/jabberwocky/Factory_UsingVIs.zip

In both cases, open the enclosed .lvproj file and then take a look at "DEMO Factory.vi". You can explore from there.

Hi Aristos Queue

Forgive

You don't prevent the coercion! You embrace it!

I've been meaning to post these for the last couple days, but I haven't gotten around to it. There's a write-up that goes with them, but it isnt' ready yet. But take a look.

This is the original solution that doesn't work in a runtime engine:

http://www.outriangle.org/jabberwocky/Fact...ingClassRef.zip

This is the modified solution that should work in a runtime engine:

http://www.outriangle.org/jabberwocky/Factory_UsingVIs.zip

In both cases, open the enclosed .lvproj file and then take a look at "DEMO Factory.vi". You can explore from there.

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!

I'm not sure about prices, but check out Endevo's UML Modeller (it's written purely in LabVIEW - Yes, that's right, LabVIEW! Written by LAVA member Mikael Holmstrom) There's a demonstration video here that's well worth watching.

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

I completely concur - just remeber that case structure selectors are case sensitive by default (you can turn that off with a right click selection), and make sure you have a separate "Default" case with a "Syntax Error" popup for speeling mistkaes you make when coding

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

I am new to this excellent forum.

I have never created a polymorphic VI yet (LV7.1)

How is this done? Is there a link on the NI website I could refer to?

Thanks

TG