3

我正在编写同时具有CLI和GUI的应用程序。CLI和GUI应用程序

我读到关于它的大多数问题和文章,并发现了高度有用的这个问题:

Can one executable be both a console and GUI application?

我最后的代码如下所示:

 if (args.Length > 0) 
     { 
      //console code    
     } 
     else 
     { 
      FreeConsole(); 
      Application.EnableVisualStyles(); 
      Application.SetCompatibleTextRenderingDefault(false); 
      Application.Run(new Form()); 
     } 

这在运行.exe文件时的伟大工程通过双击,或在调试时,或从控制台与参数。

然而,不带参数的控制台运行它时,该GUI被打开,像我预期的,但控制台被卡住等待GUI关闭。

这是不寻常的GUI和控制台的行为。控制台通常启动GUI,而不是等待其退出,但是用于新命令。

有没有办法避免它?

回答

0

在您链接到的问题接受的答案包含了这样一段话:

俊峰的第二个技术是什么ILDASM使用。他引用了ildasm的作者在两种模式下运行的过程 。 最终,它的功能如下:

该程序被标记为控制台模式二进制文件,所以它始终使用控制台启动 。这允许输入和输出重定向正常工作 。如果该程序没有控制台模式命令行参数,则它将重新启动。简单地将FreeConsole调用到 是不够的,这使得第一个实例不再是控制台程序。这是因为 启动程序的过程cmd.exe“知道”它启动了一个控制台模式程序 并且正在等待程序停止运行。 调用FreeConsole将使ildasm停止使用控制台,但它 不会使父级进程开始使用控制台。

对我来说,看起来像有一个二进制试图在控制台子系统和GUI子系统之间切换(这真的是不允许的)的头痛是比它的价值更努力。

一种方法是将有一个独立的GUI应用程序.exe。只要控制台应用程序在没有参数的情况下启动,它就会启动GUI应用程序并关闭它自己。

为了防止代码重复这可能需要将放在一个单独的类库中的所有应用程序的实际逻辑。

0

也许不是一个答案,你的直接的问题,但这种双重的解决方案,你就是自找麻烦:)这是一个黑客工具,将在某些情况下工作,但在其他没有。

适当的解决方案是在单独的类库排除的功能和应用逻辑,然后从两个控制台和GUI应用程序调用“发动机”。将所有这三个项目放在一个Visual Studio解决方案中。所有功能和绝大多数的代码应该在该类库中,GUI和控制台项目只会处理依赖于环境的特定方面(例如,按钮点击事件,只能在GUI应用程序等)

0

通常的方式做,这是从逻辑抽象的演示文稿,然后有两个EXE文件,一个CLI,一个图形用户界面,而不是有一个,可能是因为存在。沿着这条路线走下去,你会因为两种方法的好处而导致某种可怕的妥协。 带命令行选项的GUI不是CLI应用程序,它是一个带有不可见/短命窗口的GUI。

0

这看起来正确。您启动一个只在应用程序停止时返回的命令。

如果你不想等待它返回,在一个新的线程启动它。 (ThreadPoolThreadTaskasync/await在C#5.0 =>挑选自己喜欢的)。

+0

我thoght它并试图做到这一点,使用一个线程,用的IsBackground =虚假的声明,但它并没有改变任何东西,但它仍然在等待应用程序退出。 – sara 2012-03-13 11:26:28

0

需要在不坚持控制台从控制台启动GUI应用程序?从命令提示类型:

start "[title not necessary for gui exe]" "full path to .exe" 

参见编写应用程序在GUI/CLI/CUI /网络模式下工作是使用libgreattao here

+0

无论如何,GUI应用程序都会立即返回。不需要使用'start'。这只是控制台应用程序所必需的。 – Joey 2012-03-13 11:31:08

+0

启动命令阻止cmd提示等待进程结束 – 2012-03-13 11:33:17

+0

正如我所说的,它不会等待GUI应用程序。尝试'记事本'或类似的东西。 – Joey 2012-03-13 11:53:11

0

最好的办法。

在sourceforge.net上搜索。

Libgreattao解耦业务逻辑和沟通机制,这样你就可以在你的程序到处放libgreattao相关的代码。