Im using some custom control in vb.net, where I have a boolean property that, whenever it changes, it starts a timer if it's value is false or stops if it's true.
If the timer runs for several seconds, it raises a messagebox that warns of a problem happening.
The problem is that this messagebox shows even in design time. As I have traced, the default value for the property is false when the control loads in the winform in design time, it seems it starts the timer and when it ends raises the messagebox, this happens whenever I open the project or rebuild it.
I don't get why this behaviour, as this should only happen at run time but it's driving me crazy, I have tried starting the timer directly when the property changes in the setter and creating "onpropertychanged" events, but this still happens in design time.
Anyone has an idea of how to get rid of this or how to solve it to avoid this of happening, is really disturbing that things happens when the program isn't even running.
Thanks in advance.
Regards
The common way is to use the DesignMode property of the control.
true if the Component is in design mode; otherwise, false.
So in your property, before starting the timer, first check if DesignMode is False.
Related
I have a usercontrol placed on a form at runtime.
I'm experiencing a UserControl_MouseLeave after FormClosing.
I'm wondering if this should happen under normal circumstances.
To test if this would occur normally as well (and not just in my huge project) I set up a test project with a tiny usercontrol (just having a certain backcolor), and I haven't been able to get the UserControl_MouseLeave event
after receiving the Form_Closing event.
This makes me wonder if my other usercontrol just takes really long to unload therefore doesn't go away right away and thus even stays alive after the FormClosing event.
Unfortunately I did not find any information about when the events can occur.
Does anybody know if this behaviour is normal?
Nothing is destroyed when the FormClosing event is fired so your observation about the disposing taking a long time might actually be correct.
When the form is closed, the WM_CLOSE method is called internally. Here's a flowchart of what happens:
Taken from MSDN article Closing the Window
In WM_CLOSE, the FormClosing event is raised in MDI children and all owned forms. Even after that, there's still a possibility to cancel the operation.
If we continue with the closing, the window is removed from the screen (but it still exists) Only after that, the WM_DESTROY message is sent to both the form itself and the child windows. MSDN states that:
During the processing of the message, it can be assumed that all child windows still exist.
If you have a very complex application that takes longer to dispose of, it's certainly possible that events are still fired after the FormClosing event and even if the form is not visible at that time.
It's also a possibility that there's something wrong with your code but without seeing it, this is what I think is the reason for the behaviour.
Edit: You can take a look at the insides of how the Form handles everything by checking out the Reference Source.
My event structure in the following part of my VI will work when I start up the program, but never again until I stop and restart. I figure I'm not doing something simple, can someone help?
The event structure is in a while loop. Again, it works once, but not after that...
You have set Enable Beeper Value change action. It will occur once you change the value of the button from the front panel, or change the value trough property node with signaling. Changing value using a local variable or property node value property will not cause Event Handler to register the event.
It seems to me your case structure is fine.
When you press "enable beeper" the event structure should execute the case you have shown and enter the case structure in the True frame.
When you press the button again, the event structure should be executed again this time processing the False frame of the case structure.
(I assume, since you have a local variable, that "enable beeper" is not latched).
If this is what you want to happen but not what's happening the issue could be somewhere else.
Is the Read from Visa function working properly? Could it be waiting for a reply from the hardware?
I'm writing a space invaders style game in Visual Basic for my HSC Software Design project. As part of that, I am using the following line of code to detect whether an enemy hit the player's ship.
If ship.Bounds.IntersectsWith(enemy(i).Bounds) And enemy(i).Visible = True And ship.Visible = True Then
This code is located within a For loop that runs for each enemy. I use that loop to move the enemies as well as check shots and stuff. This For loop runs within a Timer set to a 1 millisecond delay.
I am receiving a NullReferenceException error on this line, and it says Object reference not set to an instance of an object. I know that means one of either enemy(i) or ship isn't set to an object instance or something, because I've already closed the form. Here's the interesting bit:
Firstly, I received this error when this form wasn't even loaded. During the time the application was running, this form was never opened.
Secondly, even if it was running, it occurred quite a while after I stopped the timer with Timer2.Stop(). I checked through my code and there is no way possible that this code should try to execute.
I'm so confused right now, what is going on?
I have an application that searches in a database for some information.
Since the database is quite big, it sometimes takes a lot of time before the application returns the results to the interface.
I want to add some sort of spinning wheel to inform the user that the application is still searching the database and did not freeze. Once the results are returned, the wheel should disappear.
Any idea how to do this or is there a good tutorial explaining how to do this?
Have you considered changing the mouse pointer to the hourglass as this would be extremely simple to implement:
Me.Cursor = Cursors.WaitCursor
...Do your DB calls here...
Me.Cursor = Cursors.Default
However, I would agree that display a 'spinning wheel' is probably a little more user friendly and definately a lot more obvious. So, first get hold of an animated gif that suits your needs. Then create a form that has a picture box containing the image.
Once you have that you can show the form to the user and in the background do the DB work, once this has completed close the form.
Another alternative would be to use a rolling progress bar instead, so when it reaches 100% it cycles around again and keeps going until you close it.
EDIT:
One thing that I forgot to mention is that you will have to handle exception conditions. Lets say you set the cursor to wait, then an error occurs. The exception may bypass the code that resets everything. This leaves the user with a changed cursor and no means of changing it.
When I have done this kind of thing I have typically created a disposable WaitCursor class and then used something like this:
Using myWaitCursor As WaitCursor = New WaitCursor
...do something...
End Using
In the Dispose of the WaitCursor class you set the cursor back to default. The same would apply if you went down the route of using a form with an image or progress bar.
Find an animated gif of such a spinner, like this one. Put it in a PictureBox, set its Visible property to True when you start the job. Beware that you'll have to run the query in a worker thread to keep the animation alive and the user interface responsive. The BackgroundWorker class is good for that.
You could use the Environments Default wait cursor, which for Vista/7 is a circle with the outside spinning, or the XP tumbling hourglass.
You could launch your DB access on a BackgroundWorker and show an animated control such as a Marquee progress bar, or you could show a custom animation to show Busy status.
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.