C# Making a Frontend to a Console Program? - c#

I wrote a console program in c# that takes up to three files as input, and does some data calculations on them.
I'd like to make a simple frontend that allows the user to easily
import files - basically choose up to three files to be routed to the backend code
change settings - I have about 10 settings that I'm currently storing in an app.config file. maybe a simple settings box would be nice
see what's going on - the console program shows some status messages that might be useful to display on a GUI
I have practically no experience with windows forms or GUI design, so I really don't know where to begin. I compiled the backend stuff into a *.dll and am currently playing around in design mode of sharpdevelop...but i really have no idea how to get the two to work together.
any pointers would be greatly appreciated!

The usual pattern, in cases like these, is to make the main features of the application into a class library and call that from a wrapping executable, such as a console app, winforms app or webforms app (if possible). That way you can easily adapt the interface as needed and simply route input and output to and from the class library.
Edit: I realize this isn't a very indepth answer, but I hope it helps to get started at least, together with any other answer that may arrive.

If you want to get started with GUI design in .NET, I recommend you choose WPF (Windows Presentation Foundation). This is the latest technology released in the UI/graphics area by Microsoft and is where everything is heading now. (Windows Forms won't be obsolete for a long time, though it is surely but slowly becoming deprecated.) I noticed however that you are using SharpDevelop, which doesn't yet have real support for WPF (as far as I know), whereas it certainly does for WinForms. If there's any chance you can use Visual Studio, I recommend you begin by learning WPF. You have the advantage of not being confused by previous experience with the styles and methodologies of WinForms, so it would very much be the right way to go.
Whichever you wish to learn, the Getting Started page of WindowsClient.NET (the official MS site for both WinForms and WPF) would be a great resource. There's also a few MSDN articles on getting started with WPF.
Hope that helps.

Have you tried Visual Studio Express editions? They're free and come with a designer for either WinForms or WPF applications.
As a first pass you'll need 3 text areas for the filenames, with associated buttons to bring up the file open dialog (it doesn't actually open the file just returns the filename).
A label to display the status - updated from your worker code.
Then either the various radio buttons, check boxes etc for your configuration settings.
Oh and don't forget the "Start" button to set off your process.
If your process takes a while you ought to use a background worker thread. You can then implement a "Cancel" button to safely abort the process and tidy up if it goes wrong.
There will be optimisations and reorganisations that you can do once you've got it working.

Your question is quite indistinct. If you're asking about working with GUI, you should read some book on Windows Forms.
And if you're asking about how to put your dll in your new windows forms application, then you should just add a reference to it in winforms project's properties and then use classes from dll's namespace.

Related

Making a program operate from system tray in C# .net

I'm working on a small internal use utility ATM, and I'd like it to appear in the system tray rather than the task bar. I'd also like it to be minimised there from startup rather than loading the main form. Also I'd like to know how to customise the left click action and right click menu on the system tray icon.
I'm failing to find a detailed walk through on this, I'm pretty new to C# (and in fact Windows in general!) so not 100% sure what to search for!
Read this article, it's a good tutorial:
https://www.simple-talk.com/dotnet/.net-framework/creating-tray-applications-in-.net-a-practical-guide/
The basic answer of using a NotifyIcon is correct but, like many things .NET, there are a host of subtleties involved in doing it right. The tutorial mentioned by Brad gives a good walk-through of the very basics, but does not address any of these:
Does closing the application from the system tray properly close any open child forms?
Does the application enforce that only one instance of itself may run (applicable to most, though not all, tray apps) ?
How to open WPF child windows as well as WinForms child windows, if desired.
How to support dynamic context menus.
The standard NotifyIcon exists in WinForms space; can I do a pure WPF solution? (Yes you can!)
I just had an article published on Simple-Talk.com that addresses these points and more in great detail, providing a tray application framework that you can put to use immediately, plus a complete, real-world example application to show everything in practice. See Creating Tray Applications in .NET: A Practical Guide, published November, 2010.

C# and Visual Studio?

