I've got a .Net windows form application where a lot of variables are initialized in the Main_Load event and I have a situation where I want my DB re-queried and all vars set to null and re-initialized (basically the form 100% reloaded from the start), but I wrote my Main-Load in such a way (my fault) that it's not that easy to do...
I know I could get exactly what I want by simply calling Application.Restart and it does the trick beautifully, but I'm not sure if this is good programming practice or considered really bad.
Are there any problems that I'm likely to run into by using Application.Restart in this context?
Not friendly to debug, but there's nothing really wrong with it. It is the exact same as terminating the app and starting it again.
You can avoid it by simply creating a new instance of your main form and closing the old one. That however does require you to prevent the program from exiting. Code is here.
It's not that the method doesn't work; rather, many times programmers forget that they've put something in their code that would stop the application from automatically shutting down, or starting up.
Please follow this Thread
You can also do the job with
System.Diagnostics.Process.Start(Application.ExecutablePath);
Application.Exit();
To directly answer the question in the title, yes restarting an application to re-initialize variables is bad practice.
There are cases where restarting an application is usefull (in example self-update), but restarting to mimic a ReInitialize() method is bad in my opinion.
I had problems with this.
I really needed to restart a large Winforms Application, when a user logs off, to ensure all cached (my) data are purged.
Solved my problem by adding the Application.restart() into the Application Shutdown Event.
This works inside the VS environment and when running the EXE
If you want to find that event select your main project properties and from the Application (Side Tab) select View Application Events at the bottom.
My guess is that this works because it is very late on in the closing process. Hope this helps someone and, more importantly, it continues to work.
Related
I know this is a hot discussed topic with many questions and answers but I still do not find the solution for the following problem:
I have a multi-tab application. On every tab is a Webbrowser control.
As the webbrowsers take more an more memory for every new tab and they do not free this memory on tab-close, I decided to make a Webbrowser.Dispose() in the tab close event handler. This helped me concerning the memory leak. all the used RAM is now free after closing.
But this caused a new problem: After the first Dispose() it seems that the session is destroyed for all other Webbrowser objects.
Normally I only login in to the frist webbrowser. If I a add several tabs I am normally logged in automatically. After the first Dispose() this does not work anymore and I have to login on every new Tab.
I tried to keep the old cookies and send them again with the new webbrowser but this did not solve the problem. The seems to be destroyed.
This seems to be a GarbageCollector-Problem. You can try to use the dirty way of System.GC.Collect(), just calling the GarbageCollector to free memory, but this is not a good way to solve the problem.
Of what you told, this seems to be a Pointer-problem.
If you declared the Connection as a global variable, you have to detach the connection from the tab befor you can close/dispose the tab itselve. The event Me.Closing shuld help you to do so.
If the Pointer stays open, the tab as an object is still connected on the Connection and will (not realy shure if/when) not get cleaned by the GC.
If you can clarify your way of duplicating/referencing the connection, I could give a more detailed answer.
EDIT: after a while of research my worries became true - there is a problem with caching under IE (>5 as far as I know). http://social.msdn.microsoft.com/Forums/ie/en-US/88c21427-e765-46e8-833d-6021ef79e0c8/memory-leak-in-ie-webbrowser-control
Suggestions are:
calling GarbageCollector manually
limit MemUsage (can result in application-crashes and also just writes the pages to disk)
about:blanc to override cache-entries
calling C++ methods to override the cache (WinINet - all I have found resulted in some ProtectedMemory-Errors - maybe this C# WebBrowser control: Clearing cache without clearing cookies works)
using C++ and WinINet (I don't know any real .Net implementation and it may also have this memory leak)
using alternatives to IE like gecko (Mozilla) - https://bitbucket.org/geckofx/
All WebBrowser instances share the session on per-process basis. According to EricLaw's answer to a similar question, it appears to be impossible to separate sessions. I'd trust Eric's statement as he worked as IE program manager at Microsoft.
If however you'd still like to try some hacks, you may look at CoInternetGetSession. First, try saving and holding on to the returned reference to IInternetSession. Further, you could look at registering your own URL namespace (RegisterNameSpace) and implementing a pluggable protocol handler which may eventually allow to overrule this restriction.
Of course, it sounds like an overkill and most likely won't help at all. A clean solution might be to redesign the logic to get rid of cookies and pass the state via URLs.
EDITED: Another idea, try to navigate the WebBrowser instance to (say) "about:blank" and wait for DocumentComplete event, before actually disposing of it with Dispose().
Thanks for your answers. Here what I checked out:
Calling GC manually:
Does only help if I use Webbrowser.Dispose() in before.
But this is not a solution because of the session problem.
Limit Mem Usage:
Not a solution. This program should run a whole day with many opening and closing of tabs. If I can not clean the used memory, the memory usage will be too much after some hours..
about:blank:
I called about:blank on Closing the Tab. After DocumentLoaded occurs for this URL I disposed the Webbrowser. Same procedure as calling Dispose directly. Session breaks down.
Other components:
I need to have an IE control in every case because the (proprietary) internet application only supports IE 8 and higher.
"Using c++ and WinInet":
Can I use the C++ Browser in my .net program? I can not switch the whole program to C++. This wouldn't be a solution for me.
In summary:
My application works fine without Dispose but has the problem with the increasing memory usage. If we could find a solution for this (which seems to be impossible) it would be the best solution.
The only thing what would be an acceptable "workaround" for me is to reuse the "closed" webbrowsers. In detail: On every tab close I add the Webbrowser to a List instead of Dispose them. When I need a new tab I take the first out of the list an reuse it and Navigate to the new URL: I tried it out but it seems there is the same problem with the sessions. The sessions in the reused tabs seems to be new again. But I really do not understand why... An suggestions for this, too?
Another workaround would be to force every Webbrowser object to be a single instance. Is this possible?
First, what I need is - n WebBrowser-s, each in its own window doing its own job. The user should be able to see them all, or just one of them (or none), and to execute commands on each one. There is a main form, without a browser, this one contains control panel for my application.
The key feautre is, each browser logs on to secured web page and it needs to stay logged in as long as possible. Well, I've done it, but I'm afraid something is wrong with my approach.
The question is:
Is code below valid, or rather a nasty hack which can cause problems:
internal class SessionList : List<Session> {
public SessionList(Server main) {
MyRecords.ForEach(record => {
var st = new System.Threading.Thread((data) => {
var s = new Session(main, data as MyRecord);
this.Add(s);
Application.Run(s);
Application.ExitThread();
});
st.SetApartmentState(System.Threading.ApartmentState.STA);
st.Start(record);
});
}
// some other uninteresting methods here...
}
What's going on here? Session inherits from Form, so it creates a form, puts WebBrowser into it, and has methods to operate on websites. WebBrowser requires to be run in STA thread, so we provide one for each browser. The most interesting part of it is Application.Run(s). It makes the newly created forms alive and interactive. The next Application.ExitThread() is called after browser window is closed and its controls disposed. Main application stays alive to perform the rest of the cleanup job.
When user select "Exit" or "Shutdown" option - first the browser threads are ended, so Application.ExitThread() is called. It all works, but everywhere I can read about "main GUI thread" - and here - I've created many GUI threads. I handle communication between main form and my new forms (sessions) with thread-safe methods using Invoke(). It all works, so is it right or is it wrong?
Is everything right with using Application.Run() more than once in one application? :) An ugly hack or a normal practice? This code dies if I start a WebBrowser from the session form thread. It beats me why. It works however if I start WebBrowser (by changing its Url property) from any other thread. I'd like to know more what is really happening in such application. But most of all - I'd like to know if my idea of "applications in application" is OK.
I'm not sure what exactly does Application.Run() do. Without it forms created in new threads were dead unresponsive. How is it possible I can call Application.Run() many times? It seems to do exactly what it should, but it seems a little undocumented feature to me. I'm almost sure, that the crashes are caused by WebBrowser component itself (since it's not completely "managed" and "native"). But maybe it's something else.
Is everything right with using Application.Run() more than once in one application? :) An ugly hack or a normal practice?
Some of both ;) This is perfectly acceptable, in that it will function as you are expecting, but it's not exactly a "normal practice."
I'm not sure what exactly does Application.Run() do.
Application.Run basically does a couple of things. First, it installs the property SynchronizationContext into the thread for Windows Forms to run properly. It then starts the windows message processing in that thread, which processes all messages from Windows going into the thread. This is what allows forms to work properly.
There's nothing particularly wrong with doing this, but it isn't a standard practice. Given your design goals, I do question whether this would be better served by just launching a separate process instead of trying to run each operation within a separate thread.
I have put some code inside of the public MainWindow() {} but I kept getting some obscure XAML parsing errors as soon as I did that (not on my computer but on 3 others I've tried it on - yep!)
Is there the preferred way to run code AS SOON as t he application starts?
The theory is I want it to call home and ask it it's ok to start. If it's not, I want the app to close out. Call it a makeshift copy-protection :)
Under normal circumstances, WPF creates the Main method (the entrypoint of the application) for you. Your options
Create a handler for the Application.Startup event and put your code there. Alternatively, you can override the OnStartup() method.
If that's too late for you, put your code in the App's parameterless constructor (it probably doesn't exist, but you can create it).
If even that's too late, you can create your own Main() method. There are several ways how to do that. Probably the easiest is to put it in another class and tell Visual Studio you want to use this method in the project's properties.
On the other hand, you said you're getting some obscure XAML parsing errors. Maybe you should figure out what exactly do they mean?
You have Window.Loaded event in WPF.
But if if you want to check for run permission before application loads ( due some resource consuption or some business strategy) use a bootstrapper a separate small executable that first launched by mainexe and after if everything ok a bootstrapper runs main exe
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.
I have a windows form application which needs to be the TopMost. I've set my form to be the TopMost and my application works as I'd like it to except for in one case.
There is a 3rd party application (referred to as player.exe) that displays SWF movie files on a portion of the screen that popup on top of my application.
Using Process Monitor I determined that player.exe application calls
flash.exe <PositionX> <PositionY> <Width> <Height> <MovieFile>
in my case:
flash.exe 901 96 379 261 somemovie.swf
Since flash.exe is being spawned in a new process after my form has been set to the TopMost it is appearing on top of my application.
First thing I did was make my application minimize the player.exe main application window hoping that this would prevent the Flash from appearing also. But, unfortunately it doesn't... even with the window minimized whenever the flash movie starts it shows up at the pixel location (901,96). I then tried creating a timer to keep setting the form.TopMost property to true every 10ms. This sort of works but you still see a very quick blip of the swf file.
Is there some type of Windows API call which can be used to temporarily prevent player.exe from spawning child processes which are visible? I admit it sounds a little far fetched. But, curious if anyone else has had a similar problem.
Addendum:
This addendum is to provide a reply to some of the suggestions layed out in Mathew's post below.
For the emergency situation described in the comments, I would look at possible solutions along these lines:
1) How does the third party application normally get started and
stopped? Am I permitted to close it
the same way? If it is a service, the
Service Control Manager can stop it.
If it is a regular application,
sending an escape keystroke (with
SendInput() perhaps) or WM_CLOSE
message to its main window may work.
Easiest way to close the app is to CTRL-ALT-DEL, then kill process. -OR-
The proper way is to Hold ESC while clicking the left mouse button... then input your username and password, navigate some menu's to stop the player.
There is no PAUSE command... believe it or not.
I don't think using WM_CLOSE will help since minimizing the application doesn't. Would that kill the process also? If not, how do you reopen it.
2) If I can't close it nicely, am I permitted to kill it? If so,
TerminateProcess() should work.
I can't kill the process for two reasons. 1) Upon relaunch you need to supply username/password credentials... There may be a way to get around this since it doesn't prompt when the machine is rebooted but... 2) Whenever I kill the process in task manager it doesn't die gracefully and asks if you want to send an error report.
3) If I absolutely have to leave the other process running, I would try
to see if I can programmatically
invoke fast user switching to take me
to a different session (in which there
will be no competing topmost windows).
I don't know where in the API to start
with this one. (Peter Ruderman
suggests SwitchDesktop() for this
purpose in his answer.)
I got really excited by this idea... I found this article on CodeProject which provides a lot of the API Wrapper methods. I stopped implementing it because I think that in order for desktop's to work you must have explorer.exe running (which I do not).
EDIT2: On second thought... maybe explorer.exe isn't needed. I'll give it a try and report back.
Edit3: Was unable to get the code in that article working. Will have to put this on hold for a moment.
Answer Summary
As one might have expected, there is no simple answer to this problem. The best solution would be to problematically switch to a different desktop when you need to guarantee nothing will appear over it. I was unable to find a simple C# implementation of desktop switching that worked and I had a looming doubt that I would just be opening a whole new set of worms once it was implemented. Therefore, I decided not to implement the desktop switching. I did find a C++ Implementation that works well. Please post working C# virtual desktop implementations for others.
Setting the TopMost property (or adding the WS_EX_TOPMOST style to a window) does not make it unique in the system. Any number of topmost windows may be created by any number of applications; the only guarantee is that all topmost windows will be drawn 'above' all non-topmost windows. If there are two or more topmost windows, the Z-order still applies. From your description, I suspect that flash.exe is also creating a topmost window.
Aside from periodically forcing your window to the top of the Z-order, I think there is little you can do. Be warned, however, that this approach is dangerous: if two or more windows are simultaneously trying to force themselves to the top of the Z-order, the result will be a flickering mess that the user will likely have to use the task manager to escape.
I recommend that your program not attempt to meddle with other processes on the computer (unless that is its explicit purpose, e.g. a task manager clone). The computer belongs to the user, and he may not value your program more highly than all others.
Addendum:
For the emergency situation described in the comments, I would look at possible solutions along these lines:
How does the third party application normally get started and stopped? Am I permitted to close it the same way? If it is a service, the Service Control Manager can stop it. If it is a regular application, sending an escape keystroke (with SendInput() perhaps) or WM_CLOSE message to its main window may work.
If I can't close it nicely, am I permitted to kill it? If so, TerminateProcess() should work.
If I absolutely have to leave the other process running, I would try to see if I can programmatically invoke fast user switching to take me to a different session (in which there will be no competing topmost windows). I don't know where in the API to start with this one. (Peter Ruderman suggests SwitchDesktop() for this purpose in his answer.)
You can use the Process class to start flash.exe directly - and use an appropriate ProcessStartInfo settings to show the window in a hidden state - or with a WindowStyle of hidden or minimized.
You could also consider using the SetWindowsHookEx API to intercept the process start API calls, and when the process is flash.exe run some code to restore you window to top-most status.
Matthew's answer is excellent, but I suspect you may be asking the wrong question. Why does your application need to be topmost? If you're trying to create a kiosk or some such, then topmost is not the way to go.
Edit: After reading your response to Matthew's comment, I'd suggest creating a new desktop and switching to it before displaying your alert. (See CreateDesktop and SwitchDesktop in MSDN.)