2009/12/27 Mimu Bunnylin <[email protected]>: > Currently, programs for Windows have to be specified as either $APPTYPE > Console or GUI. > > If the user runs a console-mode program from a console, the existing console > is kept; run outside a console, a new console is created. > > If the user runs a GUI-mode program outside a console, no console is > created, and if run inside a console, the console is immediately released. > > But suppose I want a program that will continue running in a console if run > from a console, but will not automatically create a new one if run from > outside a console. (Eg. without command-line arguments, launch the program's > GUI, otherwise print a list of valid arguments in the console.)
This is basically how linux works. The child process of a terminal inherits the standard input/output/error pipes of the terminal. If the process is called from outside the terminal, the standard output pipes are re-directed to ~/.xsession-errors by the desktop environment (in my experience, at least). > Would this be hard to implement? Presently I have to compile a console-mode > application, and use the Windows API call FreeConsole to eliminate the > console if it is not needed. This still makes a useless console pop up for a > moment, which looks silly. This could be as simple as adding a check > somewhere in the system unit for whether a console is associated with the > process or not, and decide the appropriate $APPTYPE at runtime. You can detect if a process is called from a console under windows. I've got some code at work for that. What you would have to do is to detect this, then attach the parent process' console to your app. I haven't tried this, but it sounds achievable. Henry _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