I'm trying to learn C# from some YouTube videos, but I have a few concerns. I started with JavaScript, wanted to learn a software language, so I learned some C++, but then I found out that C# is better for GUI programming, so now I'm going with that.
The problem is that I feel like VS is doing a lot of things I should know how to do but don't... When I add a button or create a new class or something it's all done with VS. I want to know what it's doing, though, so I can do it myself if I need to.
I'm on the video explaining classes, and I was wondering where the header file was. I couldn't find it, so I searched online and, come to find out, unlike C++, C# doesn't have header files. Are the class files automatically linked?
Is it practical to learn how to do everything manually, or is C# done solely in VS anyway? Is there a way to keep track of what files and code snippets are added and created when a button is pressed in VS?
I am bias, but the best way to understand and learn what is going on in a program is to debug it.
Creating a new C# app in Visual Studio will give you the fastest path to this. You shouldn't have to worry too much what Visual Studio is generating for you, because if you want to understand it, simply step through the code in the debugger. You can see exactly what calls are being made, how each of them changes state, etc, etc.
If you make a basic GUI app, then step through the InitializeComponents function, that gives you a really good sense of how VS sets things up for you.
C# can be used outside of VS, but having all the components so you can just hit F10 and starting stepping away in the IDE makes it the best choice.
Well, best way would be to not use the VS Designer, if you want to learn what happens behind the curtains. You may of course code every single line by hand and it still will work. Eg. to add a button:
Form form = new Form(); // create my form
Button button = new Button(); // create the button
button.Text = "Click me!"; // add some text
form.Controls.Add(button); // add the button to the form
Application.Run(form); // start the applications main thread and display the button
There are dozens of tutorials outside, just find the one that suits you best.
The thing is that visual studio is giving you all the preregistered stuff in built. So you just need to build your own class templates the definition will be presented to you default.
So if you create a class call employee it will create basic syntax for you and you need to write the logic directly.
Thanks,
Jigar
C# as a language is used to develop several kinds of applications such as console-based applications, Windows desktop applications and Web applications.
For the former, you will code everything mostly by hand, even if you are using Visual Studio.
For the latter two, since they are GUI based, it's recommended to use Visual Studio so that you can use the drag-and-drop approach as well as have Visual Studio take care of the routine tasks so that you can focus on the logic and actual development.
IMO, you shouldn't try to learn everythin, but anyway - core concepts will broaden your understanding and will surely help you in further dev-life.
If you want what exactly VS do with your code - put some "VCS guard" at top of project. Use Git or Mercurial and you could see exact changes that was applied to each file (commit everything before you going perform interesting action and check changes after). It could help you to track anything that will happens with your project. But for most cases its not very productive to do everything by hands. DevTools were made to remove very bored routine.
Its very useful to know how you can do something without VS installed, but all such tasks is usually not directly related to programming, mainly its some kind of supporting stuff.
Ex. how build a project with msbuild or csc.exe (C# compiler) to setup homebrew continuous integration system.
If you want really deep grasp into .NET - read CLR via C# by Jeffrey Richter. IMO it's far more important to know system guts than to know how to place button on the form without VS-designer.

User Click Tracking Library for Desktop App

We are looking into the possibility of allowing users to opt into a program where they report what button clicks etc. they do, and I was wondering if anyone can suggest a good library which already does this. Based on the way the app is implemented, we have access to the base "Button" class and can add code on the click which records the fact that the button was clicked.
What we're looking for is a library which can record all these clicks, store them locally, and then send them to us at some point in the future when the user has internet access.
Does something like this exist in an open or closed form?
Thanks,
Liron
Our app can run code in either c# or javascript, since it runs in Unity3d, but we have other desktop apps which are pure c# and would prefer a library we can run across all our applications.
We ended up going with DeskMetrics, which seemed like a good fit for our needs. We also looked at TrackerBird which has some nice features which weren't necessary for our particular requirement and wasn't working within the limited requirements of Unity3d.

Make an auto updatable VB.NET application

I have an application that is running fine.
I just want to add the auto update feature in that application so that the application can automatically download the updates and install it on the computer.
The easiest way to do this is to make your application a ClickOnce application. It is a method of application deployment which has a very simple process for deploying new versions and having the client check for and install updates. Here is a CodeProject articles which has a full overview
http://www.codeproject.com/KB/install/QuickClickOnceArticle.aspx
It depends on how your application is structured and what kind of files you want to update.
But, basically, what you'll need is a "place" (like a WebService, for example), where your application will get the necessary info to update. Then it's downloading the necessary files and placing them in the correct folders.
I'd also advice you to write a new program, "updater", whose whole purpose it's to update your "main" program.
It's difficult to give you code on how to do this, as it it's more like a pattern that you'll have to implement.
Edit Also, as said by JaredPar, some platforms may provide tools to do this.

Multiple Consoles at Once

Is there an easy way to do this?
I am testing my networking application using just the console for now. What would be nice is to have multiple consoles from one project and one press of the "Debug Now" menu item.
I could, like I have in the past, use multiple projects but that's seems unwieldy. Ideally I could launch multiple console instances (running from the same thread is fine) and have them not cover the other consoles when they do launch. Launching side by side would be awesome!
How practical is what I'm asking? Is it possible?
Thanks!
There is no easy way to do this.
Technically, you can create a separate console for an application, but it requires creating a child process to host the console. There is a CodeProject article showing the basic procedure.
That being said, at the point where you want multiple "windows" showing data, I think migrating to a (simple) GUI application is a better choice.
You could build & start a master application that runs and positions your test applications. See what the System.Diagnostics.Process class can do for you.
The real problem however is in debugging multiple instances of the same app at once. I'm not sure that that is possible.
System.Diagnostics.Process.Start("MyOtherProgram.exe");

Categories