Dave Graybeal

Due to lava's nature I would almost guess a higher FF userbase than IE, however due to the fact that IE is everywhere and that FF will only be available for someone who actively searches it out and installs it, my guess would be something closer to: IE users: 85% FF users: 15% I'm curious to see what the number really is however! Dave

Thanks for the Response Michael, I didn't see anything in that thread that seemed to match this exact problem though so I thought It might be best if I explained what Todd was trying to describe a bit better. Problem description: We are trying to load a vi that exists in an Exe into a subpanel of a VI that does not exist with that same Exe. Problem Demo: Attached is a zip file that contains 4 projects (Child App, Child App V80, Parent App, Parent App V80). Under each of these folders are the vi's used in each project as well as the built executables for each project. If you run the Parent App V80 build under LabVIEW Version 8.0, you should see a VI pop up that displays the Child App V80 vi in a subpanel (just a VI that says This is My Exe). If you then run the Parent App Build under LabVIEW Version 8.2, you'll see that the same example produces an error instead of embedding the VI. If you look at the code it is the same method used in both version. PS. Make sure to unzip the Zip File into the folder "C:\Exe Access Issue" , this is so you don't have to change the Vi paths and re-build the exe's to test it. Hopefully someone will know another method of doing this same thing. If anything sounds unclear let me know and I'll try to describe it better. Thanks In Advance, Dave Graybeal Download File:post-4149-1155660605.zip

This is one of the ways that I was thinking that could be used to give the by reference feel. Another that I think would work is if you use the endevo GOOP as a wrapper for the LVGOOP. Although it may seem a little redundent, I think it would give you a lot of flexibility for when by reference becomes implemented in the LV package. I believe you could probably ( not tested and only mildly thought about ) use the endevo GOOP package like normal, using the LV Object as your Data Member. Then in each of the methods you call the LV Native Methods for your object and pass in the Object Data Member. One thing that crosses my mind if this would work or not would be how LV actually protects its private and protected methods, so I'm not sure if that would cause any problems trying to implement. I hope this helps! Dave Graybeal

I just wanted to second the motion of Recieving Lava via the RSS Feeds. I think that it makes for a great reminder to stay up to date on whats going on, and it makes my thunderbird inbox a fun part of my day. Take a couple 5 minute breaks throughout the day to glance over the boards and pick out a couple key pieces of information that you use or contribute I'm sure you'll enjoy your experiences here on the Lava forums. A Big WELCOME!!! Dave Graybeal

Don't forget about us Lava users that are capable of multi-tasking and getting a chance to browse the forums while attending the NIWeek Seminars!!! I just also need to add that Dean Kamean(sp?) was an amazing speaker today, definently the most motivational, insperational and fun keynote this year! It would be nice if they recorded ( or if someone else even had a self made video) that could be put into a web stream to give everyone a feel for the amazing experience that is NIWeek. Dave Graybeal

