Modal Madness

[John Lokanis]

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

[MikaelH]

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

[Antoine Chalons]

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 .

[John Lokanis]

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.

[Aristos Queue]

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.

[Michael Aivaliotis]

"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.

[Val Brown]

It is for me as well. And AQ, I like the CTL+SHIFT+R idea....a lot!

[Yair]

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.

[Black Pearl]

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

[Daklu]

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.

[PaulG.]

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.

[John Lokanis]

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!

[Ton Plomp]

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

[crelf]

...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).

[unicorn]

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?

[Daklu]

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.