We Keep Coding

Showing a modeless form's 'title bar' inside the parent form when it's minimized

I'm trying to implement some complement views inside my application and I would like to have a better layout control over them. I don't know how to explain in words what my desired functionality is, so I made it through with some photoshop help, hoping you could give me a hand to implement it.
My application now looks like this:
(i need reputation to post images so.. sorry for the links)
http://i59.tinypic.com/2ikv8m1.jpg
When I minimize the modeless form which is focused in the previous image, I would like to be able to see it (and handle it to maximize or close) inside my main form as I show in the image below (made it in photoshop)
http://i58.tinypic.com/1e28go.jpg
Hope someone can lead my into a solution and thanks for the support.
EDIT: I need to be able to move that form outside my main form, even to a different monitor.

If you don't want to use the MDI approach, then set TopLevel of the modeless Form to false and add it to the main Forms Controls collection before showing it:
Form frm = new Form();
frm.TopLevel = false;
this.Controls.Add(frm);
frm.Show();
*Obviously changing Form to the correct type of your modeless form.

If i understand what you are trying to do, you want to minimize a certain form but still see it within your app (im assuming like Excel or Word)
You can do something similar to what Idle_Mind said, but enclose both in a Form instead of the parent.
Form fParent = new Form();
fParent.Dock = DockMode.Fill;//i think this is the syntax. Use this if you want the form to fill to the screen
Form fChild = new Form();
fChild.TopLevel = false;
fParent.Controls.Add(fChild);
fChild.Show();
Here, it should minimize to the lower left part of the parent form. You can then size the parent to whatever you want it to be.

WPF MessageBox not waiting for result [WPF NotifyIcon]

I am using WPF NotifyIcon to create a System Tray service. When I show a messagebox, it shows up for half a second and then disappears immediately without waiting for input.
This kind of situation has happened before, and the usual advice is to use an overload which accepts a Window parameter. However, being a System Tray service, there is no window to use as a parent, and null is not accepted in its place.
Is there any way to make the MessageBox wait for user input short of creating a custom MessageBox window myself?

You don't need to create a proxy window for this. Just add MessageBoxOptions.DefaultDesktopOnly to your message box and it will fire on your desktop without disappearing.
Example
MessageBox.Show("My Message", "Title", MessageBoxButton.OK,
MessageBoxImage.Information, MessageBoxResult.OK,
MessageBoxOptions.DefaultDesktopOnly);

According to the answer here, a workaround is to actually open an invisible window and use that as the parent of the MessageBox:
Window window = new Window()
{
Visibility = Visibility.Hidden,
// Just hiding the window is not sufficient, as it still temporarily pops up the first time. Therefore, make it transparent.
AllowsTransparency = true,
Background = System.Windows.Media.Brushes.Transparent,
WindowStyle = WindowStyle.None,
ShowInTaskbar = false
};
window.Show();
...then open the MessageBox with the appropriate parameter:
MessageBox.Show(window, "Titie", "Text");
...and don't forget to close the window when you're done (possibly on application exit):
window.close();
I tried this and it works well. It's undesirable to have to open an extra window, but it's better than making your own messagebox window just for the sake of making this work.

Custom dialog box in wpf issue

I'm calling my custom dialog window with this code:
GUI.SLDialog sd = new GUI.SLDialog();
if (sd.ShowDialog() == false)
{
return;
}
But sd.ShowDialog() always returns nothing (i think), because the function breaks, but the waypoint at return; isn't reached.
Dialog is automaticly closing when I add to button:
this.DialogResult = false;//or true
Anybody know what am I doing wrong?
Thanks in advance for your help.C.H.
#edit
This is my SLDialog:
xaml: http://wklej.org/hash/9fb67fb0c7c/
cs: http://wklej.org/hash/16e3ccc6c0d/

I don't think I can tell you much here unless you post the code for the dialog but I do have a suggestion in the mean time.
Since you're already unhappy with the standard dialog boxes and customization is clearly an option why not move towards what people are coming to expect? Instead of your standard dialog why not just create a user control that lays over the rest of your UI and blurs everything out from the background? Much like a jquery dialog box you might see on a web page.
Modality is easier to control since it's just a matter of covering your entire app window with a translucent rectangle and then make the dialog window appear however you want.
Just a suggestion.

