jgcode

Good to hear

This patch (for 8.6.1) may help??? The Data Entry Properties Dialog Box for Numeric Controls Do Not Work Correctly in LabVIEW 8.6.1 http://digital.ni.com/public.nsf/allkb/765EBEBE6568CB098625756700718B66 Cheers JG [edit] Yep, I was right, it seems fix is to install 8.6.1 and patch. Hope you have a copy of 8.6.1?? [/edit]

Of course this is what I did when I said I could not see any difference. It all looks the same to me My eye maybe out tho??

What is the functional difference between the three controls now posted? They all look like they give the same effect to my eye. ???

Sweet, I remember seeing that one posted, I will check it out. I think that is the way I am going to go.

Howdy! Is it possible to have an X control that can spawn a dynamic User Interface VI - such that the UI is non-blocking in the X control thread? I have done X Control with static UI - easy. I just want to know if it's there is any problems that may arise or it anyone else does that before I go down that path. Right know I have my control in a main VI and I have a separate UI that runs in parallel to the main VI and that "acts" only on the control. The parallel UI is run by by main VI and comms/data go through the main VI to the control. I would like to encapsulate the control and parallel UI together. However, the UI and control must run at the same time - the parallel UI cannot block the control. Would this work ok? Cheers JG

Am logged in!! But still not working. I think there was a problem with my account activation?? Thanks heaps

Can someone please post the hack, the old LAVA links seem dead and I am having trouble (?) getting it from openG. Cheers

Very Cool

I am pretty sure you can't - as this is where the dreaded race conditions come into play. I have seen this a bit from older code, that programmed with this not in mind (e.g. lots of globals)... It worked fine on their PC at the time. Move on to different PCs - multi threading, hyper threading, Core 2 Duo - where the timing characteristics of the code are now different and whammo - race conditions start popping up. Same code, different PC.

