Kurt Friday

Cool, I'd love to see some OOP frameworks, would be great to have a bit of a community effort on this. Good points, would be useful to see at a glance that your object is by ref, but I suppose we are using by value objects in a by ref capability. Perhaps a convention could be started by choosing a specific wire color, I'd suggest a green color which is consistent with other by ref implementations such as File IO, VI Server, control refs. Yes, unbundleing all the time is an overhead and takes up a bit of real estate. At the moment I'm also placing a few more items in the object data other than just the datamember DVR to achieve active objects so its usefull to unbundle and get what I need. It would be nice to just plug the object into the IPE but then how does it know what to unpick since the object can hold many things, multiple DVR's possibly Ahh, yes, that would get you. At the moment I'm carefull about placing methods inside an IPE unless I have to. If I dont I just use them outside. I agree with you that there needs to be some checking that looks at the method you place and does a check to see if there is any possibility of cycling back to a read on the same DVR A probe on the DVR to show the data would be handy, I suppose the probe would have to implement an IPE behind the scenes and then I can see a situation where you probe your object within and existing IPE and then you get a lockup. I suppose you could make your own custom probe that is a member of your class, a bit like the old object explorer. I'm really happy that everyone is on the same page with respect to implementing by ref objects. Looks like we have a great kickoff point with a workable framework that is easy to implement and doesn't require a heap of support vi's. In the past I've always used my own OOP implementation to give me what I want because LVOOP just wasn't there yet, but now it is and I'm very happy and I have to say a big thank you to NI for working on this

I've been having another play with the concept of datamember DVR inside object ref and it’s appearing to be solid. The only thing you need to watch is that you don't perform a method call inside an In Place Structure DVR R/W that acts on the same data. So placing a method of the same class or a parent method with dynamic dispatch will cause it to lock. Placing a parent only method inside a child method's InPlace Structure DVR R/W is OK since it only acts on the parent data which has its own DVR. But in the end it’s the same kind of rules you would use as before when you had lock and unlock primitives in previous architectures. I haven’t been able to create a race condition as a result of implementing parent and child data member DVR’s. Since parent data is accessed in a child by parent methods the data is protected, the data locking protection mechanism exists at all levels of the object hierarchy.

Hi Everyone. As I mentioned earlier I was thinking about releasing the GOOP Developer source code under the BSD open source license. Well for those who are interested you can download it here. It's written in LabVIEW 7.1 and there were a few challenges I had to overcome to make an application have a file explorer look and feel such as contextual popup menus, splitter bars, treeviews and listviews that worked the way I wanted them to. Its all object oriented, built on an early implementation of the OOP framework. There are lots of scripting goodies in there and lots of useful components or frameworks you could pull out of it. So enjoy, if there is something that isn't clear or commented enough let me know.

No problem, try downloading it again its now in 8.5

I've been playing around with this and have something that works. Check out this post.

I found some time to play with this again and came up with something that works. Office.Word.InsertDoc.vi This should get you going.

Hi Joshua From a quick look at your vi I would guess that the memory management required to build those 8 large arrays starts to interfere with performance causing it to lag behind the RIO application. I would also suggest that redraw of those 8 plots will take longer the more data you are throwing at it. Try breaking it up using a queue driven state machine. One process just manages reading the TCP packets and poping them into a queue. Another process waits on that queue and builds your display buffer. Also consider pre-allocating your display arrays this will reduce the memory management overhead. You probably dont need to update your plots when each packet arrives, perhaps once every 250 msec or sec is sufficient. Hope this helps

I don't know either what Add Object in a concatenated way means or how it would be implemented. I had a bit of a play and found a few things which should push you in the right direction. I don't think Add Object is going to be the way to go with this, I found that if you perform Insert -> Object from Word then you get the same result, just a single page. However if you do Insert -> File then you get what you want. So this then suggests the method that you need to implement. If you look inside Word Insert Object.vi then you see Method "AddOLEObject" A path to investigate would be from the Document Ref get the Content Ref. On the Content Ref perform method "InsertFile" I had a quick play with some partial success, but more tinker time was needed.

Take a look at this post.

Perhaps a new toolkit LabPHEW

Hi Mate I don't think its exposed. Check this post

Mmmmmm Toast!!!

I think what is happening is that by deleting the error wire you break the dataflow. So the order of operations may be Load XML String, Get All Matched Nodes, Close then run invoke node Get XML on the Node Result Array which will now be invalid because you closed the main ref. Why it's crashing LabVIEW I don't know.

Take a look at LabVIEW\vi.lib\platform\browser.llb\Open a Document on Disk.vi This should help you.

Ahhh, cool. I'm a little more wiser now.

I'm just revisiting the bad old days of vits and playing with Rolf's suggestion that you can place a vit on the BD in a similar way as the reentrantly called vi is done in my posted example SpawnFP_2. I can get it to work in dev environment but not as a built exe. Here is a shot of my code. The trick to get it to work in the dev environment was casting the spawned vit name to a path, this must request LV to open the vit and rename it as a new instance. If you just wire the vit name into the Open VI as a string it complains that "Cannot instantiate template VI because it is already in memory" So OK that makes sense. But When I build it and run it it just complains that "Cannot instantiate template VI because it is already in memory" I'm just playing with it for intrest sake to see if there was something I missed when I was playing with vit's back in the late Jurassic with the Popup Menu.

Hi Rolf Some nice tips. I was trying to do something like this when I was developing the popup menu toolkit. It was built in LV 7.0 and I had to use vit's because each recursively spawned submenu needed its own unique FP. I remember experimenting by placing the vit in the BD as you mention but there was an issue that I'll have to take another look at, I'd say it's been resolved in later versions of LV. So as part of the user documentation I tell the developer that they need to include PopupMenu.MenuSelector.vit into their build.

I can't think of any reason why. Perhaps it breaks some new feature of LV2009.

Well done guy's

Brilliant!! Yeah, it's a handy technique.

Are you getting the error when you run the executable or the source code? Is anyone else who downloaded the demo experiencing the same issue? What version of LabVIEW are you using? Try the suggestions in this link.

Can you provide more detail, is there an error message? I included source code and a build, did either of those work?

I just knocked up a demo that shows how to implement an agent to read the palette from an exe. Agent.PaletteDemo.zip Hope this helps

Weird, I just tried it, it should work but doesnt. Time to try an agent.

I think what you need to do is open an application reference and pass it to your Read/Write Palette functions. Use machine name "localhost" also check that your VI Server Configuration is correct by going to Tools -> Options. Enable TCP/IP and machine access to 127.0.0.1