# .NET and More > WPF, WCF, WF >  [RESOLVED] BusyWindow is not draging with MainWindow if I drag and drop MainWindow

## Kram Kramer

MainWindow xaml codes are here;

MainWindow vb codes are here;

BusyWindow xaml codes are here;

BusyWindow vb.net codes are here;


My question is here;

----------


## jmcilhinney

At a glance, I'm not seeing anything in your code that would make the two windows stay in sync.  Why exactly do you think they should?

----------


## Kram Kramer

> At a glance, I'm not seeing anything in your code that would make the two windows stay in sync.  Why exactly do you think they should?




```
myBusyWindow.Owner = Application.Current.MainWindow
```

----------


## jmcilhinney

You appear to be under a misapprehension about what that Owner property does.  The documentation for that property, which you should have read well before posting about this topic, has this to say:



> Once this relationship is established, the following behaviors are exhibited: 
> If an owner window is minimized, all its owned windows are minimized as well. 
> If an owned window is minimized, its owner is not minimized. 
> If an owner window is maximized, both the owner window and its owned windows are restored. 
> An owner window can never cover an owned window. 
> Owned windows that were not opened using ShowDialog are not modal. The user can still interact with the owner window. 
> If you close an owner window, its owned windows are also closed. 
> If an owned window was opened by its owner window using Show, and the owner window is closed, the owned window's Closing event is not raised.


There's nothing there about the owned window moving with the owner or vice versa.  If you want that behaviour then you would have to code it yourself.  That would mean the owned window handling the appropriate event of the owner and then positioning itself relative top that owner.  I've done that before rather simply in Windows Forms and I would expect it to be fairly similar, although not identical, in WPF.

----------


## Kram Kramer

Hi jmcilhinney, 

Please click following link and read the #17th post.

----------


## jmcilhinney

I'm not really sure what you're asking or implying.  If you don't want the user to be able to interact with the calling window while the other window is showing then you should call ShowDialog.  I'm not sure why you were told otherwise but that's how it works.  You call Show if you want to be able to interact with either window and ShowDialog if you want to interact only with the second window.  The point of an owned window or modeless dialogue is to create a tool window sort of thing.  A classic example is the Find & Replace window in VS.

----------


## si_the_geek

Please do not edit posts (unless it is just a couple of minutes after you first posted it), because it causes confusion and/or annoyance.  It is better to post a new reply instead.

It also makes things harder if you split your question over multiple threads like this, because it means that all of us who are trying to help you (even if we don't reply) have to go around looking for all of the relevant information - instead of it being in one place.    

In this case you should have just replied to this thread, because this question is not the same as the one at the start of the other thread (so it doesn't belong there).

To save others the effort, here is the other post:



> Originally Posted by techgnome
> 
> 
> In the button click event, create an instance of the wait form, show it (not as a dialog though)
> 
> 
> 
> Our code is still wrong...
> 
> ...


Using .ShowDialog might be the wrong way to go in this case, because it means only that window can run code (the window that called it can't do anything).

If you don't want users to interact with a window, you can set Enabled to false (but it has been a while since I used WPF, so it may be a different property name).

----------


## Kram Kramer

If I change techgnome's code from 

```
myBusyWindow.Show()
```

 to 

```
myBusyWindow.ShowDialog()
```

 then the code sticks on the this line 

```
myBusyWindow.ShowDialog()
```

----------


## Kram Kramer

> Using .ShowDialog might be the wrong way to go in this case, because it means only that window can run code (the window that called it can't do anything).
> 
> If you don't want users to interact with a window, you can set Enabled to false (but it has been a while since I used WPF, so it may be a different property name).


I think using .ShowDialog is correct way as youtube video does.

To make MainWindow.IsEnable = False is not good idea because nobody is doing this...

----------


## jmcilhinney

I would suggest that the most appropriate way to go here is to have the waiting window accept a delegate and have it invoke that on a secondary thread.  The main window would create the waiting window, pass it the delegate and then display it by calling ShowDialog.

----------


## Kram Kramer

> A classic example is the Find & Replace window in VS.


You can interact with MainWindow during Find & Replace window is open as it should be.

But BusyWindow is different thing. The user should not interact with MainWindow during BusyWindow is open.

----------


## jmcilhinney

Here's a quick example I just threw together in WinForms.  The code in the waiting window can look something like this:

vb.net Code:
Public Class Form2     Private ReadOnly method As [Delegate]    Private ReadOnly args As Object()     Public Sub New(method As [Delegate], ParamArray args As Object())        ' This call is required by the designer.        InitializeComponent()         ' Add any initialization after the InitializeComponent() call.          Me.method = method        Me.args = args    End Sub     Private Async Sub Form2_Shown(sender As Object, e As EventArgs) Handles MyBase.Shown        Await Task.Run(Sub() method.DynamicInvoke(args))         Close()    End Sub End Class
The form requires a delegate and optionally accepts arguments too.  Immediately after it's displayed, the form invokes that delegate asynchronously and awaits it's completion.  Because the delegate is invoked within a Task that is awaited, the UI is does not freeze while the delegated method is being executed.  Once the method completes then the Task also completes and execution continues and the form closes itself.  The calling window can look something like this:

vb.net Code:
Imports System.Threading Public Class Form1     Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click        Using dlg As New Form2(New Action(Of Integer)(AddressOf DoSomeWork), 10)            dlg.ShowDialog()        End Using    End Sub     Private Sub DoSomeWork(seconds As Integer)        Thread.Sleep(1000 * seconds)    End Sub End Class
Wherever is appropriate - in this case, in the Click event handler of a Button - an instance of the waiting form is created and an appropriate delegate and corresponding arguments are passed to the constructor.  It could be any method you wanted with any arguments you wanted.  In this case, it's a method that takes a number of seconds and simply waits for that long, but you can do any work you like there.  You then call ShowDialog to display the waiting form, which invokes the specified method and then closes when it completes.  You can try that for yourself and see that the dialogue can be dragged around as much as you like but it will not allow access to the calling form.  You can do pretty much the exact same thing in WPF.

----------


## jmcilhinney

> You can interact with MainWindow during Find & Replace window is open as it should be.
> 
> But BusyWindow is different thing. The user should not interact with MainWindow during BusyWindow is open.


I know that.  That's what I'm telling you, i.e. that you should not be using an owned window in this case because owned windows don't provide the functionality that you want.  You never should have set that previous thread as Resolved because your issue wasn't resolved.  You've now asked a different, irrelevant question here and we've had to go back to the original issue.

----------


## Kram Kramer

Hi jmcilhinney,

Could you please post WPF code with BackgroundWorker if possible?
Because your WinForm code is very complicated for me...

----------


## jmcilhinney

I won't be posting any more code.  I've provided an example and I've explained the principle.  It's for you to adapt and apply to your own situation.

----------

