ThreadPool.QueueUserWorkItem new Form CreateHandle Deadlock - winforms

I have a thread that needs to create a popup Window.
I start the thread using ThreadPool.QueueUserWorkItem(new WaitCallback(CreatePopupinThread))
Thew thread creats a new form. The application freases in the new Form constructor at CreateHandle. The Worker Thread is locked...
How can I fix this?
this is how I create the form
var form = new ConfirmationForm
{
Text = entry.Caption,
Label = entry.Text,
};
In the constructor the thread enters a deadlock
public ConfirmationForm()
{
InitializeComponent();
}

I think it would be better to create the "popup window" on the UI thread and then create a thread in the "popup window" to process what you want it to do.
As I suspected, you canĀ“t show a form created on a non ui thread.
See this answer: Possible to construct form on background thread, then display on UI thread

I have fixed the problem...
The deadlock whas triggered because the tread start whas done in a Form Activated Event... I have moved it to a Shown event and now it works ok...

Related

Progressbar for a wpf to load a page

I have two wpf windows in my wpf application.
1) When i click on the load button it loads the second Window. The secong window takes 15 to 20 secs to load.
How do i add a progress bar to show a loading window and when the second window loads close the progress bar.
I was recently working on a loading window for my app where you click the app and it takes about 10s to load. I have a loading window with an intermediate loading bar. The key was to put the loading window in a different thread to enable the animation to run while it was loading the other window on the main thread. The problem was to make sure we do stuff propertly (like when we close we close the window should stop the thread... etc).
In the code below... LoadingWindow is a small window with a progress bar on it, SecondWindow would be the window that is slow to load.
public void OnLoad()
{
Dispatcher threadDispacher = null;
Thread thread = new Thread((ThreadStart)delegate
{
threadDispacher = Dispatcher.CurrentDispatcher;
SynchronizationContext.SetSynchronizationContext(new DispatcherSynchronizationContext(threadDispacher));
loadingWindow = new LoadingWindow();
loadingWindow.Closed += (s, ev) => threadDispacher.BeginInvokeShutdown(DispatcherPriority.Background);
loadingWindow.Show();
System.Windows.Threading.Dispatcher.Run();
});
thread.SetApartmentState(ApartmentState.STA);
thread.IsBackground = true;
thread.Start();
// Load your second window here on the normal thread
SecondWindow secondWindow = new SecondWindow();
// Presumably a slow loading task
secondWindow.Show();
if (threadDispacher != null)
{
threadDispacher.BeginInvoke(new Action(delegate
{
loadingWindow.Close();
}));
}
}
There are many ways you can accomplish that. An easy way would be to create a third window or panel with the progress bar or a waiting animation. That third window is in charge of loading your second window and get displayed as soon as you click the load button on the first window. When loading of the second window is completed, the third window with the progress bar closes and the second window gets displayed.
hope this helps.
You could use the BusyIndicator as part of the WPF extended toolkit. You can download it here: http://wpftoolkit.codeplex.com/wikipage?title=BusyIndicator
On immediate loading of the new window before you do your expensive processing that takes forever, you can set the IsBusy to true. When processing is done, set IsBusy back to false. This method involves wrapping your XAML in the BusyIndicator in the 2nd window, which may or may not be what you want.

updating UI in windows phone 7

In method that is working in the background, i have two important lines :
createPopup();
MessageBox.Show(sth);
more lines
more lines
createPopup() just creates a popup, adds a grid as a child and shows popup.
My question is, why first shows up messageBox, then shows up Popup, which appears after all lines in this method done ? How could I make this popup to show before all lines in this method will be done ?
All the UI changes are normally queued up and will be shown at once on the screen.
And this does not include MessageBox. So it shows up immediately and prevents the execution, until user clicks on Ok. Hence eventhough your popUP is first executed, it will be shown in the UI only after the MessageBox.
For your problem, Try placing your MessageBox.Show(something) in a separate thread.
createPopup();
Dispatcher.BeginInvoke(() =>
{
MessageBox.Show("some message");
});
more lines
more lines
Give it a try. I am not sure whether it solves your problem or not as I dnt know the code in createPopUp() method.
Creating the pop-up, does not actually draw it on the screen until the Layout event. If you want to ensure that the pop-up has been drawn before you display the pop-up, attach an event handler to the pop-up's LayoutUpdated event and display the message box from within that event handler. Be sure to detach the event handler as well or you will see multiple message boxes.
public InitPage()
{
Popup popup = new Popup();
popup.LayoutUpdated += popup_LayoutUpdated;
LayoutRoot.Controls.Add(popup);
}
void popup_LayoutUpdated(object sender, object e)
{
popup_LayoutUpdated -= popup_LayoutUpdated;
MessageBox.Show("hello");
}

When Modal Dialog is shown in WPF and a user clicks on the parent window, make the modal dialog flash, blink or shake

