Sending command to showDialogue Form from inactive form - c#

I want to send keys to a show dialogue form from another inactive form.See the picture
Form a is showing dialogue.Behind is another form which has a customized keyboard and numpad.
I simply send keys against these button clicks.
How is it possible that I can send keys from keyboard to show dialogue form.

What you're asking is essentially impossible. Once you understand how modal dialogs work (forms that are shown using the ShowDialog method are modal), you will understand why. A modal dialog is used when you want to force the user to interact only with that dialog. It prevents them from interacting with any other windows in your application by disabling those windows. They become impervious to mouse clicks, don't receive keyboard input, and can't receive the focus. Windows beeps at you and flashes the title bar of the modal dialog when you try, it's non-subtle way of shaking its head and saying "no, no, no".
So what's going on here is that when you show your "Deposits" form as a modal dialog using the ShowDialog method, all of the other windows in your application are disabled. In your particular case, that means the window that contains your on-screen keyboard is disabled, too, and can't receive mouse click events. That's why nothing is happening when you try to click on its "keys" (buttons).
The easiest workaround (as I suggested in a comment) is to show your "Deposits" form as a non-modal dialog using the Show method instead. Unlike a modal dialog, this will not disable other windows in your application, allowing the user to interact with all of them at once. Clicking on another window will set focus to that window and allow it to process input events. But you say this isn't workable for you, because you want the "Deposits" form to disable every control on your main window, but not your on-screen keyboard.
Of course, I lied at the beginning when I said it was "impossible". What I meant is that is that it's very tricky, and will require you to work around the standard Windows interactivity model. A couple of ideas
on how you might go about doing that spring to mind:
You could use the On-Screen Keyboard utility that is included with all recent versions of Windows. Microsoft already provides a program for this purpose. You don't have to build and maintain your own, it already includes all the necessary logic to prevent it from stealing the focus when the user clicks on one of its "keys", and since it isn't part of your program, it won't be disabled when you show forms as modal using the ShowDialog method. To check it out, go to Start -> Run and type osk.
For example, in Windows 7 it looks something like this:
If you insist on using your own, custom-designed on-screen keyboard, you will have to show it as a child window of your modal dialog. That is, your application starts with its main form, per usual. Then, when you show the "Deposits" form as a modal dialog using the ShowDialog method, the main form gets disabled. From the "Deposits" form, you can then show the on-screen keyboard form using the non-modal Show method. The main form is still disabled, because it's showing a modal dialog (the "Deposits" form). But the "Deposits" form is not disabled, because it's showing a non-modal dialog (your on-screen keyboard).

Related

Disable minimize, maximize and close buttons of parent window when a modal dialog is shown on a WPF parent

I have a WPF parent window that opens a modal dialog with the ShowDialog method when a button is clicked on the view. The parent window is blocked as expected until interaction with the pop-up ends, but the minimize, maximize and close buttons on the parent view are still available and clickable. Do you know if it is possible to disable them and if yes, how?
I also noticed that if my parent window is WinForms it works like this, only for WPF remain these 3 buttons clickable.
Note: the default behavior in WPF already provides this. Our library code was overwriting it. Issue has been solved since.

Is there a way to keep all windows in focus within a Windows Forms application?

I have an application that some times requires the user to have two forms open at a time. I have the main 'home' form window, but also a calculator form window. It isn't a normal calculator so I would like the calculator to stay within the one application.
When filling out the main form, the calculator is needed to work out some data to input. Only problem is, when calculator.ShowDialog() is used, the main form loses focus. The calculator is opened to the right of the main window. So ideally, I would have which ever window is clicked, gain focus.
Just use form.Show() instead of ShowDialog
Me thinks that you can add Code line calculator.Activate();

Enable events in main windows while modal window is active

In a WPF window I implemented a component that gives an indication of all active errors in the system.
The component is located in the task bar and
If one hovers over the component a tool-tip is shown with summary info
If one clicks on the control, a panel is the activated that is showing a detailed list.
In the application we also use wizards implemented as modal windows.
Now, here's my problem: if a new event occurs in the system during an active wizard, the component in the task bar is updated however I cannot use the hover event to see a summary. Both events (hover and click) are not usable due to the modal dialog that hides the parents message loop.
Is their a way (or what's the best solution/suggestion) to have at least the hover message active while the modal wizard is present.
Thanks.
They don't call it "modal" for nothin' :-)
Humor aside, depending on your exact scenario, here's two options and a third option that's a bit more involved and you probably don't need it but it can handle a wider range of scenarios:
Option 1. It sounds like you have a normal app that does not show its MainWindow and is using only its taskbar presence. If this is the case then you don't need a dialog at all, simply use the MainWindow itself as the "dialog".
Option 2. If you are already using the MainWindow visibly then use a pseudo-modal approach whereby you don't actually use a dialog but all other controls except the control acting as your "dialog" control are hidden/collapsed.
Option 3. Use two separate processes. Basically, this is two separate apps - one is your taskbar component and the other is your main app. Use IPC to link the two - e.g. I have used a Windows pipe for such a thing and it works fine.

Read-only Outlook window via Win32

I have window handle for my Outlook Inspector window. Basically, it's still window, and I want it to behave like modal, i.e to not respond until I'll release control. I can't use Form.Showdialog() in this case, because it freezes whole application, but I need Outlook resources for other purposes.
Update: I found EnableWindow() function in user32.dll, but it disables whole application, like modal dialog boxes do. Is there possibility to disable only child window, but not parent?

Is there a way to auto-hide a always-on-top modeless dialog when the parent opens a modal dialog?

My C# Winforms app has an always-on-top modeless find dialog. Since the user has access to the parent window while the modeless find dialog is open they can choose to open a modal dialog as well. Since the modeless dialog is always-on-top it obscures the modal dialog, but it is not possible for the user to close the modeless dialog at this point since the modal dialog locks out user interaction to all other windows.
Currently I'm working around this by manually adding code to close the modeless find dialog before opening any modal window, I'm wondering if there is a better solution?
How about making the modeless dialog not-always-on-top before invoking modal dialogs, then restoring it?
modeless.TopMost = false;
// show modal dialog here
modeless.TopMost = true;
Does the find dialog need to be always on top? If the purpose just is to have it floating above the main form, isn't it sufficiant to set the main form as parent to the find dialog? Then it will always be in front without have to be always-on-top.
Otherwise I'd make the find dialog listen to what happens in the app and take steps accordingly. (This can be solved in numerous ways, from events to a commong base form for all forms in the app to a CBT-hook that listens system-wide for window activation/deactivation.)

Categories