2009-10-27 27 views
24

¿Es posible (y en caso afirmativo, cómo hago) hacer que un solo programa funcione como una aplicación de consola y una versión de GUI usando Delphi 2007?Programa como consola y GUI

Lo que persigo es que si el programa se ejecuta con las opciones de línea de comando adecuadas, debería funcionar como un programa de consola, imprimiendo salida a la consola usando WRITELN, pero si no se dan argumentos de línea de comando debería ejecutarse como una aplicación GUI de Delphi normal? El intérprete de línea de comandos espera que la aplicación termine antes de permitirte ingresar un nuevo comando, mientras que una aplicación de GUI iniciada desde la línea de comando te devuelve inmediatamente a la línea de comando. y la aplicación GUI se inicia en un proceso separado. Quiero este comportamiento retenido.

no me importa algo como esto:

SI ENTONCES GUI StartApplicationAsGUI (ParamStr (0))

decir. No me importa que deba reiniciar la aplicación usando alguna forma de llamada EXECUTE para iniciarla en modo GUI si es necesario, siempre que la línea de comando vuelva a la entrada de la línea de comando cuando se inicie la versión de la GUI.

preferiría una solución/sugerencia de que es a lo largo de las líneas de:

< Analizar Comnand Línea >
SI ENTONCES ConsoleMode
      RunConsole (Parámetros)
else begin
      Aplicación.Inicializar;
      Application.CreateForm (...)
      Application.Run;
FIN

(o viceversa, es decir. Hacer las cosas de una manera especial si el modo de interfaz gráfica de usuario)

por lo que todavía puedo usar IDE y VCL de Delphi al hacer la interfaz gráfica de usuario ...

Respuesta

4

Windows tiene valores diferentes en el encabezado del ejecutable para la consola y la aplicación de interfaz de usuario (ver más detalles here). Por lo tanto, parece imposible hacer funcionar el mismo ejecutable en ambos modos.

Como alternativa, puede abrir una consola en su aplicación de interfaz de usuario, pero será una nueva consola, no la que ha iniciado la aplicación.

12

En Windows esto es un poco complicado. En realidad, la distinción entre una aplicación de consola y una GUI es una sola bandera en el encabezado PE. Puede escribir fácilmente aplicaciones de consola que creen ventanas, pero de esa manera siempre tendrá la ventana de la consola (podría ocultarlo, pero eso no sería bueno cuando las personas ejecuten su programa desde cmd).

Usted puede, sin embargo escribir una aplicación de interfaz gráfica de usuario que crea una consola si es necesario, usando la función AllocConsole:

Un proceso puede estar asociado con una sola consola, por lo que el AllocConsole función falla si el proceso de llamada ya tiene una consola. Un proceso puede usar la función FreeConsole para separarse de su consola actual, luego puede llamar al AllocConsole para crear una nueva consola o AttachConsole para adjuntarla a otra consola.

Si el proceso de llamada crea un proceso secundario, el elemento secundario hereda la nueva consola.

AllocConsole inicializa la entrada estándar, la salida estándar y los identificadores de error estándar para la nueva consola. El identificador de entrada estándar es un identificador para el búfer de entrada de la consola, y los controles estándar de salida y error estándar se manejan en el búfer de pantalla de la consola. Para recuperar estos identificadores, use la función GetStdHandle.

Esta función se utiliza principalmente mediante la aplicación de interfaz gráfica de usuario (GUI) para crear una ventana de consola. Las aplicaciones GUI se inicializan sin una consola. Las aplicaciones de consola se inicializan con una consola, a menos que se creen como procesos separados (llamando a la función CreateProcess con el indicador DETACHED_PROCESS).

Sin embargo, cuando se ejecuta desde cmd, es probable que aparezca otra ventana de consola en lugar de volver a utilizar la existente. No sé si existe una buena solución allí.

12

OMI, el mejor enfoque aquí es tener clases no visuales que realmente hacen el trabajo del programa. Luego puede llamarlo desde un programa GUI, y también puede llamarlo desde un programa de línea de comando separado. Ambos programas son solo envoltorios alrededor de la funcionalidad de su (s) clase (s).

Esto obliga a que el diseño sea también limpio: sus clases están necesariamente separadas de la capa de la GUI de su aplicación.

+2

Esta es la respuesta correcta. – Tim

+0

El problema con este enfoque es que requiere la distribución de tres archivos si se realiza correctamente: 1) Un ejecutable de línea de comandos, 2) Un ejecutable GUI y 3) Un archivo de biblioteca que contiene el núcleo relevante del programa. Preferiría un solo ejecutable, y la mejor opción parece ser tener un programa de GUI con un bit de consola en el encabezado que luego puede reiniciarse con una consola separada si necesita ejecutarse como GUI. Al igual que ildasm en los diversos enlaces provistos. – HeartWare

+0

Bueno, yo diría que solo dos ejecutables son factibles. Si construye el EXE incluyendo sus BPL, entonces no hay necesidad de distribuir ningún archivo "core", solo un exe por aplicación. Pero obviamente usted es quien conoce sus necesidades de despliegue; Me alegro de que la respuesta de ildasm haya sido útil. – JosephStyons

3

AttachConsole() se puede utilizar para mantener la consola de los padres. P. ej. Si la aplicación se inicia desde una cáscara línea_de_órdenes, AllocConsole() se puede evitar:

if not AttachConsole(ATTACH_PARENT_PROCESS) 
then AllocConsole; 

Más información aquí: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx

+0

un ejemplo de código de Chee Wee está aquí: http://chuacw.ath.cx/blogs/chuacw/archive/2015/12/02/delphi-app-with-console-and-gui.aspx – dummzeuch

Cuestiones relacionadas