.Net Program with both WinForm and Console Interfaces - c#

I have a simple question and I'm sure it's been answered, but I can't seem to find the solution I'm looking for.
My basic question is that I've created a console app in .Net that runs automatically on a task scheduler every day, but now my clients also want a windows form-based interface that they can use to run special runs (they use the GUI to specify a few parameters - such as specific dates, etc - to make the program run a bit differently).
The way I thought to do this would be to convert my console app to a WinForm solution and to include Command Line Arguments for when I wanted it to run as the original console app with defaults, but I'm thinking that's not the right way since it would still involve a form load.
My other thought was to convert the "engine" part to a DLL and to make 2 executables - One a console app and one a winforms app, but I'm not sure if that's right either / could lead to more maintenance.
What is the correct way to do this?
I'm writing this in VB, but am equally comfortable with C# solutions if that is easier for you.
Thanks!!

Typically, I'd split the logic into a library, then make a simple console app and a simple Forms app to call into the logic in the library.
You can then distribute these separately and use them as they are intended, without duplication of code.

You can modify your Program.cs to accept arguments, then if some args had been passed to your app prcess them and exit from main, else start your main form, something like this:
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
if (ProcessCommandLine(args))
return;
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
static bool ProcessCommandLine(string[] args)
{
//Process it, if some has been processed return true, else return false
}
}

Or you can make the form invisible and go with your first option, reading the commandline.
here is a way of making the invitial form invisible. Form Invisible

