Keyboard shortcut (Ctrl + period) won't work in stand-alone executable that I've built

[darby22]

I've built a stand-alone executable for a VI through the application builder. The 'run' keyboard shortcut (Ctrl + r) works, though the stop (Ctrl + .) no longer works. In fact, when the program is running, 'stop' under the Operate tab is greyed out. Does anyone know why?

This is particularly problematic because I'm using Matlab to run and stop the Labview stand-alone using the keyboard short-cuts through the command prompt. Without the function of Ctrl + period the rest of my code can't stop Labview.

Thanks in advance.

[altenbach]

What are the windows options in the properties?
Do you have a runtime menu configured?
How does it behave in the development system?

[darby22]

Altenbach,

VI properties only has two categories, General & Memory Usage. There aren't any window options that I can manipulate in the stand-alone. The following two links say to check Window Appearance and the Run-Time Menu to bring back the ctrl+period function, but neither option are present in the stand-alone.

http://digital.ni.com/public.nsf/websearch/3BE03984DF617DB386256CF600511D0E?OpenDocument

http://digital.ni.com/public.nsf/allkb/D3BFB43C919C787C86256F430054268C

I didn't configure the runtime menu in my original VI. When I open it to check, Ctrl+. is listed as the shortcut for stop.

Ctrl+. works as a shortcut for stop in the original VI.

[RavensFan]

If the abort button is removed from the window that is build into the executable, then the Ctrl-period is not going to work.

[darby22]

RavensFan, the abort execution button is still present and functional in the stand-alone executable.

Does anyone know if there is something I could be doing wrong (or something additional I need to do) during the application build that could be disabling some of the keyboard shortcuts?

Thanks for the replies so far.

[altenbach]

Can you attach a simplified copy of your toplevel VI? 

[James.M]

The ctrl+. doesn't work in an executable as far as I can see. You'll need to program up that key combo using an event structure. See attached executable that won't stop when you press it.

This is how you can handle a Ctrl+. event:

[Hooovahh]

CTRL + . for abort is a debug tool, and for that reason shouldn't work when you aren't debugging your software.  The breakpoint, and highlight execution also don't (generally) work in an EXE either.  Write code that doesn't rely on these techniques to stop your code and you'll be better for it.

[Alexander_Sobolev]

Do you normally turn off PC by disconnecting power? Abort button is not a stop button. It is the last tool to abort execution. LabVIEW will just quit.  Who will clear memory, files access flags, set any hardware to idle state, release resources?

When you are building exe, it configures  top level VI to start automatically. Can not Matlab use command prompt to run exe, why Ctrl+R?

Then - programmatic tools to control it.

I was using simpe UDP listening parallel cycle that accepts commands from anywhere. Technically in Labview I built a small dll that was just converting command calls to UDP commands and sending them to main application, and called that DLL from matlab.

But ways to control external application is a separate topic. Using windows tools to locate application process and kill it is also covered by it. Also a nice way to stop a bad app.

[altenbach]

As has been discussed many times, an executable should never have any need for a stopped, non-running state.

(e.g. here or here)

Design a proper state machine such that the executable starts (run when opened) in an idle state and returns to it whenever there is nothing to do. Once you are completely done, close the program. This is the same as with any other program. Have you ever had a need to "stop" MSword or internet explorer? A stopped state is only useful during development, not once it is deployed standalone.