RegisterHotKey not working with invisible forms (c#)

I'm trying to put an icon in the system tray and then give it a global keyboard shortcut to carry out a function.
I'm using RegisterHotKey to set the global keyboard shortcut, and it works if the main form associated with the icon is visible. But if the form is invisible then the WndProc method is never invoked.
Any ideas?
Edit:
What I mean by "hidden" is that the following is added to the main form:
protected override void OnLoad(EventArgs e)
{
hotKey = new GlobalHotkey(GlobalHotkey.WIN, Keys.T, this);
bool registered = hotKey.Register();
Visible = false;
ShowInTaskbar = false;
base.OnLoad(e);
}
"registered" is showing as "true", and the shortcut key works fine if I leave out the "Visible = false;" and the "ShowInTaskbar = false;".

The problem is that setting ShowInTaskbar to false changes the window handle, which means that the hwnd passed to RegisterHotkey is no longer valid.
Registering the hotkey after setting ShowInTaskBar works fine.

Winforms works around a pretty draconian restriction in the winapi. Some properties of a window can only be specified when a window is created and can't be changed later. Or in other words, they are specified in the native CreateWindowEx() call.
It works around it by calling CreateWindowEx() again. Or in other words, destroy the existing window and create it again. That's a nifty trick but it does have some side effects. You can see a wee bit of flicker for example when the new window paints itself. Some bigger side effects are visible on for example a TreeView. All the nodes collapse when it gets recreated. Hard to avoid, there is just too much state associated with the original window. For a Form, the ShowInTaskbar property is one such property. But also RightToLeft, FormBorderStyle, ControlBox, etcetera.
The most relevant side-effect is the one you are running into. Recreating the window always changes the Handle property, inevitably. And that goes wrong when you use RegisterHotKey(), or a library that uses it, that winapi call uses the window handle. So when Winforms destroys that window there will never again be a callback.
It is easy to fix, you are just using the wrong event handler. Make the call in an override for the OnHandleCreated method instead. It re-runs when the window gets re-created. Yet another easy fix, but not nearly as reliable, is to only set properties like ShowInTaskbar in the constructor.

WPF owner window on top of child window

Is it possible for Owner window in WPF be on top of Child window when you click on it while Owner window is below Child window?
here is example how I call child window:
Window2 window = new Window2();
window.Owner = this;
window.Show();
Parent/Owner window will always be under child window.

To get the behavior you want, you don't want to set the Owner on either window.
You, of course will have to handle the logic yourself when closing either of the windows to close your imaginary "child" window.
There may be some other logic you'll have to implement related to minimizing, maximizing, etc.

Many of the answers on this page involve nulling-out the Window.Owner property for some or all of the (non-MainWindow) windows in your System.Windows.Application. While this is a simple and easy fix that does indeed, in isolation, fix the issue of Window overlap, unfortunately it also inhibits a lot of useful application-wide functionality that WPF seems otherwise eager to provide in the areas of:
Application acti­vation/deactivation (via mouse-click, desktop Alt-Tab switching, etc...),
correct observance of the Application.​ShutdownMode property, and generally,
orderly cleanup, resource disposal, and exit of your Application upon shutdown.
It is possible fix the Window overlap issue while still preserving these system-wide WPF features by instead designating a special invisible window instance as your Application.MainWindow.
Modify your application so that the first Window it creates--which is the Window that gets assigned to Application.MainWindow--is a special dummy Window that is then made invisible by setting its Visibility to Visibility.Hidden or calling Window.Hide(). This will not hide its owned windows. Then, ensure that your desired "main" window containing your true content, plus all the other windows, owned by this invisible window.
Once hidden, the dummy Window will not show in the Windows 10 taskbar. You can set the Window.ShowInTaskbar property on whichever of the visible windows you deem appropriate to simulate apparent special designation, as required.
This approach allows any of the visible windows in your Application to be on top of the others, while still preserving WPF features and behaviors for system-wide app activation. For example, when the Application is activated (by clicking on any one of the windows, or via Alt-tab), all of the application's windows are together brought above any other desktop app windows, while still preserving the most recent "in-app" Z-order. WPF shutdown functionality is also preserved, including correct observation of the Application.ShutdownMode logic in accordance with the invisible MainWindow (or all the others) being closed.

I ran into a similar situation. I solved this by simply removing the owner after showing the window.
Window2 window = new Window2();
window.Owner = this;
window.Show();
window.Owner = null;
Edit:
Someone replied to this, and while looking at it, I decided I wanted to make an extension method.
public static void ShowAsIfChildOf(this Window childWindow, Window parentWindow)
{
childWindow.Owner = parentWindow;
childWindow.Show();
childWindow.Owner = null;
}

Please note that the solution mentioned by Licht
Window2 window = new Window2();
window.Owner = this;
window.Show();
window.Owner = null;
seems to me to be the same as
Window2 window = new Window2();
window.Show();
i.e., as if no ownership relationship has been set, i.e., when you close the owner window the owned windows do not close, etc., and may not be a solution when one would wish to have all of the ownership relationship features except "An owner window can never cover an owned window."
Once this relationship is established, the following behaviours 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.
The best solution here looks to me to be the one with hidden main dummy window described by Glenn Slayden, at the link below, though it would be nice if there was a simpler one.
https://stackoverflow.com/a/66110288/19683309

Don't set Owner for child window, then in MainWindow handle OnClosing event like this:
private void MainWindow_OnClosing(object? sender, CancelEventArgs e)
{
foreach (var window in Application.Current.Windows)
{
if (window is Window appWindow)
{
if(appWindow.Equals(Application.Current.MainWindow))
continue;
appWindow.Close();
}
}
}