Chris_S Posted November 10, 2010 Report Share Posted November 10, 2010 How do I programmatically get the path to a global VI? You cannot use get this VIs path because global VIs don’t have block diagrams. So how do I get the path to a global, from inside a top-level VI that uses that global? Just how there is a “Current VI’s path” function, I need a “That VI’s path” function Quote Link to comment
Grampa_of_Oliva_n_Eden Posted November 10, 2010 Report Share Posted November 10, 2010 How do I programmatically get the path to a global VI? You cannot use get this VIs path because global VIs don’t have block diagrams. So how do I get the path to a global, from inside a top-level VI that uses that global? Just how there is a “Current VI’s path” function, I need a “That VI’s path” function I don't use globals so I can only start with some guesses. A global is a callee of the VI so start with that list. I belive you can get a type for each VI ref so look for globals. For all global type vis, open the FP of each and get a ref to all control (traverse FP controls) and find one with the name you are after then get the path to the VI that holds it. Like I said, just guessing. Ben Quote Link to comment
Matt W Posted November 10, 2010 Report Share Posted November 10, 2010 How do I programmatically get the path to a global VI? You cannot use get this VIs path because global VIs don’t have block diagrams. So how do I get the path to a global, from inside a top-level VI that uses that global? Just how there is a “Current VI’s path” function, I need a “That VI’s path” function Make a static VI reference to the global vi then use the path property of the reference. Quote Link to comment
jcarmody Posted November 10, 2010 Report Share Posted November 10, 2010 Just how there is a “Current VI’s path” function, I need a “That VI’s path” function If it's in memory, you can do this: Quote Link to comment
Chris_S Posted November 11, 2010 Author Report Share Posted November 11, 2010 (edited) If it's in memory, you can do this: this didnt work. Error 1445 occurred at Open VI Reference in Safe_Start.vi Possible reason(s): LabVIEW: Open VI Reference will no longer match VIs in memory by file name. A VIs full name now includes any owning libraries so a filename is no longer sufficient. You can use strip path to wire the filename as a string, but this will not work for VIs in libraries. Edited November 11, 2010 by Chris_S Quote Link to comment
Chris_S Posted November 11, 2010 Author Report Share Posted November 11, 2010 Make a static VI reference to the global vi then use the path property of the reference. i cant make a ref to the global, because that would hard code the path in the static VI ref. The global may be in different locations on different systems. that is why i need to pull the path on the fly. I don't use globals so I can only start with some guesses. A global is a callee of the VI so start with that list. I belive you can get a type for each VI ref so look for globals. For all global type vis, open the FP of each and get a ref to all control (traverse FP controls) and find one with the name you are after then get the path to the VI that holds it. Like I said, just guessing. Ben this only works if the global is in that vi. the point is to use the global by reference. using it by ref, it will not show up on a callee list. The problem with pulling by reference, is that you need the path to pull it. So i need a way to get the path. Our main program houses the global in different locations for development software and released executable software. For all of our development testing, the global is in an llb. when the software is released for use the global will be compiled into an exe that resides in a completely different location. The exe runs a secondary piece of software, stored in a different location. This secondary software is where i need to call the global by reference. Since the secondary is not inside the exe. if i strip path i will only be left with the location of the secondary software, not the exe that contains the global. I cant run a list of callers from the secondary, trying to get the exe, because the exe calls everything by callback. Im sorry the whole situation is very convoluted. It’s always a pain trying to conform around old issues, as opposed to cost of rewriting old code to do things right. Quote Link to comment
jcarmody Posted November 11, 2010 Report Share Posted November 11, 2010 this didnt work. Error 1445 occurred at Open VI Reference in Safe_Start.vi Possible reason(s): LabVIEW: Open VI Reference will no longer match VIs in memory by file name. A VIs full name now includes any owning libraries so a filename is no longer sufficient. You can use strip path to wire the filename as a string, but this will not work for VIs in libraries. It worked for me. Did you wire the VI name with a String or Path datatype? I used String. Quote Link to comment
Grampa_of_Oliva_n_Eden Posted November 11, 2010 Report Share Posted November 11, 2010 i cant make a ref to the global, because that would hard code the path in the static VI ref. The global may be in different locations on different systems. that is why i need to pull the path on the fly. this only works if the global is in that vi. the point is to use the global by reference. using it by ref, it will not show up on a callee list. The problem with pulling by reference, is that you need the path to pull it. So i need a way to get the path. Our main program houses the global in different locations for development software and released executable software. For all of our development testing, the global is in an llb. when the software is released for use the global will be compiled into an exe that resides in a completely different location. The exe runs a secondary piece of software, stored in a different location. This secondary software is where i need to call the global by reference. Since the secondary is not inside the exe. if i strip path i will only be left with the location of the secondary software, not the exe that contains the global. I cant run a list of callers from the secondary, trying to get the exe, because the exe calls everything by callback. Im sorry the whole situation is very convoluted. It’s always a pain trying to conform around old issues, as opposed to cost of rewriting old code to do things right. And now for something completely different... I think you would be better off using Datasocket or the like, where all you have to do is change the URL for differnet environnets. Ben Quote Link to comment
Chris_S Posted November 11, 2010 Author Report Share Posted November 11, 2010 It worked for me. Did you wire the VI name with a String or Path datatype? I used String. when i tried this within a vi that used the global normally. Yes it worked. But when I ran it from a secondary program (with the first program running so the global should be in memory) I got that error. And now for something completely different... I think you would be better off using Datasocket or the like, where all you have to do is change the URL for differnet environnets. Ben I really haven’t used datasockets so I do not know. But wouldn’t using different URLs be equivalent to just using paths directly? Like saying I can hard code the path to one location or the other. Or have a url to one or the other. Either way there is hard coded information. Quote Link to comment
Chris_S Posted November 11, 2010 Author Report Share Posted November 11, 2010 (edited) My main goal here is: I have a global I can use normally. That I can guarantee will always exist (its location may change development or exe). I also have a new global that may or may not exist. If it does exist, it will be stored in the same location as the first. If it does not exist I can handle any errors, my code will not be broken, and will still run without problems. So for example if I have on my diagram a string global (from global_1.vi) used normally. Can I get the path to global_1.vi so I can use that path to call Global_2.vi by reference? See Ex1.jpg attachment Edited November 11, 2010 by Chris_S Quote Link to comment
Ton Plomp Posted November 11, 2010 Report Share Posted November 11, 2010 when i tried this within a vi that used the global normally. Yes it worked. But when I ran it from a secondary program (with the first program running so the global should be in memory) I got that error. That is normal, VIs are enclosed in there own application space. If you want to open a (global) VI in a different application/project, you need to open a reference to that application first. Ton Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.