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?
Related
I am currently working on a LabVIEW project and have found myself stuck on how to make a while loop exit when I press the abort (stop) button. For a simple while loop I understand how to do this - but the problem is that this while loop is nested inside of an event structure and I'm guessing that the button cannot be pressed while the loop is executing. Attached here is a picture of part of my code (that contains this specific event case which is causing me problems): To spend a little more time explaining what the problem is - I think the code is doing what I want it to do (namely output a set of commands in a repeated cycle with a wait timer) but I cannot stop the code mid cycle (pressing the abort button with my mouse does nothing - as in the button doesn't show it being pressed and the indicator shows no change, I also can't use any other functionality of my program during the cycle which I'm assuming is related). And I do not want to stop the LabVIEW program from running entirely - just the code inside the while loop pictured above. This is what the front panel is configured too for completeness:
Essentially what I want to happen is the while loop to execute when I press DWG and in the middle of the cycle be able to abort it. Sorry if my code seems a little messy. Additionally, I've tried the same code with a for loop originally (via a conditional terminal so it could stop early) and that didn't work either. Thanks for any help I appreciate it!
Your problem is that inside the event structure, by default the UI is frozen so no UI actions (keyboard/mouse/etc) are processed until you exit that frame.
Option 1. You can right click the Event Structure and select "Edit events handled by this case" dialog and then uncheck the "Lock panel" checkbox -- that will allow the UI to be live while you are in that frame. I do not recommend this solution generally unless you have an extremely simple user interface because it leads to the user being able to change controls without the events behind those controls being processed (not a good UI experience for users). But if the UI is simple enough, that works.
Option 2. You can create a user event that is the code you want inside your While Loop. When the Deg Wait Go button is pressed, use the "Generate User Event" node to trigger that event. Do the same thing in the user event case so that the event re-triggers itself if and only if the Abort button has not been pressed.
Option 3. Create a separate loop OUTSIDE your UI loop that does your processing with some sort of command queue running between the UI loop and that other loop. The other loop moves into various states at the request of the UI loop... it's the one that does nothing until it receives a "go" message and then keeps looping until it receives a "stop" message. You can Google "queued message handler" for extensive details of this solution. This is the most common solution for complex UI requirements, especially useful for separating concerns of the UI code from the execution code.
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.
All,
I have a TabControl in an application that started behaving strangely. Some background...
This program was converted from VB6 to VB .NET 2008, and used to refer to forms using their class names. In other words, I might have a form class called frmFoo. In the code for the program you might see:
frmFoo.Show()
or
frmFoo.UserDefinedProperty = True
During some recent changes, I created variables to represent instances of my forms much like these:
Public MyForm as frmFoo
MyForm = New frmFoo
MyForm.Show()
In doing so, I also removed code from the form's Load event handler and put it in the form's constructor.
When the form loads, or when a document is loaded and should influence the TabControl's selected index, something like the following will not necessarily fire the SelectedIndexChanged event.
MyForm.tbsForm.SelectedIndex = ValueReadFromFile
...or...
MyForm.tbsForm.Tabs(ValueReadFromFile).Select
Sorry to be so wordy, but there's more. If I open the form and look at the TabControl to verify that it's been set properly, everything works like it's supposed to. The misbehaving TabControl is contained within another TabControl, so I have to click the parent TabControl to see it. If I can see it, and run a test, the test always works. If I can't see it, and run a test, the first test I run will not fire the event. ...paging Dr. Heisenberg...
It's almost as if the control has to be initialized first by changing the value or making it visible onscreen...I'm totally lost on this one. It's the most unusual behavior I've ever seen. And everything worked perfectly before I began using variables to represent forms and placed the Load event code into the form constructors.
Can anyone help, or at least put me out of my misery?
SH
-------------------------------------------------------------- Edit #2
I just performed a test after having attempted to eliminate some of the variability in the behavior. But I wanted to confirm the previously-stated behavior.
I opened the program and read a file. This file contained a value that should have triggered the event handler. Without making the control visible, I can change the SelectedIndex property of the tab control without the event firing.
I closed the program down again, and reopened it. This time, selected the parent tab that allowed the child tab (the one whose event I'm concerned with) to become visible. I then selected a different tab in the parent control, meaning that the child control was no longer visible. When I opened the same file as before, it fired the event.
I'm tempted to implement a flag that confirms that the control has been repainted or whether the parent tab has been displayed. I may have to fire the event in code if the flag isn't set.
I want to reiterate that everything worked when the program referred to the forms by their class names and much of the arrangement of controls on the forms was done in the load event. Now the program creates variables and the arrangement of the controls is done in the form's constructor. I'm sure this has something to do with the problem I'm having, but I can't understand how. Any wisdom to share?
MyForm.tbsForm.SelectedIndexChanged = ValueReadFromFile
doesn't make a lot of sense. Is tha trying to assign a handler to the SelectedIndexChanged event? or is ValueReadFromFile the name of the tab?
What you're saying is that you have two tab controls, say, A and B. Tab control B is contained within a tab of A, and unless A has the tab page selected that contains the tab control B, the SelectedIndexChanged event of B will not fire if you change its tab programatically?
In which different ways have you tried to select a tab within the child tab control, and when is this code being executed?
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.
We have a question regarding VB.Net 2008.
We are used control array in vb.net and third party timer controls.
When handle received from external application to timer control event procedure,
after this form becomes blank and controls disappear.
What we have to do to persist the controls.
You asked what you have to do to persist the controls. It's not clear whether you mean winforms or webforms, but I can answer for both possibilities:
If it's the former, you have it backwards. The default behavior of all controls is that they are "persisted" until you tell them otherwise. If anything disappears, it's because you have code somewhere that tells it to. That's where you need to start looking.
If it's webforms/ASP.Net, the problem is that you don't understand the page lifecycle. Everything that raises server events, including your third party timer controls, causes a post back. That's how events work - the browser posts the form back to the same url in such a way that the server knows to call a your event code at the right time. The thing here is that as far your server is concerned, it's still just a new http request, and that means you're working with a brand new instance of your page class every time this happens. If you've previously added some controls to your page, it doesn't matter. That was an old instance that was discarded and probably disposed by the time the page was visible in the user's browser. If you want to keep those controls, you need to make sure you add them to the page on every postback.