I've been developing using C# from scratch for less than 3 months and what I got at present is a console application made with Visual Studio 2015. This application consumes a web service, the XML is deserialized, formatted and saved in an Access database, and lastly a success or error XML is sent back to the web server. 3 classes make up the application: The main stream class, a SOAP client class and a DB class.
Now the reason why I'm posting this it's because I need to get that console app integrated with a GUI in which some data gotten from the deserialized XML should be shown (this is an extension of the project that the stakeholders didn't think about before stepping on the developing stage), but I have no idea how to do it.
So far I am reading about "Building WPF Applications" and "Windows Forms" but the documentation is overwhelming and I don't know if I'm on the right path, so can you guys give some guidelines before I start wasting time coding stuff that maybe are not the best option to integrate my console application with a GUI? Is there a way to make the console application become a GUI based application?
I would appreciate if you provide me with practical links to tutorials in which they quickly implement GUIs, my time is running out and I need to start coding right now. Thank you very much for reading this and helping me.
If you're just looking for a barebones GUI and aren't too worried about it looking polished, I'd suggest you right click on your project -> add->Windows Form.
Then, turning your your Console App into a GUI based application is as simple as instantiating your Form-derived class and calling .ShowDialog().
Example:
using System.Windows.Forms;
//Note: if you create a new class by clicking PROJECT->Add Windows Form,
//then this class definition and the constructor are automatically created for you.
//Open MyFancyForm.cs, right click on the form, and click View Code to see it.
public partial class MyFancyForm : Form
{
public MyFancyForm()
{
InitializeComponent();
}
}
static void Main(string[] args)
{
var guiForm = new MyFancyForm();
guiForm.ShowDialog();//This "opens" the GUI on your screen
}
It's that simple. I suggest you add add a new class to your project as a WindowsForm instead of just a class so that you have access to the form designer. Of course, it's up to you to add fields to your form class and have it populate the GUI appropriately.
Edit: if you wish replace the Console entirely, right click on your project->properties and then change "output type" to Windows Application.
What you're trying to achieve is actually relatively simple and straight forward. You need to launch your existing console application process from a new Windows Forms or WPF application and subscribe to its input and output streams.
If you don't want to show your current console application as a visible window, remember to set CreateNoWindow to true.
var processStartInfo = new ProcessStartInfo(fileName, arguments);
processStartInfo.UseShellExecute = false;
processStartInfo.ErrorDialog = false;
processStartInfo.CreateNoWindow = true;
// etc.
Here's an article that goes through all the steps: Embedding a Console in a C# Application
The above article's code can be found on GitHub if you want to take a closer look. Here's an example of what sort of embedding can be done:
With the project it's easy for you to either hide the whole console or have it side to side with some custom UI controls that do further processing with your data.
You can put a TextBox inside your form and redirect anything that would go in the console to the TextBox.
see this for more info
Redirecting Console.WriteLine() to Textbox
Without entering in "why" territories, if you have a console application project you can right click the Project -> Properties -> Application and change the Output type to Class Library (or to Widows Application).
If you choose class library then you can consume your library from wherever.
Related
I need to write a very small application which writes some system data to a file and then exits. I could do this in a console application but I have no need or desire for a console window to appear during this process.
I would normally use a Windows Forms application with no forms, execute the code in the Main method and then allow the application to exit, however, this time I couldn't help but wonder if this is the best way to do it and whether you could do it with a WPF application instead, what the differences are and whether or not once you've remove any forms/windows and unnecessary reference, it matters or not.
WPF and WinForms are two different libraries that show UIs.
If you never show a UI, you aren't using either of them.
You should start with a WinForms project (WPF projects set extra project metadata that you don't want), then delete the reference to System.Windows.Forms.dll.
Alternatively, start with a console project, then change the Output type to Windows Application.
Windows Forms with no window or console app with the type changes to windows application will give you the same result which is a simple app with Main() method and now windows.
WCF will only make sense if you actually want to display something as you're not going to use any of its features in your case.
I was wondering if it is possible to open a second project (in the same solution as the first one) by code in the first project.
For example i have one form application project and another console application project.
The form application starts and when the user clicks a button i want the console application to run and the form application to stop.
Or could someone tell me how to delete my application .exe file?
The projects don't need to be in the same solution to do that. Just use Process.Start to start the executable for another application, and then close the main form to end the current application.
If you don't want to run the code as an entirely different process then it may also make sense to have a 3rd project that is a "class library" that the other two projects could add a reference to. This would allow you to define common code used in either application, using classes that are generalized to be helpful in either project.
I'm not sure what you're trying to do; but Process class has Start and Kill methods that will let you launch / exit processes.
http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx
I've got a console application and I want to run it from another application. But when I invoke it from code--to call program I use ActiveXObject--it shows the console. How do I get it to not show the console? I mean, the program works but console is shown.
If you make the application a Windows Application instead of a Console Application it will not show or open (or use) a Console. Your code can stay the same - and the application will still function (without ever creating a Form or Window).
That being said, if you control the "other" application, you may want to consider making a class library instead of a separate Application. This would allow you to just include and run code within the library without starting a separate process.
You can create it as a Windows Forms application with a hidden window. That's just one possibility like Reed Copsey pointed out, i used it once because i needed to process some specific Window Messages.
I'm having a bit of a trouble trying to create a multi window'ed console application. Currently, my application's main console window is used to collect user input and display output.
Much of this output comes from a separate thread, as live data comes in. I was wondering if there is a way for me to separate my application into two windows, where the second window was either a console window or even any other kind of window that could display the text of the incoming strings... In particular, the main console window would be where the user input commands etc, and the second window displayed what the system was currently working on. This second window could be entirely readonly.
Any suggestions would be greatly appreciated! I would post code, but I don't really have anything relevant (that I can think of) to post....
This will be hard to do.
Here is answer for similar question: Can you have multiple .net Consoles (as in Console.Writeline)
If you really want to do it, you can find logic here: http://www.codeproject.com/KB/cpp/MultipleConsoles.aspx
Maby better approach will be to start another process (console app) and communicate between them thru IPC ( Interprocess communication ) - like named pipes .
More about IPC you can find: http://www.infoq.com/news/2008/01/wcf-comm-options
It is probably easier to just pop-up a Windows Form with a TextBox containing the data you wish to show. You can simply start a new thread and call Form.ShowDialog() to get the form to show.
I've read a few topics about programs that combine Windows Forms and console applications, but it seems my question hasn't been solved yet. Is it possible to run a program from cmd-line and to be able to control the application via forms and via cmd-line commands? It means:
for ordinary users of the application to control the application via (Windows Forms) forms,
for debugging and advanced users to control the application via the console (and optionally see what's happening in Windows Forms))
I know that what I want is quite a big deal, and it will probably mean a lot of work, but still I would like to know how to do it properly.
It isn't difficult, just P/Invoke the AllocConsole() API function to create your own console. For example, make your Program.cs source code file look like this:
static class Program {
[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
#if DEBUG
CreateConsole();
#endif
Application.Run(new Form1());
}
static void CreateConsole() {
var t = new System.Threading.Thread(() => {
AllocConsole();
for (; ; ) {
var cmd = Console.ReadLine();
if (cmd.ToLower() == "quit") break;
// Etc...
}
FreeConsole();
});
t.IsBackground = true;
t.Start();
}
[System.Runtime.InteropServices.DllImport("kernel32.dll")]
private static extern bool AllocConsole();
[System.Runtime.InteropServices.DllImport("kernel32.dll")]
private static extern bool FreeConsole();
}
You just need to start your Windows Forms application with an ApplicationContext instead of a form itself. You are then not depending on the main form to be shown and can act like an console application.
You could also just create a command-line executable and link with the Windows Forms libraries yourself to use them.
Another way would be to use some kind of starter, that fires up the Windows Forms application, and a command line tool that communicates with the Windows Forms application over local networking, or some other inter-process communication, D-Bus or similiar systems - many ways lead to Rome...
Yes, what you want is very possible. You have options. Some I can think of...:
Use UI Automation to write a controller application that can connect to the Windows Forms application and control it. This is new in Windows Vista. There are managed classes packaged in the System.Windows.Automation namespace, which first shipped in WPF, which arrived in .NET 3.0. (Now that I think about it, I'm not sure "new in Windows Vista" is true. It may be "new in .NET 3.0" which implies it also works on Windows XP. Hmmm....) UI Automation requires no code change to the Windows Forms application, but it can be sort of low-level, because you need to program each mouse click or cut/paste. See the answer to Stack Overflow question Is there a way to control a third-party EXE file from VB.NET?.
Modify your Windows Forms application to expose its function via a WM_COPYDATA interface. Then your client application can communicate with it. Again, the model here is two distinct applications, one of which can control or interrogate the other. The .NET Reflector tool is a good example of this approach. There's a ReflectorController, available as part of the ReflectorAddins project on CodePlex. The controller is a command-line tool, that can send WM_COPYDATA messages to Reflector, to tell it to open a new assembly, navigate to a particular class, and so on.
The code for the controller:
http://reflectoraddins.codeplex.com/sourcecontrol/network/Show?projectName=reflectoraddins&changeSetId=29526#19979
This approach will work for any Windows Forms application. You will need to override the WndProc method. To see how, check The Code Project article Use WM_COPYDATA to send data to/from C++ and C# Windows processes.
I also used this approach to build a Windows Forms-based progress monitor that can visually display the progress of long-running tests.
Within your application, expose a COM server object that can be programmed. This is exactly how Microsoft exposes Office function to applications. Office Automation allows any COM-capable program (C#, VBScript, PowerShell, Perl, PHP, etc.) to "drive" Office applications. The Office application is visible while that is happening. This approach would also require additional code in your Windows Forms application; specifically you have to host a COM object and hook it up to your UI layer. This may be preferable if you want maximum flexibility for superusers - they can write their own scripts to drive that component.
I'm sure there are other options.
I remember seeing IronPython being used in a demo controlling Windows Forms from Python's command line interface (IDLE).
Edit:
I could not find the original video but this one should show what is possible without too much effort. See this video and jump to 19:00.
This would be possible. You will have to look into threading the Windows Forms form, possibly with the use of a separate application domain within the same process. You might look into creating a proxy object (a kind of message class inheriting MarshalByRefObject).
Normally when looking at your application, you have an UI layer and a business layer (and a data layer, and who knows many more layers). You can think of the console client as an UI layer (with simple command inputs) and the Windows Forms client as another one.
Simply check at application startup for command-line arguments. If there are arguments specified, instantiate the simple console classes, otherwise instantiate the (probably more complex) Windows Forms classes.
If you want your changes to reflect in the Windows Forms application (while controlling it from the console application) setup your applications as much as you can with databinding. Let your business layer reflect what's actually going on in your application.