Alright, well I almost feel a little guilty about being so quick with my first post. After giving the overall concept more thought and discussion ( had a great chance to talk to many of the LAVA Guru's at the Salt Lick about this implementation), I don't feel nearly as cheated in this new implementation. I see the reason that this version of GOOP was a great feature which was lacking which is the passing by value (dataflow). After some dialogue with a few folks, it really doesn't sound tremendously difficult to create some wrapper vi sets to use your objects with to create the by reference feel of other current GOOP toolkits. I do hope that "passing by reference" is something that gets implemented natively in the next version or two, however I do see the advantages of having a truly by value object and the couple quick ways to use them in a non-natively "by reference" way. Although I'm still not able to move all my objects over from my endevo build to a labVIEW native object, I'm glad they implemented what they did. It truly is a great step in the right direction. Dave Graybeal

So far I feel a little bit dissapointed with the new integrated version of GOOP. It's Lack of "Passing By Reference" takes away a lot of the area's where we tend to use objects. There is no real creation of an object and destroying of it. They really appear to be nothing more than a glorified Cluster that enforces some degree of good programming techniques. I'm not saying its all bad, I think its surely a move in the right direction. When I first heard about the OOP being integrated I thought that one of my first projects would be converting all my endevo objects over to LabVIEW objects, however after seeing the need for direct dataflow with no parallism (sp?) I see that this project is something thats going to have to wait until the next version of LabVIEWs GOOP that has "Passing by Reference". Overall... Fairly dissapointed, but It's still good as far as showing progress in the right direction. Time to get back to the next session!!! Dave Graybeal

Michael, just Yesterday I updated another computer from 8.0 to 8.0.1 and ran into this same issue with the 'd' graphic. I remembered seeing this post a while back and was finally able to find it, but was bummed to see that there was no solution for it. Is this issue something that you were able to fix? I'm not sure exactly what caused the problem, but I tried running the JKI mass compile tool and it crashed on me about half way thru, so i tried running the labview version which crashed as well ( this one actually showed me the vi it had trouble with, but i didnt get it written down and have not seen the error since). I ended up having to check out all my code from my SC software to get the JKI compiler to finally go thru. Not sure what part of this process caused the 'd' graphic, but it's a bit odd to look at! Thanks, Dave Graybeal

Another option is in LabVIEW 8.0, The SubPanel Control has an option that you can turn on to allow opening of the Block diagram. This allows you to open the block diagram of an embedded VI while the application is running in the subpanel by right clicking on the subpanel and choosing open block diagram. I use this feature a lot for debugging and it works great. Below is a screenshot of what to look for! This is Where to Turn It On: This is Where To Open it during Run Time: Good Luck, Dave Graybeal

Perfect My Drive Mapper now show's no indication that it ran. Hiding the Task Bar was a great idea. I have now evaded 1000 questions about why my users computer screen blinks or pops up new software. Thanks to Everyone for the Help!!! The Following is a screenshot of the simple program used to map my drives for my users. I build this VI into an executable and place a shortcut to the executable in the Windows Startup folder so my users have all the drives mapped. I also added in the HideRootWindow = True into the ini File so there is no indication that this drive map program is running. Dave Graybeal

Well, apparently I jumped the gun a little bit. Yesterday after placing in the closeFP property node I noticed that the lack of front panel appeared exactly as I was hoping ( no blinking screen before it disappeared). However, I failed to look at the results of the code which ended up not executing. It apparently is the case that EITHER the CloseFP method or the FP.Open Property used to hide the front panel will causes labview to immediatly stop execution. So I'm pretty much back to where I started now, looking for a way to run my executable in a state that hides my front panel without using the CloseFP method or FP.Open Property. I believe I've seen Apps written in LabVIEW that have been able to launch in he system Tray of the Computer without having any active visible Front Panels. If anyone has any further insite on this I would appreciate it. Thanks again, Dave Graybeal Alright, after playing with a few more things I managed to find a property node that appears to work for hiding the Front Panel of the VI in an executable. First thing I do is Set the Run VI Transparently to True, then I set the Transparency Level to 100% which makes the VI invisible. Now when I launch the VI all I see is a Windows Task Bar for the VI come up, No Front Panel Flash or anything. Thanks to all for the help! Dave Graybeal

Thank you very much, this worked exactly how I was hoping it could. I am a little curious why the method takes precident before the front panel is actually loaded vs the property node fp.open causing it to open for a brief second. Thanks for the help, Dave Graybeal

Good Afternoon (Morning for the west coasters), I'm having a bit of difficulty getting an executable of mine built in labview to behave the way I would like it to. Basically I have a simple VI which uses the command prompt to map a few drives on our network. I built this VI into an executable with hopes of tossing it into the startup folder of our machines here at work to auto-map all the drives that we need (using exe over a .bat to help keep login and passwords to remote drives more secure). The application works, however I'd like it to be of no interference to my users, as though nothing new has happened/changed so that I don't get 1000 questions asking me what the new window that pops up is for. I haven't had much luck getting the UI/Front Panel to show up however. I know that I can set FP.Open to false and it will go away, however it still flashes momentarily on the screen. If anyone has any idea's or suggestions I would appreciate it. Thanks, Dave Graybeal

wow, I'm actually a bit surprised that I never came across this issue earlier. Thank you for the link, it was very interesting material to read. I guess i'll have to get away from these types of habits. Thanks again, Dave

Alright, the issue I'm seeing is that the Fract/Exp String To Number VI is incorrectly translating some strings to numbers. For instance the number 1.3 is being converted to the number 1.30000000000000004. Yes, it is placing a 4 at the 17th place past the decimal. This happens with a few numbers that I've noticed (different numbers being tacked on the end). Attached is a VI that demonstrates this error. If anyone can think of anyway to get around this please let me know. In the mean time I'll be on the phone with NI to see what the issue is and how to work around it till it is resolved. Also, while I was getting the VI ready to attach to this post I noticed that even just basic math on numbers can create this same issue. 130 / 100 is comming out with the same results. Thanks, Dave Graybeal Download File:post-4149-1146232154.vi

A neat idea (and maybe its already the case?) is if the <customize this text> descriptor was actually able to be customized by those that manage to obtain 500 post status. Maybe Jim's got something fun and creative he'd like to put there! A sorta reward for him being so active (and beneficial) on these forums. Congratz Jim, Dave

Unfortunately both the pc's that I typically work on are part of a larger corporate scheme. Even with a re-install of our corporate version of windows xp (and all the other software and such they toss in with it) I'm afraid I won't see much improvement. Both my pc's are a fairly new Windows XP install (around 2 or 3 months) so I think I'm pretty well stuck with the performance that I'm seeing ( which isn't really all that bad minus the annoyance of having to click ok on a warning box when i forget to open labview first). Three Cheers for Corporate Control!!!

Thanks to all for your responses. I'm glad that I'm not the only one that has seen this message before. I see i was pretty close to the guessing what the issue was, thanks for the further explanation about the DDE and when the timeout occurs! I've seen this message on nearly all the PC's that we run around this department, so I'm a little curious as to what type of machine those of you are running that don't encounter this error. The system I booted up this morning (which is where the message came from) is a PXI-8187 embedded controller running at 2.5 GHz with 1GB of Ram. I also see the error on my Desktop computer which is running at 2.8 GHz wit 512 MB of Ram (time for a ram upgrade... LabVIEW8 isnt very appreciative of 512 MB). Lets hear what some basic spec's are on the pc's your able to run that don't encounter this error! Thanks again, Dave Graybeal

So here I am waiting for LabVIEW to load and figured I'd take the time to toss up a post about something that I see on a daily basis. Attached is a picture of an extremely common LabVIEW error that tends to pop just about everytime i attempt to load LabVIEW by opening a VI directly. This error is repeatable in the sense that it happens about 9 times out of 10 when i try it. I'm sure that others have seen this error before (or at least I'm hoping), and I was wondering if anyone knows why it happens and/or how to keep it from happening. My best guess so far is that it has something to do with the length of time it takes LabVIEW to load. Maybe something along the lines of windows issue'ing a timeout warning while trying to open your file because the application attempting to load it is taking too long? I guess I should also note that the file does load, and that you just click the OK button on the error box to make it go away. This error comes up as a result of opening a VI, when LabVIEW is not loaded into memory yet. I'm curious to hear if others have encountered this, and what they have done about it (if anything). Thanks, Dave

There are many things that can contribute to memory issues. The following is a list of common mistakes I have made in the past that can add to the bulkyness of code: 1) Look for the use of the Build Array function within a loop. If I remember Correctly this causes an additional copy of the array to be created each execution of the loop. This can be solved by initializing the array outside of the loop and using the insert into array function within it. The concatenate string functions works in a similar way to the build array as well. 2) Watch out for the use of Local and Global Variables. Local Variables cause a front panel to remain in memory even after the VI's execution has ended ( so sub vi's that use these in the background will stay in memory). Global Variables will create an additional copy of the data each time that the Global Variable appears in the code. 3) Clusters that contain clusters can also be an issue, because as you unbundle the data it will create additional copies in memory instead of referencing the original data. Hopefully some of this information is as helpful to you as it was for me. Good Luck, Dave Graybeal

