tags:

views:

157

answers:

2

In a C# .NET GUI Application. I also need the console in the background for some tasks. Basically, I'm using a Thrid Party library for some processing (takes lot of time) which writes its intermediate results to console. This processing is a computationally time taking task. So, I'm assigning this task to backgroundworker. I mean background worker calls these library functions. But problem is there is no way for me to show the user status of computation, because I don't have source of the library. I was hoping Console will be shown. But surprisingly Console.WriteLine doesn't seem to work. I mean, there isn't any console window shown. How come?

EDIT:

I tried setting application type = console. But there seems to be a problem. Only, main thread is able to access the console. Only Console.WriteLines executed by main (Application) thread are displayed on console. Console.WriteLines executed by other (BackgroundWorker)threads of the GUI, the output is not shown. I need console only for Background workers. I mean, When background worker starts, console starts & when it ends console will be off.

+2  A: 

Create your own console window and use the Console.SetOut(myTextWriter); method to read anything written to the console.

jgauffin
pecker
If the third-party library is a .NET assembly and uses `Console.Out` this will let you grab whatever it is printing and display it in your own window. If it's a native DLL that you p/invoke, `Console.SetOut` won't be effective.
Ben Voigt
A: 

Set your application type to "Console Application". Console applications can also create GUI windows with no problem, and write to the console at the same time.

If you don't have control of the main application, and you want to make sure that a console is shown, you can p/invoke AllocConsole (signature here).

This isn't the same as being a console application though, your application will always get a separate console window, which might be surprising to someone who launched it from a command prompt window. You can work around that with AttachConsole (signature and example here) but shell redirection of the output still won't work. That's why I suggest setting the application subsystem to console if you can.

Ben Voigt
pecker
GUI application class doesn't inherit from `Form`. In a GUI application your main function creates an instance of some class derived from `Form` and calls `Application.Run` (for WinForms, a different but similar function for WPF). You can call `Application.Run` from a console program as well, and it will show a GUI alongside the console window.
Ben Voigt
Here's an explanation, that also shows that a GUI program can be remarked as a console program AFTER it's done building: http://www.codeproject.com/KB/cpp/EditBin.aspx
Ben Voigt
Also: http://msdn.microsoft.com/en-us/library/fcc1zstk.aspx which described the linker flags which set the SUBSYSTEM field in the PE header (someone mentioned this header, then deleted their comment for some reason). Note that `/SUBSYSTEM:WINDOWS` is used when *Application does not require a console, probably because it creates its own windows for interaction with the user*. A `/SUBSYSTEM:WINDOWS` application is not required to create windows, and a `/SUBSYSTEM:CONSOLE` application is not prohibited from creatinbg them. These two options really mean **CONSOLE** and **NOCONSOLE**.
Ben Voigt
claws