John Lokanis Posted July 29, 2009 Report Share Posted July 29, 2009 Have you ever been editing a bunch of VIs in your project and then decided to run the main VI to see if the edits worked, but you left a modal dialog VI front panel open somewhere? The result is it becomes frontmost, but is not actually running so you are stuck because you cannot get to your main VI UI and you cannot interact with the modal VI either. I do this all the time and it just ticks me off. So, I threw together this simple VI to avoid all that. I drop it down on the block diagram of my main VI so it runs first. If this happens to you, give this a try and let me know what your think. -John Stop on Modal VI Open.vi 2 Quote Link to comment
MikaelH Posted July 29, 2009 Report Share Posted July 29, 2009 If this happens to you, give this a try and let me know what your think. That's a good feature. It would be good though to be able to define a Project Specific VI(s) that always is ran before you start your main VI in a Project. Of cause I like to see the option of defining a Main VI in a project so then you press Ctrl-R from the Project Tree, it should automatically start your Projects Main VI. //Mikael Quote Link to comment
Antoine Chalons Posted July 29, 2009 Report Share Posted July 29, 2009 To avoid this problem I never set my VIs modal in the VI properties, VIs to appear modal set themselves "modal" when they are called and set themselves back to "normal" after execution. But I like your VI, it's a nice way to solve this issue . 2 Quote Link to comment
John Lokanis Posted July 29, 2009 Author Report Share Posted July 29, 2009 To avoid this problem I never set my VIs modal in the VI properties, VIs to appear modal set themselves "modal" when they are called and set themselves back to "normal" after execution. I never thought of that! Good idea. I will try that in the future. Quote Link to comment
Popular Post Aristos Queue Posted July 30, 2009 Popular Post Report Share Posted July 30, 2009 It would be good though to be able to define a Project Specific VI(s) that always is ran before you start your main VI in a Project. I begged. I pleaded. I failed. "The project is for file organization, not for defining a single application." But if someone wants to lobby for this, I'd back it in a heart beat. I've kept "ctrl+shift+R" open just in case we need a "Run the VI that my current project has marked as the top-level VI" shortcut key. And, while I'm dreaming, we could even mark *multiple* VIs as the top-level or start up VIs, maybe some of them are on other deployment targets, and hitting ctrl+shift+R could deploy as needed and kick them all off and running. Whoa... a whole new flavor of uber-geek nirvana. 3 Quote Link to comment
Michael Aivaliotis Posted July 30, 2009 Report Share Posted July 30, 2009 "The project is for file organization, not for defining a single application." Hmm, I think for the majority of us, this is the default mode of operation. A project = my application. Quote Link to comment
Val Brown Posted July 30, 2009 Report Share Posted July 30, 2009 It is for me as well. And AQ, I like the CTL+SHIFT+R idea....a lot! Quote Link to comment
Yair Posted July 30, 2009 Report Share Posted July 30, 2009 I feel that a better solution for this is the one shown in Darren's nugget here, because it doesn't require you to do anything beforehand and allows "fixing the mistake". One of the posts there also has a link to a 7.0 equivalent, for those who don't have 8.x. But if someone wants to lobby for this, I'd back it in a heart beat. I certainly don't feel that the project is for file organization (aside from the files tab, which can help with that), but I can't say I understand your exact request. Why not post an idea to the idea exchange yourself? Those who agree can support it there. Quote Link to comment
Black Pearl Posted July 30, 2009 Report Share Posted July 30, 2009 A project (LV project window)= a project (eg. getting that ATE running). That is more than a bunch of files. If it is just for organizing files, then please call it file organizer. Felix Quote Link to comment
Daklu Posted July 30, 2009 Report Share Posted July 30, 2009 Hmm, I think for the majority of us, this is the default mode of operation. A project = my application. I agree. All my projects don't contain an end user application, and I have applications that span multiple subprojects, but I never have multiple applications in a single project. At the very least if it was optional it could be used by those who find it useful. Quote Link to comment
PaulG. Posted July 30, 2009 Report Share Posted July 30, 2009 I feel that a better solution for this is the one shown in Darren's nugget here, because it doesn't require you to do anything beforehand and allows "fixing the mistake". One of the posts there also has a link to a 7.0 equivalent, for those who don't have 8.x. I agree. I use Darren's "Abort" quite often. It sits on my desktop. Quote Link to comment
John Lokanis Posted July 30, 2009 Author Report Share Posted July 30, 2009 I agree. I use Darren's "Abort" quite often. It sits on my desktop. I didn't know about that one. I like it. I just threw mine together in a few minutes after this screwed me up one time too many. I should have searched for an existing solution. Oh well, there is always more than one way to skin a VI, I guess... Why not post an idea to the idea exchange yourself? Done! Go vote for it if you like the idea! Quote Link to comment
Ton Plomp Posted July 30, 2009 Report Share Posted July 30, 2009 I begged. I pleaded. I failed. "The project is for file organization, not for defining a single application." But if someone wants to lobby for this, I'd back it in a heart beat. I've kept "ctrl+shift+R" open just in case we need a "Run the VI that my current project has marked as the top-level VI" shortcut key. Uhm, using the IDE for products?..... Hmm, I think for the majority of us, this is the default mode of operation. A project = my application. A project is A product (internal/personal/external) but I never have multiple applications in a single project. Client and server apps for the same product(project) go into the same project. Ton Quote Link to comment
crelf Posted July 30, 2009 Report Share Posted July 30, 2009 ...I never have multiple applications in a single project. I do - especially when I have multiple targets. That said, I'm all for having the ability to define a VI to be run on a keyboard shortcut. I'd also like to see a button on the toolbar of every VI in the project that I can run the top level with (I'm not a huge keyboard shortcut guy). Quote Link to comment
unicorn Posted July 31, 2009 Report Share Posted July 31, 2009 I have also test VIs (for testing special SubVI, classes or XControls) within a project, even within a class. So I have one, two many main programs. But most of them are used in the development environment. Usually there is only one VI which is build as an application. It a good point that VI modalize themselves when started and unmodalized when finished. Could be a radio button in the VI properties - customize appearance - dialog? Quote Link to comment
Daklu Posted July 31, 2009 Report Share Posted July 31, 2009 Client and server apps for the same product(project) go into the same project. I do - especially when I have multiple targets. Excellent points on both counts and a reminder (again) that everyone has different ways of using Labview. 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.