I have created an application in visual studio 2010 using C#.net.
In that application I am generating MS-Word report...
For that I have used SaveFileDialog for saving that documnet to a particular location..
Initally it was woking fine...But from some days my SaveFileDialog window is not getting opened on my system.
Same code is working on other machines without any problem.
Things I have done to fix this problem :
Uninstall VS 2010 and reinstall it.
Installed VS 2012
But that problem is still there.
P.S. I have Windows 7 O.S. 64-bit
Any help would be appreciated.
SaveFileDialog will only operate if it is used from a thread set to single-threaded-apartment.
Ensure that the thread you are using to display it is set to that mode.
If you are calling it from the Main() thread, ensure that Main() is marked with the [STAThread] attribute like this:
[STAThread]
private static void Main()
{
Related
I'm having an odd issue with Visual Studio Community 2015. My program runs correctly inside the Visual Studio Editor, and it also runs correctly when the Application .exe is double clicked in the bin/debug/ directory. However, when the Application is run anywhere else on the computer (including the Release directory) the program does not run correctly. I am definitely copying all of the Debug folder to the location of attempted execution so it's not because of that.
When I run the executable, a loading icon appears on the mouse, in Task Manager it appears as a process using about < 500K RAM and stays there until reboot. No window appears at all, and it is impossible to end the process once it has started, meaning it cannot be deleted.
I'm using .NET 4.5.2 primarily however I've tried 4.5 and 4.6 and neither fixed the issue (I've checked and I have all 3 of them installed). I also tried copying the System DLLs locally and that didn't fix the issue either. I also tried creating a minimalist solution (below) containing a project that only printed "Hello World" and quit.
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.ReadLine();
}
}
}
This program experienced the same issues except it couldn't even be run within the Debug folder, only within Visual Studio. I then changed the project so it opened, then closed again straight away without printing anything so that it didn't use the System libraries at all, and it did the same thing. I then tried running the program in both 64 and 32 bit forced, (on a 64 bit laptop) and that didn't make a difference either.
I'm using Windows 7 Home Premium - Visual Studio Community 2015
Thanks for any help :)
Another possibility for such a rare issue could be your Anti-Virus program. Some of them like to inject an DLL into each created process to better protect you. But this can also lead to such awkward problems.
The only other way that comes to my mind would be to check the Event Viewer or run Process Monitor to get an idea where the error comes from.
Try using the release configuration and enable Break on all exceptions (Check Managing Exceptions with the Debugger for help on enabling the VS exception handling).
Hopefully this will break visual studio and show you enough information on the exception.
You can also try using Process Monitor to find the issue.
I would highly recommend using a simple hello world program to find out the root cause. My suspicion is on some corrupt .NET framework installation
That's because it's not the proper exe...
In order to get a proper working .exe for you App Right Click on your project in Solution Explorer > Go to "publish" tab > select Publish Now
(Now go to debug folder and find exe)
It will automatically open the "publish" folder which has files for install, but NOW go to your "debug" folder and you will find the working exe there and some other Visual Studio generated files releated to publish that you don't really need
~ ChenChi
We have a WPF application built in Visual Studio built in system A. It runs out of VS on system A (as well as in VS, obviously). But when I take the .exe to a second system (B) and run it there it crashes before it comes up. It puts up the infamous message: "xxx has stopped working, Windows is checking for a solution to the problem". Of course, Windows never finds a solution. But it runs if I have Visual Studio running on system B (even though it's a new session with no connection whatsoever to the application). This has me scratching my head. I have already tried everything in this thread: Application crash without Visual Studio installed
I was absolutely sure the part about 'disable the option "Enable Visual Studio hosting process"' would solve the problem but it didn't. I have disabled that option in the project settings for all instances and it still crashes. Any ideas? Sorry if I can't share the code.
there can be lots of reason. first you have to check window Event Viewer, you will able to find actual reason.
also you should handle DispatcherUnhandledException="Application_DispatcherUnhandledException". this will show actual error.
in App.XAML :
DispatcherUnhandledException="Application_DispatcherUnhandledException"
and in App.cs:
private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
e.Handled = true;
}
I have program which execute on window XP and use microsoft reportViewer, all work fine and customers succeed print documents.
Where program run on Windows 7, when click on print button of control reportViewer do nothing. Expect show available printers in computers, but do nothing.
I think that problem relation on PrintDialog and property UseEXDialog = true, but in control not have option change that.
I compiled project in visual studio 2012, install windows reportviewer redistributable 2012 but problem not resolve.
Any idea to resolve problem.
Sorry for bad English.
The problem is resolved :)
When debug program see follow error:
System.Runtime.InteropServices.SEHException
Message: External component has thrown an exception.
Source: System.Windows.Forms
Target site: Int32 PrintDlgEx(PRINTDLGEX)
This error occurs only Windows7. When search in google found next description “you program have the [STAThread] attribute specified”.
Code which set thread apartment state to ApartmentState.STA work fine.
thread.SetApartmentState(ApartmentState.STA);
I will like to show the onscreen keyboard. As a result I went to the following link on stackoverflow:
Calling the on-screen keyboard using a button in C#
That technique works great when I am running my wpf application targeting the x64 platform. In other words it works when I set:
but if I set it to 86x it does not work. I need to run my application as x86 though. How can I solve this problem? I just have an exception when running my code on a x64 bit computer...
Edit
I have temporary solution. What I did to solve this problem was to create a new project in Visual Studio (Console app) and named FooApplication targeting the x64 bit version. That program looks like:
Class Program
{
static void Main()
{
System.Diagnostics.Process.Start("osk.exe");
}
}
then I am able to start the calculator my executing FooApplication.exe from my original wpf application.
I cann't make my application to apply Windows visual styles.
Application.EnableVisualStyles() in program.cs not changing RenderWithVisualStyle property to true.
[STAThread]
public static void Main(string[] startArgument)
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
.....
}
Interestingly if I'm debugging with "Enable visual studio hosting process", Application.EnableVisualStyles() works as expected, RenderWithVisualStyle goes to true and styles are applied. But no styles without hosting process either Debug or Release mode.
Changing target framework v.2 to v.3.5 makes nothing.
Any ideas please, I'm stuck with this issue and googling for 3 days with no success.
Many thanks
You need to embed a manifest XML file that specifies that the new version of the common controls DLL should be used. See the MSDN article on visual styles for more information on how to do this.