Thank you Very much Kennon, This looks exactly like what I was missing. I'm going to give this a go and make sure it solves the issue I was having. I didn't think to look for an instruction set on NI's website as I have built many applications in the past and wasn't counting on the need to take extra steps when using other NI provided VI's. It would have been nice if the LabVIEW application builder would have recognized the use of these VI's and auto inserted the necessary lines in the INI automatically. Maybe thats something to toss up to The Wish List thread! Thanks again, Dave Graybeal

I've completed work on a VI that uses the SCC VI's included in LabVIEW to get the latest version of my groups Reuse Library. The VI works great and will be used at the startup of LabVIEW to hopefully keep all our Machines up to date with the latest versions of our reuse code. ( Another Thread in relation to this project is Launching Application at LabVIEW Startup ). Alright, now for the issues that I've encountered. First, when I build an executable from the VI that uses the SCC VI's included in LabVIEW it does not work as it did when running the VI from within LabVIEW. The issue that It appears to be having is that it cannot find the Source Code Control Configuration settings, and therefore cannot connect to our VSS. This makes sense to me considering the fact that the SCC Configuration Settings are something that is Setup within LabVIEW. But, this leads me to question how we are supposed to get these VI's to function from within our own applications that run from executables. Are these VI's not meant to be used within a Distributed Application? Or, is there a Workaround that I'm missing to accomplish this? I look forward to hearing your opinions and/or knowledge on this matter. Thanks In Advance, Dave Graybeal