Three projects as Reed suggested is a correct approach, however if you really need 1 executable (which we for some reason really wanted in one case) you can do following:
static class Program
{
[STAThread]
static void Main(string[] args)
{
if (args[0]== "-ui")
{
System.Windows.Forms.Application.EnableVisualStyles();
System.Windows.Forms.Application.SetCompatibleTextRenderingDefault(false);
System.Windows.Forms.Application.Run(new MyFormWork());
}
else if (args[0] == "-console")
{
Helper.AllocConsole();
DoYourConsoleWork();
Helper.FreeConsole();
}
}
public static class Helper
{
[DllImport("kernel32.dll")]
public static extern Boolean AllocConsole();
[DllImport("kernel32.dll")]
public static extern Boolean FreeConsole();
}

1: you can use XML for arguments. your console just need to read XML for its argument.
then create a form app just for editing XML and save.
Benefit:
your app is running by task scheduler so your form do not need to .
for user it's easy to open form app and change something that will save to xml
Console --run every day without any notice
Argument.xml -- argument for Console .
Form -- user interface
2: you can mix both within a form but it will run every day in form base not good idea

Related

C# not outputting to console

I'm sure there's some simple answer, but none of the other Stack Overflow posts has helped me. My code will not log to the Console, and it's hard to do anything useful with that state of affairs.
using System;
using System.Diagnostics;
namespace Learning
{
class MainClass
{
public static void Main (string[] args)
{
Debug.Log ("this?");
Debug.Print ("How about this?");
Console.WriteLine ("WORK");
Console.ReadLine ();
}
}
}
I've been able to write to the console before, I don't know why it's being persnickety now.
Probably because your code doesn't actually compile. Log() is a static method of Debugger, not Debug, and it takes three arguments: level, category, and message.
public static void Main (string[] args)
{
System.Diagnostics.Debugger.Log(1, "category", "this?");
System.Diagnostics.Debug.Print ("How about this?");
Console.WriteLine ("WORK");
Console.ReadLine ();
}
It's worth noting that Debug/Debugger methods will not do you any good unless you are Debugging. To start a debugging session in mono, go to the Run -> Debug
You may want to check what kind of application you are using. For example, if you are making a Forms Application, you won't have access to the Console functions.
You can change this by going into the Solution Properties, and changing it from a Windows Forms Application to a Console Application. This won't have any effect on your program, other than it will run a Console alongside.

Keep a Form running after COM visible DLL terminates

I created a COM Visible DLL in C# that should show a Form after some inputs from the User in the host application (unmanaged). It works fine with ShowDialog(), but ideally the Form should keep running even after the DLL finishes. Because the Form need some Data a separated Project with Main(string[] args) is not an option.
How can I accomplish this? I tried something like that but it didn't worked.
public class FormManager : ApplicationContext
{
FormMain frmMain;
public FormManager()
:base(new FormMain())
{
frmMain = (FormMain)this.MainForm;
frmMain.Closed += new EventHandler(OnFormClosed);
}
public void SetData(object o1, object o2)
{
if (frmMain != null)
{
frmMain.SetData(o1, o2);
frmMain.Show();
}
}
private void OnFormClosed(object sender, EventArgs e)
{
ExitThread();
}
}
I have no idea where Application.Run should be inserted.
I, too, am a little unclear as to what exactly you are trying to do here... but normally, if you are placing the Application.Run somewhere in that code, it would be in place of this line:
frmMain.Show();
Of course, by using Application.Run you will be freezing this code (the thread that calls Application.Run) until the form in question closes... So maybe that doesn't really accomplish what you want (it is, indeed, unclear).
Edit After Clarification of Question
Here's the thing about COM in .NET that was not true about previous iterations of Microsoft languages. When you call an assembly in .NET via COM (OLE) the calling assembly subsumes the COM exposed code into its runtime. In other words, when you look in the Task Manager, you won't see both of your assemblies running! You'll only see the one that did the calling. Thus, when you close the main assembly, you close any running code attached to it, including your COM code.
There is one way around this, but it's not simple. In short, you would need to:
Launch your second process (you could, for instance, use a Process.Start())
Use the first process to look inside the ROT (Running Objects Table) and locate the second assembly
Communicate freely via COM (OLE) and pass your data
At this point, the two assemblies are running in separate runtimes, which will allow you to produce forms in the second assembly that will not close when the first assembly closes. That, as I understand it, is what you're looking for.
If you want to try this route, do a little Googling for the ROT and try some sample code. If you have questions about that let me know!

How do I generate keystrokes in a non-form application

So I have a huge program and decided I should make one of the methods run in a separate thread. So I put the method in a separate class, an activated it on my form. It seemed to worked just how I wanted it to until it got to part where it gave me this error:
SendKeys cannot run inside this application because the application
is not handling Windows messages. Either change the application to
handle messages, or use the SendKeys.SendWait method.
I tried looking for the answer online. I think I saw something about how SendKeys only works in a Form or something.
Can anyone tell me a way to simulate a keystroke without using SendKeys, OR a way to get SendKeys to work in a different, non-form thread?
Your console application needs a message loop. This is done through the Application class. You will need to call Application.Run(ApplicationContext).
class MyApplicationContext : ApplicationContext
{
[STAThread]
static void Main(string[] args)
{
// Create the MyApplicationContext, that derives from ApplicationContext,
// that manages when the application should exit.
MyApplicationContext context = new MyApplicationContext();
// Run the application with the specific context. It will exit when
// the task completes and calls Exit().
Application.Run(context);
}
Task backgroundTask;
// This is the constructor of the ApplicationContext, we do not want to
// block here.
private MyApplicationContext()
{
backgroundTask = Task.Factory.StartNew(BackgroundTask);
backgroundTask.ContinueWith(TaskComplete);
}
// This will allow the Application.Run(context) in the main function to
// unblock.
private void TaskComplete(Task src)
{
this.ExitThread();
}
//Perform your actual work here.
private void BackgroundTask()
{
//Stuff
SendKeys.Send("{RIGHT}");
//More stuff here
}
}
I Know this not an answer, but this how i used to do using ActiveX and Script
Set ws = CreateObject("WScript.Shell")
str = "Hi there... ~ Dont click your mouse while i am typing." & _
" ~~This is a send key example, using which you can send your keystrokes"
ws.Run("notepad.exe")
WScript.Sleep(1000)
For c=1 To Len(str)
WScript.Sleep(100) 'Increase the value for longer delay
ws.SendKeys Mid(str,c,1)
Next
Save this code as file.vbs and double click to execute in windows machine.

How to check Condition for executing Application through Shell propmt using C#

I have an application that can be run using GUI and Non-GUI environment. In order to execute with non-GUI environment I need to check condition for "Executing the Application using Shellprompt"(so that GUI should not pop up). I need to check the condition for executing if the application is using shellprompt. How can I specify or check the above condition? Thanks in advance.
Regards,
Arasu.
Hi usually we pass some command line parameters to enable "batch mode" of the application when we run it from the console, also because the normal use case is to have it running via Windows Scheduled task.
Said so, inside the main method you can check the command line parameters and in case your keyword (aka "batch") was specified instead of loading the main form you run your UI less procedures.
so if I understand correctly you are currently able to specify the app should start up on command prompt from a setting in the UI, but you want to be able to specify it should start up on command prompt from the command prompt? you can use the args in the main method of your app for that, just as you would pass args to a comon command line app. like so (from Program.cs):
namespace WindowsFormsApplication1
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
if (args != null && args.Contains("-nogui"))
{
// start command shell app version
}
else
{
// start UI app version
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
}
I may have misread your question so if my answer is not of help to you.. maybe you'll find this answer helpful instead.

How to make it so if one copy of a program is running another won't be able to open?

How to make it so if one copy of a program is running another won't be able to open?
Or better yet, how to make it so that if one copy is already running, then trying to run another copy will just act as if you maximized the original process?
Scott Hanselman wrote a post on doing this sort of thing
This article
True Single instance application - WinForms.NET
explains how to create a true single instance:
This article simply explains how you
can create a windows application with
control on the number of its instances
or run only single instance. This is
very typical need of a business
application. There are already lots of
other possible solutions to control
this.
e.g. Checking the process list with
the name of our application. But this
methods don't seems to be a good
approach to follow as everything is
decided just on the basis on the
application name which may or may not
be unique all across.
using System;
using Microsoft.VisualBasic.ApplicationServices;
namespace Owf
{
public class SingleInstanceController
: WindowsFormsApplicationBase
{
public SingleInstanceController()
{
// Set whether the application is single instance
this.IsSingleInstance = true;
this.StartupNextInstance += new
StartupNextInstanceEventHandler(this_StartupNextInstance);
}
void this_StartupNextInstance(object sender,
StartupNextInstanceEventArgs e)
{
// Here you get the control when any other instance is
// invoked apart from the first one.
// You have args here in e.CommandLine.
// You custom code which should be run on other instances
}
protected override void OnCreateMainForm()
{
// Instantiate your main application form
this.MainForm = new Form1();
}
}
}
Change you main function this way:
[STAThread]
static void Main()
{
string[] args = Environment.GetCommand
SingleInstanceController controller = new SingleInstanceController();
controller.Run(args);
}
Your best option is to use a named mutex. These articles explain the design pretty well and provide all the necessary code:
http://sanity-free.org/143/csharp_dotnet_single_instance_application.html
http://iridescence.no/post/CreatingaSingleInstanceApplicationinC.aspx
Extending this to maximise the main window of the running application should be a simple alteration to either of the examples provided.
You can use Mutex to make your app singleton. There are plenty of examples how to do it.
The Microsoft.VisualBasic.dll assembly contains a class 'WinformsFormsApplicationBase' which contains some functionality like the thing you want.
You can use this class in a C# application as well.
Just create a class which inherits from this class.
Set the SingleInstance property to true and override the necessary methods.
Offcourse, this means that you have a reference to the VisualBasic.dll assembly, which could be seen as a disadvantage, but, I think it is by far the most simple and easiest solution.
More info can be found here

Categories

Resources