We Keep Coding

Odd behaviour when opening a WPF Window from WinForms

When displaying a WPF window from an Excel addin, I'm encountering odd behaviour whenever I show it with myWindow.Show() rather than myWindow.ShowDialog(). Thus far everything has worked fine when using the latter. However, it would be nice to be able to display a window such that the user can interact with Excel at the same time - i.e. the behaviour I'd expect from Show().
The problem is that controls in my form start acting very oddly quite quickly. ComboBox dropdowns collapse immediately, and textbox input ends up in whatever cell is selected in the Excel worksheet that's active.
I've noticed that with ShowDialog, Snoop is able to attach to my window as well, whereas with Show, I get an error amounting to "Could not find a PresentationSource to attach to". I'm not, however, completely sure if that's related.
Obviously one solution would be to stop directly showing a WPF window from WinForms; I expect the problem to largely go away if I change my window into a UserControl and chuck it into an ElementHost. However, I'd rather avoid that if I can.
Current code (roughly)
public void DoOpenWindow(Office.IRibbonControl button)
{
var myWindow = new myWindow();
// This hasn't addressed the issue, though may be sensible to include:
//ElementHost.EnableModelessKeyboardInterop(myWindow);
// This *also* didn't work, and essentially set my window to
// be always on top of Excel
//var hwSrc = HwndSource.FromVisual(myWindow );
//var ownerHelper = new WindowInteropHelper(myWindow );
//ownerHelper.Owner = (IntPtr)Globals.ThisAddIn.Application.Hwnd;
// with ShowDialog() this works fine...
myWindow .Show();
}
Current thoughts are:
I'm getting window messages from Excel forwarded to myWindow, some of which it isn't expecting.
Excel is intercepting messages meant for my window (keyboard and mouse), which is probably what ElementHost.EnableModelessKeyboardInterop(myWindow) is intended to solve (but either I'm using it wrong, or it's not the whole solution).

How to keep window visible at all times, but not force it to be on top

I'm creating a "desktop gadget" of sorts, I've disabled manual minimizing of the window, but now there is another problem: the system can still hide the window if the user presses Windows+D, for example.
When hidden that way, no usual minimize/resize/visibility events are fired.
I want to do something almost like TopMost, but without forcing the window order.
Maybe it's possible to install a global shortcut event using win32 API, and briefly set TopMost to true, but that sounds very hackish.
I found one solution, but it does not seem to work on Windows 10: Keeping window visible through "Show Desktop"/Win+D
The other common option, which would be writing an actual desktop gadget, is not possible on Windows 10, given their deprecation.
Are there any other methods to keep a window visible (but not on top of the screen) at all moments?

This function is working for me:
BOOL FixShowDesktop(HWND hWnd)
{
HWND hWndTmp = FindWindowEx(NULL, NULL, L"Progman", NULL);
if (hWndTmp)
{
hWndTmp = FindWindowEx(hWndTmp, NULL, L"SHELLDLL_DefView", NULL);
if (hWndTmp)
{
SetWindowLongPtr(hWnd, -8, (LONG_PTR)hWndTmp);
return TRUE;
}
}
return FALSE;
}
Note, this code is a bit better then from Keeping window visible through "Show Desktop"/Win+D because the window can be overflowed by other windows (like any other window). Using SetParent places window under all other windows.

Disabling Dialog Flashing C#

I have a populated ListView dialog. If a user clicks on an option in the ListView, a new dialog is shown above the ListView.
My problems is that when I click off of the new top-most dialog (onto the ListView behind it), the new dialog's borders flash/blink several times. The icon on the taskbar also flashes. I wish to disable the flashing, but cannot find a property to change.
To show my dialog, I use the following code:
if (detail == null)
detail = new Details(opt, val, user, desc, m_l);
else
detail = null;
detail.ShowDialog();

This is intended behavior, it's because the new dialog is modal. It's drawing attention to the fact that something needs to be done.
If you need to make a non-modal form, instead of using ShowDialog(), simply use Show().

Sounds like to me you are creating modal windows each time. And you cannot resume the previous dialogs until you dismiss your new top-most window.
Take a look at this wikipedia article for information about modal dialogs.
I would advise you look at how you are creating/showing your windows.
In WPF you show windows via Show() or ShowDialog(), however, I do not know which type of ListView you are using
EDIT:
Per your comment, you want modal dialogs. The only ways I can think of even trying to remove the flashing is going into WINAPI. This doesn't seem like a job for .NET.
I want to suggest a few things:
Take a look at options for showing each window. See this MSDN page
Take a look at the options for styling each window. See this MSDN page
Reconsider your design. I know this may take a lot of work, but having so many layers of windows is kind of unappealing to most users. Ultimately, I believe this option will make your application the best.

Thank you all for your answers and guidance. I have found the best way to handle my problem.
I was using an event ItemActivated. This event was called when an a highlighted item on the ListView was clicked. This became a problem when the user would double click on an already selected item. This would cause the new dialog to show, but also flash several times.
By using the DoubleClick event instead, a single click on a selected object does nothing. A double click on either a selected or non-selected item opens the dialog without the flashes. The flashes still appear if you try to click off of the dialog box, but are not as much of an issue.

Creating popup without possibility to tab to a background element

I am trying to create a popup but when it is open it is still possible to use the tab key to switch the focus to an element in the background (e.g. to a button and use space to press is). The only way I found until now is to check on every lostFocus event (which also fires for every element contained in the Border element) and check if the focus is now in a element inside the Border. If not I manually set the focus.
Is there a nicer way to keep the focus within the Border (or a Grid,...)
I'm working on a Windows 8 App.

Do you mean that using a Modal Dialog with Form.ShowDialog(Owner) still allows you to focus the parent components with Tab?
Can you give a sample of your code call?

Form2 form = new Form2(); //Make an instantiation of your Form
form.ShowDialog(); //ShowDialog()!!! NOT form.Show()!!! Or anything else :/

A few ideas:
Set Enabled to False on the background visual tree, though that might change the way things look if you still want to show them partly
Set IsHitTestVisible to False to disable pointer input
Use RenderTargetBitmap.Render() if targeting Windows 8.1 to render the content of the background to an image and simply replace all that visual tree with an image of it

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.