Hi Jeffery I don't know if its a bug? But I ran into the exact same problem using the property node Data Value of a Class with either Get LV Class Path.vi or Get LV Class Default Value.vi and RCF - it ran fine in LV but not the application context of RCF. All I wanted to do was find the Class Control's Class Name So I typecasted the selected GOObject/Control reference to a Class, got the data value, wired that to the Get LV Class Path.vi, to parse the class name or something like that (I can't remember exactly). But there was a much easier way: All I had to do was get the Library Reference from the VI property node (RCF was acting on a Class Data Member VI). Then get the class name!! Depending on what you are trying to do there may be an another way i.e. if you just require a Library Ref to the class. What are you trying to do?

Ok, I played around with this for a while now and here is the low down: After searching around I have been unable to find the .spec file for the currently installed packaged in a temp directory. (Which temp directory is it? C:\Users\<me>\AppData\Local\Temp???) The other location I may have been able to use is the cache. But I thought about this I can't be 100% sure where the cache folder is: Is it C:\Program Files\JKI\VI Package Manager\cache or C:\Users\<me>\AppData\Local\VirtualStore\Program Files\JKI\VI Package Manager\cache?? (PC dependent) Therefore I decided to store all files I need to manipulate in the package to a known location. I choose C:\Users\<me>\AppData\Local\Temp\OGPB\... Now I know exactly where they are. The path is set in the spec, and I just have to create it in my scripts. Easy. I handle all the installation and uninstallation of files with scripts. Heck, I even wrote a small API that I can reuse for this stuff that creates a file with all the installed file paths so I can clean them up nicely at uninstall. I little bit more work for this edge case, but now I have my package for icons and I am very happy fo' shizzle Yep, it sure would be handy if the same info was available that is in the VIPM build hooks.

I can't edit my original post but there is now a [cross post to JKI]

I am using LV2009 and FP:State property toggles between Standard (in subpanel) and Closed (not in subpanel)- but not maximized ?? That is ok tho, cause now I have a way for the VI to test itself. Cheers

Hi Hooovah, thanks for the VIPM link. I use these VIs and have them as templates in my library. But yes, I am chasing information on Post Install Hooks. The reason is I am trying to install files in a path that must be resolved at the time of installation. If the path is resolved at the time of the build then the path is set to the computer that builds the package. And this is a problem. I want to package up the files but then get access to them and install them myself in the resolved location. Given that is what I am trying to do, is there a better way, or is Post Install Scripts the way to go? Alternatively I am thinking a Pre Install script may work, where I can edit the .OPGB file with the resolved path. But I was hoping for a lead into any data that is passed between the Installer (VIPM) and the Hook VIs. As they are included in OGPB I assume VIPM supports them. Maybe it is a good idea that I post there and ask! Cheers JG

Cheers, but its not that I want to load it, I just want to know when the VI tests itself - is it the "active VI" in the subpanel out of a possible number of VIs at a given time. So if it isn't I don't want any actions to be performed, so unfortunately this will not work for my task. Thanks tho. <edit> Ok had a thought and it worked The Front Panel:Open property is True when the VI is loaded in the subpanel False otherwise Easy! Problem sorted Cheers </edit>

Is there a way for a VI to tell if it is currently loaded in a subpanel? Maybe a property? Anyone know? Cheers JG

Thanks Ton Are you able to eloborate on this? Post Install Script info is what I am chasing. Have you done one before? Is there any way to access to the package file path (or is this done relative to the Script VI)?

Would anyone be kind enough to post any links to documentation etc.. about the OpenG Package Builder. I am particularily interested in Script VIs (or hooks) and if there is a template available and if there is/what information is passed to the template. Regards JG

Just out of interest to you program for NI on a Mac?

No, I believe the thread began with this: Sorry you haven't got your original questioned answered yet, but I believe the above was healthy discussion on issues regarding the build script, changes to the internal structure in 2009, and problems with transferring an 8.x to a 9.0 build. I tried to start another topic, but it was answered here so, I in turn, responded here. The mods can move it if they want. Just wanted to let you know there was no intentional high-jacking (well at least on my part ) Cheers JG

Great point! I stay away from their peripherals too due to this reason about their device drivers. I had a VIAO that served me well for 6+ years, but I think they are a little expensive for what you get. We had Lenovo's at my last work place and they were great (although again a little expensive compared to Dell). We currently use Dell at this job and they seem to run fine and are cheap. The boss and admin use Apple. One LAVA topic that comes to mind is that when people discussed this they said you should make sure you work PC has the same res as your home/remote PC (in this case both laptops). Makes coding life easier.

I thought you might have, as this method of generation lends itself very well to an OOP architecture. Having said that, I haven't had the chance to design any apps like this, but I have been lucky enough to do maintenance on ones that have. And I can see the benefits are really cool.

Yes sorry, we have been evaluating 2009 (and it looks like we are going to upgrade now) so I have been playing with stuff so that is why I did a drag and drop to the desktop and was happy that it solved the problem. As for the Source Tree comment yes, sometimes (if thats how I want to do it for that project) I want to keep my (latest) build under my dist folder which happens to be a defined folder structure under the Source Tree. I would prefer to avoid the build to C:\temp (or where ever) and copy and paste back under the Source Tree to check the build in, or for other reason mentioned. However, from all the discussion and even more playing around I have been doing, I have come to the same conclusion as you - so I think the solution above is the way to go. The reason for this is, even though I still think it adds to a problem, the benefits of having a cleanly built EXE in LV2009 do out way the above (for me anyway). By human nature, I would prefer not to have change the way we do stuff but I think I can overcome that inertia with a little time. Coz at the end of the day, having no external files in my exe - is just way too sexy (hey that rhymes) Thanks for your back and forth dialog on this Gmart. It helped me get my head around this new feature.

Really? For me - I have found LabVIEW 2009 to be more faster. Load time (without palettes) is so quick it blew my socks off. (I tend load the palettes tho, for Quick Drop etc... so I am happy to wait) Only thing I have noticed is Dialogs take a little time to open. But e.g. once the IE has been opened once, it is quick after. Class Templates Dialog seem a little slower, but I like the new features, plus you can do multiple methods - so it is cool for me. BTW - Does anyone know if there is a way to load the IE at start up? How are others finding the speed?