I have a form in a Pocket PC app that is set to be the Application form using:
Application.Run(New frmMain())
Somehow this form is getting closed for no reason while working on another form. No closing event is fired and nowhere in my code can you close the main form anyway. It is only closed by clicking the OK button at the top right of the window. When this is clicked, the user is prompted if he/she really wants to close the application. However, this is not occurring either.
Basically, I am on another form which adds a new record to the database. After adding the record the gotFocus event is somehow called for frmMain. When the code in the gotFocus event reaches a reference to a control on the form, there is an exception that states that the object is disposed.
When I bypass the code in the gotFocus event, the application just closes completely. I verify this by checking that it is not running in the device's memory.
I have been stepping through code for 2 hours and I have absolutely no idea why this could be occurring. Anyone possibly have a tip?
This sounds as an exception being raised anywhere. Maybe an exception on another thread? Look at the output window to see what it says.
Related
We have a huge application that runs through a mass of code for every click you do. In one specific case, where you have a specific control in plain sight (so that the events are firing) and you load some special data into it and then click on the new button the form loses some events, like the closing event (you cannot close the form anymore and stop points in debug mode are not triggered) and one validating of a ComboBox that is really needed for the program. The only thing you can do when you get this kind of error is to restart the application to get out of this subform. But I tested it for 2 days now and even when I activate all points in the 'Exception Settings' I don't get any exceptions. The form (and other controls) are not losing ALL events. The resize, for example, still works. Even a specifically called AddHandler is not firing. Can you iterate somehow through the EventHandlerList? Or is there any way to test WHERE the event dies? Somehow any ideas on how to debug such a problem?
I'm using vb.net 2013, and I have configured Shutdown mode to "When last form is closed".
On my main form, I have a menu item which has this code to close the application:
Application.Exit
Everything is working fine, except one case:
When I open a specific form, where a Combobox is created on runtime and I've used Addhandler to subscribe to several events.
The combobox is created when pressing a button.
When I open this form and I don't create the combobox, everything is working ok. If the combobox is created, when I close this form and try to close the application using the menu item, nothing happens. The application is not closed and no error message is displayed. (the same situation occurs when I try to close the main form with "x" button)
On the form's (where I have the combobox) close event , I tried to put a line of code:
MyCombobox.dispose()
But the situation is the same.
What can I do? Thank you!
What I do from my little experience is
1.) remove the MyCombobox from its parent control (I'm think this is in your combobox close event).
2.) set the MyCombobox to Nothing
3.) Dispose() it.
MyCombobox = Nothing
MyCombobox.Dispose()
It would be useful to see some part of your code for the close event so we can help you check. More power to you!
Update based on OP's comment:
I have read the following from MSDN: https://msdn.microsoft.com/en-us/library/system.windows.forms.form.closing(v=vs.110).aspx
From this, it is important to note that:
The Form.Closed and Form.Closing events are not raised when the Application.Exit method is called to exit your application. If you have validation code in either of these events that must be executed, you should call the Form.Close method for each open form individually before calling the Exit method.
In the program I'm writing, there is just one form. I've made a user control visible and it contains several buttons. One of the buttons is supposed to close the form when clicked. I can't find any way to do this without getting the error: "Cannot access a disposed object. Object name: 'ShapeContainer.'" I'm pretty sure I understand the problem; after the form has been closed, the user control no longer exists, so there's an error when Form.Close() (I've tried Form.Dispose() too) has completed and it tries to go back to the code inside the button click event. Does anyone know how I could accomplish closing the form through this user control's button without getting the error?
Okay I'm pretty new to vb but I think if you get rid of the Form.Dispose() & Form.Close then try Me.Close() as you are referring to the current Form that the button control is located on.
You Should have got this error:
(Error 1 'NameSpace_.Form1' cannot refer to itself through its default instance; use 'Me' instead.)
I've inherited some VB.net code. My task is to find out why it isn't working. I have 2 applications. The first one
is run as a service, infinitely checking a table to see if there are any tasks to be handled. If it finds one, its supposed to fire off the second application to handle the task then returns to the loop and checks for another. Both these applications are forms but they do not show any windows. The problem I'm having is after the second application is finished, the first application never gets a signal it is done so it is waiting forever, thus it can't move onto the next task. If I go into TaskManager and kill the second application, the first one gets that notification and proceeds as it should. Below is how I am creating the process and waiting for it. I've tried several different ways of creating and waiting for the process (using a Shell/OpenProcess, WaitForSingleObject,etc) and I can't get it to work. I've searched all over the internet, StackOverflow and the MSDN site but nothing I've tried works. I've been messing with this for 2 days!!
Form 1 Load:
Dim ProcessProperties As New ProcessStartInfo
ProcessProperties.FileName = strExeFullPath
ProcessProperties.Arguments = " /project " & l_project
ProcessProperties.CreateNoWindow = True
Dim myProcess As Process = Process.Start(ProcessProperties)
myProcess.WaitForExit()
When Form2 is finished, it does a Me.Close() and Exit Sub in the load subroutine but the process is still showing in the TaskManager and never returns to Form1 so Form1 is in WaitForExit forever. I've tried closing every open file and connection and setting them to Nothing in Form2, Me.Dispose,etc. I've tried Application.Exit as the last line of Form2. That stupid thing will not die!! Why won't it DIE!!??!!
What am I missing?
If I go into TaskManager and kill the second application, the first one gets that notification
Keep your eyes on the ball, the real problem is that this second application is not exiting by itself. And thus myProcess.WaitForExit() isn't going to return. So this is not a problem in your code snippet.
Why the 2nd app doesn't want to quit is completely unclear from your question. Given that it is a Windows Forms app, do keep in mind that there is nobody to click the Close button of the form. Application.Exit() should make it stop, Environment.Exit() is a rude abort that cannot be veto-ed by a FormClosing event handler.
Anyway use this:
ProcessProperties.Arguments = String.Format("/project {0}", 1_project)
No leading space is required and code becomes more readable.
Cheers!
I suspect Form2 is trying to show some modal dialog (maybe a message box, maybe an unhandled exception box) before quitting. Since App2 is launched by App1, which is a service, Form2 cannot interact with the desktop and just sits there waiting for a button click that will never happen.
Try to allow the App1 service to interact with the desktop (you can find that option on the Log On tab of the service properties dialog box) and check if Form2 actually pops up a dialog before quitting.
I have a DataGridView control in my Windows Forms Application.
I am adding rows to the grid using a background thread. I change the form's cursor to Waitcursor when the process starts and back to Default when it ends. This works well for the form, but not for the grid. When the form's cursor is changed back to default, the grid's cursor does not change, although the cursor over the rest of the form does.
Does this have anything to do with the fact that I am updating the grid from a background thread? (The cursor is being changed from the UI thread directly).
Edit: The background process raises an event, the handler checks the InvokeRequired property of the grid and decides if it needs to "Invoke" the method again from the main thread. So, in effect the actual UI update happens from the appropriate thread. I am not sure if this means that I am "using a background thread" or not. :|
I've had some problems doing single thread updating of my datagrids, where the datagrid did not reset to normal cursor after i've had waitcursor to true.
What I did was right after i went
this.UseWaitCursor = false;
I added
DatagridviewFoo.Cursor = this.Cursor;
Maybe it's just the same problem for you
I've had this problem as well. It was difficult to track down the cause, let alone a solution.
This issue only ever happened when I had a dialog box over the DGV control and the mouse clicked on a button to close the box such that when the box closed, the mouse was over a (resizable) column border. If the cursor ended up over a cell, the problem didn't arise. If I had to guess, I'd say the grid was seeing a column resize event as soon as the dialog box closed which wasn't properly handled.
Using Cursor.Current = Cursors.Default fixed my issue (without the need to explicitly reset the control's cursor). But maybe be aware that Application.UseWaitCursor = False didn't work even with the explicit control cursor reset.
I had a similar problem, but neither of the posted solutions worked for me. Mine was not caused by clicking a button above a movable column separator. It just randomly happened after opening and closing a dialog box. I'm pretty sure it came down to timing because .Net/Windows has issues when it comes to setting cursors and actually having them take effect. To try to overcome that, the library we use for showing and hiding the wait cursor calls - ack! - Application.DoEvents. I set a breakpoint in OnCursorChanged and saw that the cursor was sometimes actually getting set on a latter call to Application.DoEvents (used to keep the UI responsive while waiting for the file system to release a write lock on a file). So I guess sometimes the default cursor was getting turned back on before the call to set the wait cursor had fully taken effect. Anyway, my brute-force approach is to call
Cursor = Cursors.Default;
in my override of OnCellEnter (which always happens after the grid gets refreshed following the dialog box being closed). I'm not particularly proud of this, but it seems to work.