I have a Windows forms application, and for some reason I'm getting an invocation error on application.run form1 why would this be? I have been scratching my head all day
namespace UserDataImport
{
class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
I'm getting a Target invocation error
start debugging the program, on the VS press Debug->Exception. that will open a window like this:
mark the "common Language Runtime Exceptions"
now when the exception is thrown you should have a nicer look at what went wrong. then add the code that went wrong
Related
My EnableVisualStyles() is not working anymore. I now get forms with a green line around it, it's horrible. How can I fix this? When I start a new project it's the same. I think about un-installing visual studio and reinstall it, but there should be a better way I think/hope. Does anyone know the solution?
PS I tried the Application.DoEvents() method, but this is not the answer for me.
an example of how my form looks now
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
I'm creating a Windows Forms application using Visual Studio 2012, C#, .NET 4.5; Windows 7.
I would like to handle any unhandled exception with my own error handler. I wrote some code like the own shown below. I even tried two different ways of error handling.
Now when I run this program within Visual Studio (2012), then this works very fine !
But when I start the program from explorer, then my error handler is never called; instead, there will always pop up the standard error handler from .NET Framework.
So what am I doing wrong?
static void Main()
{
try
{
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += new UnhandledExceptionEventHandler(HandleUnhandledException);
Application.Run(new frmMainFrame());
}
catch (Exception ex)
{
// Here is my error handler ....
}
}
static void HandleUnhandledException(object sender, UnhandledExceptionEventArgs args)
{
Exception ex = (Exception) args.ExceptionObject;
// Here is my error handler ....
}
Hook up Application.ThreadException as well.
Or set Application.SetUnhandledExceptionMode to UnhandledExceptionMode.ThrowException to have your appdomain handler kickin.
First at all i would use the Debugger.Break() Method to attach your program into to problematic code part. Than maybe just check if currentDomain is not null. Assumed that you don't raise a Exception that forces the CLI to stop.
I am trying to keep the (beta version of my) application running as much as possible,So I placed another try-catch inside Program.cs as well in cases where some critical errors occur and shut the application down unexpectedly.And in the catch i rewrote the Application.Run() method so that the application can resume itself after being terminated for what ever reason.
Is it right to have such a plan for this specific scenario?
If it is not right,Then what else is recommended in order to keep the program running?
This is the sample code demonstrating what i mean:
using System;
using System.Collections.Generic;
using System.Windows.Forms;
using Hossein;
using Pishro.Classes;
namespace Pishro
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
try
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new frmMain());
}
catch(Exception exc)
{
API.SaveAndShowLog(exc);
Application.Run(new frmMain());
}
}
}
}
Globally handling exceptions is a good idea for logging and alerting.
An automatic restart policy like yours can be useful, yes. There is a risk however: If the crash has corrupted global data-structures restarting the app can have unpredictable results like silent data corruption. For example, files might still be open and locked. Locks might not have been released. Static variables might be in an undefined state. Rogue threads might still be running, unaware that the application UI was destroyed.
I recommend that you restart the app by starting a new process of your application. Let the old process die.
I think your question involves a deeper question.. Should I catch all the exceptions?
To keep going you could catch them all.. but all those possible exceptions that you don't expect or not know are probably bugs.
Maybe you should try to implement better error handling approach within your app. So all the exceptions are known or expected.
Instead of wrapping a try catch around your application run method, consider handling the exceptions with events.
static void Main()
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
MessageBox.Show("Exception handled");
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
}
Mainly the thread exception is the one you want but ideally - you would want to set up some form of logging/flagging the error to the user and still dispose of the program because it may cause the program to continue in an unfit state. Please put a button on your form and in the click event throw new Exception(""); and then the message box should display.
I'm planning to host the service in windows service, but I'm thinking about the problem described in the title. Anyone had similar issue?
Thanks
Update
The problem is that when you throw an exception in WinForms/WPF/Win Service app, the program crashes and you'll have to restart it.
An exception does not always crash your server. Even an unexpected server-side exception will be transferred to the client. It is considered more severe than an expected one though, faulting the channel.
The basic idea is to include the expected exceptions (faults) in you interface contracts . There are many ways to do that, here is an introduction article.
And of course you need decent exception handling at the server.
A thing you can try is to intercept any exceptions by hooking to the ThreadException event in the Main method entry point of your Host application to check whether it is a FaultException.
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
// Hook to this event below
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
}
static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
if (e.Exception is FaultException)
return; // Bypass FaultExceptions;
else
throw e.Exception; // Throw otherwise
}
}
I can find many examples on how to get arguments in a console application, but I can't seem to find an example of how to get arguments in a windows form application.
I would like to following things.
whenever I open a jpg file, windows launches my application.
I would like to know path and name of the jpg file from my application.
How do i do that?
Environment.GetCommandLineArgs
Open up program.cs, on a file > new > winform project, you'll get
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
change this to
static class Program
{
[STAThread]
static void Main(string[] args)
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
Now its just like the console apps, you'd access them via args.
Even if you don't go with this option, you should be aware of how the win form app is initialized :) This way, you could run different forms or not run a form at all.