New Thought, Maybe I am looking at this totally incorrectly. So Here is exactly what I am trying to do in case there is another option I am not aware of.
I have a WPF app, the main window shows a smaller dialog window using ShowDialog(), when a user clicks on the parent window that showed the dialog, I need to make the dialog window, flash, shake or blink.
AresAvatar posted a link that looks like it might be able to use, but is there another option I am not aware of?
My original Question.
Mouse click event when Modal window's parent is clicked in WPF app?
I have a wpf app that shows a modal window using ShowDialog().
I would like to fire an event when the user tries to click the parent window that is now disabled.
Is it possible on the parent to receive a click event when it has shown a modal window?
When I attempted this using an interaction trigger, the events never fired on parent window.
Otherwise, what suggestions / options are there.
Thanks
No WPF events are sent under these conditions. The only Windows message I can see that gets sent is WM_WINDOWPOSCHANGING. You could check for that message, and check if the window was disabled when it occurred. Here's a good article on checking WM_WINDOWPOSCHANGING.
Edit: that link seems to be dead. Here's an example on StackOverflow of checking window messages.
I know this is an old question but I'll post my solution in case any one needs it.
Set the dialog.owner prior to calling ShowDialog().
var dialog = new DialogWindow();
dialog.owner = MainWindow;
dialog.ShowDialog();
The result is that clicking on the main window, brings the dialog window to the front and makes the dialog window flash.

Status Message during function call (WPF, Multithreadin)

I have one "CleanUp" button on my WPF UI.By clicking on this button, I"ll call some C++ wrapper function to do some calculation.The calculation will take some time.
What I want exactly:
1. During calculation, I want to show some message like "Clean-Up is going on" besides one node of TreeView (TreeView is present on same UI.
Any help would be appreciated........
You can try by using a BackgroundWorker.
Just set a new background worker and set it's dowork event to your "wrapper function to do some calculation" ;-)
After that you can trigger the reportprogress event to set a new state or message while it's executing.

How can I make a 'Partially' modal dialog?

Is there a way to start off showing a dialog modally, but then instead of hiding it, to keep it visible while changing it to a non-modal dialog?
I want to show a dialog, blocking the method that shows the dialog. Then when the user clicks the 'Finish' button on the dialog I want:
The dialog to remain visible.
Control to return to the method that showed the dialog.
I've achieved this result by running the dialog on a separate STA thread, and using an event to block the main UI thread until 'Finish' is pressed, but there's a catch to this method: you can click on the close button of the 'main' window while the dialog is visible, and the main window closes when the dialog is hidden.
Update
Thanks for the responses so far. Sorry - it looks like I got the balance wrong between too much background and not enough.
The form is effectively a modal 'wizard' dialog - it appears, sits in front of the main app modally, and then is hidden. So as far as the user's concerned there's no non-standard weirdness going on. The only difference is that the dialog is driven from a series of callbacks from the UI thread, so I don't think making it truly modal (via a call to ShowDialog) for its lifetime would work. The first callback must show the dialog, and then block while the user sets their preferences via the dialog UI. After that, the dialog stays visible and displays a progress bar page while various other callbacks are made from the UI thread. Eventually the form is hidden. The user isn't interacting with the main window while the form is up. As far as they're concerned, it should appear to be 100% modal wrt the main UI thread.
(The form is a dialog for a Visual Studio wizard - these are driven from a series of callbacks on the UI thread). An alternative would be to show the dialog, hide it, immediately show a topmost 'progress' form instead and then hide that, but I think showing a single dialog is more seamless an experience for the user.
Again - sorry for the confusion!
Perhaps you want to rethink your interaction model? How are you going to explain this to your users? They have an internalized model of how computer programs work, and you better have a very good reason to break that. They know about modal dialogs, they know about non-modal dialogs, they know about inspectors. Choose one, and apply it.
Modal dialogs are made for short-time interaction. They should not block exiting the application. The user is in control of the interaction, the program only provides the minimum of restrictions needed.
[after the explanation, replaced]
What's wrong with showing the progress bar in the modal dialog? Start processing once ok
is clicked, disabling all buttons, only keeping the cancel button active? If it takes a long time, the user might want to abort the action. Only close the dialog when you're finished processing.
You could use a modeless dialog then have your main UI check if the user has clicked the Finished button. If the modeless dialog is open but Finished hasn't been clicked then don't respond to any users actions in the main form...
This is just a terrible idea - it's completely non-standard behavior and you're going to jump through all kinds of hoops to get something working that is just going to horribly confuse your users.
Like most of the other answers here stated, you're implement non-standard UI elements that will be confusing to most users.
If the dialog remains visible just to provide read-only access to the data, then why not have dialog window close normally and open a side-bar window in your application with the data from the dialog window?
If the dialog remains visible to allow the users to continue making updates in it, then perhaps, it shouldn't be modal to begin with.
Point is, there's a couple different ways you can accomplish your task without breaking standard UI metaphors.
I'd make it a flyout from the side or bottom of your app that shoves other things out of the way. If it's on top of other stuff that the user might need to see or interact with then it's just gonna annoy them.
I found that showing an an invisible modal dialog on the main UI thread during the blocking stage of the interaction works great.
Hidden modal dialog settings (so it's not visible): ShowInTaskBar=false, FormBorderStyle=None, size={0,0}, Opacity=0%, StartupPosition=CenterParent.
The hidden dialog is shown on the UI thread using ShowDialog. The visible dialog is shown on a separate STA thread. The thread is kicked off before calling hiddenDialog.ShowDialog on the main UI thread.
The visible dialog hides hiddenDialog when it wants the initial blocking state to complete. This stops the main UI thread from blocking.
The important bits of code:
void LaunchWizardForm(s)
{
// Show the wizard on its own thread.
ThreadStart t = () =>
{
_wizard = new WizardForm(s);
Application.Run(new ApplicationContext(_wizard));
};
var thread = new Thread(t);
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
// Block this (main UI) thread
_hiddenForm.ShowDialog();
}
void EndModalEpisode()
{
_hiddenForm.Invoke((Action) (() => _hiddenForm.Hide()));
}

Resources