There is one MessageDialog with text, that must be updated on timer (DispatcherTimer). Debugger shows, that on timer tick Content property is assigned, but visually there are no changes. Is there any tricky way to display new title?
MessageDialog blocks the UI thread until it's closed. So, you cannot change anything on the UI until it's closed. The only you can update it you need to call ShowAsync() method periodically in the tick event of the DispatchTimer. However, before closing the old message dialog, it won't work. Best way to achieve this, uou should implement your own message dialog as a user control.
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 have a Control say for ex a Submit button if user clicks the button twice or more continuously then user receiving same message / same operation taking place twice or more.
I need to avoid this situation.
thanks for your inputs.
You need to detect the button click event either in the code behind of the view (or ViewModel if using the MVVM pattern) and disable the button. Now I take it that your submit button is firing off some kind of asynchronous operation. Once the asynchronous operation has successfully completed you will probably need to enable the button so that it is available again.
Shankar, if you want to avoid clicking on button, you should disable it. If you can give more details about what exactly you are trying to do, more details can be given.
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.
I have an application that uses a NotifyIcon in the tray to hide/restore the application, as well as pop up notices to the user of application events. My application has a notification queue, and I use the NotificationIcon.BalloonTipClosed event to determine when to reset the balloon and show the next notification (if there's one in the queue).
This method seems to work great in both usual causes (user lets the balloon close itself when it times out, and user clicks "X" in balloon to force it to close), but there's a third case where BalloonTipClosed doesn't get called:
Notification balloon pops up
While it's visible, user right-clicks on notification icon to bring up context menu, causing the balloon to disappear
The BalloonTipClosed event doesn't get triggered in this instance - I figure it's a bug in the framework (I'm using 2.0), but does anybody have an idea around this? If I don't get this event, my application always thinks there's a balloon visible (I have a boolean that prevents it from displaying multiple balloons at once), and it will never show another icon again, as long as it's running.
This belongs as a comment to Aarons answer, but I am not allowed to comment yet.
If you handle the BalloonTipClicked and MouseClick events on the NotifyIcon (as well as the BalloonTipClosed) then you can capture all the ways the balloon can close. The only thing you have to be aware of is that several scenerios will trigger multiple events, so be sure to code around that (something like isClosed = true, and then reset that when a new balloon is displayed).
In the event handler for the BalloonTipClicked Event, I would check to see if the right mouse button was clicked, and if it was set the boolean to false.
Here's what I ended up doing, though I don't particularly like this solution. I added a second timer to the form and set it for 10 seconds. When a notification pops up (when I pop one), I start the timer, and then in BalloonTipClosed, I stop it. If the timer ticks (meaning that BalloonTipClosed hasn't run yet), I display the next tip manually.
The result is that if it hasn't fired yet, I take care of it. However, I'm open to better solutions if anybody has one.
I think this post from Raymond Chen about balloon notifications may help you:
http://blogs.msdn.com/oldnewthing/archive/2009/05/04/9585032.aspx
My mdi VB.Net application performs a long operation on some data. Ideally I should use a separate thread to prevent the dreaded “Not Responding” message.
My problem is if I use a separate thread users then have the ability to click on other controls in the application which can directly affect the operation my background thread is working on, creating an error.
Is there any way to prevent all the mdi windows, toolbars and other controls from receiving mouse clicks and keyboard input during my background thread’s operation?
Or is there a way to clear the message que before performing a Application.DoEvents?
Thanks
I would say that the best choice when you don't want a user to click on a control is to set Enabled to False for that control.
CLARIFICATION: Setting Enabled to False for a parent control will also disable any children. So, setting Enabled to False on the main window and and MDI windows, will do the trick.
There are a couple of ways of disabling the controls but I'm not sure it's what you want.
If you have a main window which is completely disabled while a background thread is processing then why go through the overhead of processing on the background? The advantage of processing on the background is to allow the user to still work with the application while you process data.
I think a better approach would be to take Dustin's route and selectively disable certain controls that can affect the background operation. Or make your background operation independent of the UI while it's processing.
If you tell us a little bit more about how your Main Window and Background thread interact we may be able to give you a better solution.
Hide all forms and only show the one main form. Then disable the Toolbar/Menu if you have either. Then have a status bar with a progress bar and when it gets done, unhide the form the user was working on.
When you are using a statusbar or a progress bar while your background thread is processing some longduring task, disabling your form will also disable your progress/status bar from updating. So what you should do in this case is disable every other control exept from the one that needs te be kept active (e.g. like a progressbar).
List<Control> lstControls = GetAllControls(this.Controls);
foreach (Control ctrl in lstControls)
{
if (ctrl.GetType().Name.ToLower().Contains("progressbar") {
ctrl.Enabled = true;
}
else
{
ctrl.Enabled = false;
}
}
Use a thread and display a modal dialog that shows the user the progress of your task and gives the user the option to cancel it.
The modal dialog will automatically prevent input (the parent may have to be the mdi window itself.)
(Please do not use hacks like hiding or disabling controls or windows. And please, please, please! do not use DoEvents.)