I know that I can specify program arguments in CLion with Edit configurations, but I find it quite inconvenient when I want to quickly run the program with new arguments and don't want to store it in a separate run configuration. Is there something like a shortcut displaying dialog with arguments input?
I know I can always use terminal, but I'd like to have an access to CLion's GUI debugger.
Related
It's definitely difficult to write and debug autokey scripts in it's GUI window. I know that you can run a script using autokey-run --script {script-name}.
But is it possible to use autokey module explicitly in a .py file and write a standalone script and run it independently? That way it would be possible to take advantage of all IDE features like autocompletion, line-by-line debugging, seeing stacktrace in case of exception when writing a script.
There is 2 ways that I can run exe file: with double click or via command line.
I want to do different function from each way..
Is it possible?
Thanks!
You could also start via a Process, Schedule, register an extension, Autostart any many more. You need to tell us what you want to achieve for a satisfying answer. Following Answer is for switch a command-line and a gui mode.
If you have the Install of you Program in you hands, you can simply use "Command" to read the commandline arguments and use that for a command line mode and a gui mode.
Make a switch like "-gui" and simply write
If Command = "-gui" Then
frmMain.Show
End If
I've gone through the questions and the solution proposed works great. It helps us both compile and run programs in Sublime text editor instead of opening the command line prompt every time you need to run a program.
However, it doesn't work when you have to accept input from the console (Like cin and Scanner(System.in)). How do you fix those?
Running programs within Sublime Text cannot accept input, regardless of the language they're written in. To interact with your program, you'll have to run it through the shell. The only way around this is if you're using an interpreted language like Python, Ruby, Perl, JavaScript, etc., in which case you can install the SublimeREPL package and run your code via an interactive session. Unfortunately, since you're using compiled languages, this is not an option.
Need to retrieve the path of an invoking shortcut.
This is a Qt application, but I suspect I'm going to have to go native to do this, primarily on win. I can come up with a scheme for Mac..
Is there a way to get this? The win terminal application seems to be able to do this, for instance.
(it needs to work for a moved shortcut, so I can't embed the path in an arg.)
When a process is started, there is no information passed that identifies the shortcut that was used to invoke the new process. You need to use command-line arguments to pass startup parameters to the new process.
this is not yet another "I need a console in my GUI app" that has been discussed quite frequently. My situation differs from that.
I have a Windows GUI application, that is run from a command line. Now if you pass wrong parameters to this application, I do not want a popup to appear stating the possible switches, but I want that printed into the console that spawned my process.
I got that far that I can print into the console (call to AttachConsole(...) for parent process) but the problem is my application is not "blocking". As soon as I start it, the command prompt returns, and all output is written into this window (see attached image for illustration).
I played around a bit, created a console app, ran it, and see there, it "blocks", the prompt only re-appears after the app has terminated. Switching my GUI app to /SUBSYSTEM:Console causes strange errors (MSVCRTD.lib(crtexe.obj) : error LNK2019: nonresolved external Symbol "_main" in function "___tmainCRTStartup".)
I have seen the pipe approach with an ".exe" and a ".com" file approach from MSDEV but I find it horrible. Is there a way to solve this prettier?
This is not behaviour that you can change by modifying your application (aside from re-labelling it as already discussed). The command interpreter looks at the subsystem that an executable is labelled with, and decides whether to wait for the application to terminate accordingly. If the executable is labelled as having a GUI, then the command interpreter doesn't wait for it to terminate.
In some command interpreters this is configurable. In JP Software's TCC/LE, for example, one can configure the command interpreter to always wait for applications to terminate, even GUI ones. In Microsoft's CMD, this is not configurable behaviour, however. The Microsoft answer is to use the START command with the /WAIT option.
Once again: This is not the behaviour of your application. There is, apart from relabelling as a TUI program, no programmatic way involving your code to change this.
Maybe write a console-based wrapper app that checks the parameters, prints the error message on bad parameters, and calls/starts up the actual program when the parameters are correct?