We Keep Coding

Having two active windows in a Winform application

Sorry, this more than likely has been asked at some point but I'm not even sure what I should be searching on...
I have a winform application with multiple forms. Up until this point having a one form open at a time has been fine. But now, I have a new form that I want to add on but have the ability to keep that form open while I work in other forms. I'm not even sure what this is called but I have seen it done before in other applications.
I did find this: Run two winform windows simultaneously
But this new window is a winpipe queue viewer that runs a thread. When I try initializing using the
Application.Run(new QueueViewer());
I get the error:Starting a second message loop on a single thread is not a valid operation. Use the Form.ShowDialog instead.
The problem with that is it locks the program from doing anything else until I close that form.
Thanks for your help!

Add a form to your project (let's call it Form2). Somewhere within your code (maybe in a button click event) use the following code:
Form2 f = new Form2();
f.Show();
The Show method allows you to interact with the originating form, whereas ShowDialog prevents interaction from the original form.

Show Form on applications main window

Two windows apps communicate through .net remoting. The host publishes an instance of a class that the client can call methods on through remoting.
The class has a method which pops up a form if not already visible, using form.Show() and performs some functions in a thread.
When the thread completes the form disappears even though I don't explicitely close it. The instance of the class does not go out of scope, and the class instance maintains a reference to the form.
I don't want the form to disappear and am thinking that if I use the Form.Show(System.Windows.Forms.IWin32Window) overload this would work if I pass the applcation main form to the Show method. The problem is my class instance knows nothing about the application. Is there any way to find the applications main form?
The form is being created and shown inside the thread.

Using Windows functions to make a window modal

I m using c# and I want to make a window a modal one and I want to use methods from Windows API for that.
The SetWindowPos function can make a window a top most one, but I couldn t find a way to make it modal...
Is there a way to do so with SetWindowPos or if not, is there any other windows function to do so?

Considering that your question is tagged c#, you have the entire .NET Framework at your disposal, which provides built-in functionality for displaying windows (forms) as modal dialogs. There's no reason you should have to call functions from the Windows API to do this.
In general, the only reason to P/Invoke functions from the Windows API is to use features that were not already exposed through managed code. The average application will have to do this only rarely, and basic use cases like showing a modal dialog certainly does not require it.
The way to do this in C# (or any .NET language) is to change the way you show the form in question. Instead of calling the Form.Show method, you should use the Form.ShowDialog method.
There are two overloads available. The first accepts no parameters and sets the owner of the dialog box to the currently active window. The second accepts a single parameter that specifies the window that will own this dialog.
The Form.Modal property provides a quick way of checking to see whether or not the form is displayed modally. As the documentation notes, however, it is read-only. The only way to display a form modally is to call the ShowDialog method, as discussed above.
As far as a Windows API solution, there isn't any such function that you can call. A window cannot be transformed into a modal dialog after it has been created. You have to display it that way initially. In a Win32 application, you do that by calling the DialogBox function (as opposed to CreateDialog).
MFC shows a modal dialog using the CDialog::DoModal function, but it doesn't truly show a modal dialog. Instead, it uses a hack to create a pseudo (or simulated) modal dialog that involves disabling the owner window, running its own message loop inside the DoModal method, and waiting for a pre-defined series of events that causes the modal loop to exit gracefully. I do not recommend doing this in your own application. It's simply not necessary, and it's too easy to get wrong. There are/were enough bugs in the MFC approach, and that team had the full knowledge of the Win32 internals at its disposal.
The ShowDialog method in WinForms works on a model very similar to that of MFC. Hans's answer here provides additional information. Do note that if you're going to implement your own modal dialog loop, you need to remember to re-enable the
owner window first, and then destroy the modal dialog. If you don't do this in the correct order, you'll end up with the wrong window having the focus. Microsoft's Raymond Chen posted a blog entry about this: The correct order for disabling and enabling windows.
EDIT: Added more information, based on comments from asker.
I'm not sure why you need the wrapper you've created to customize the save dialog to be a UserControl. It's not a control, the user isn't going to interact with it on your form. You're only going to show it from your code. Thus, I think the better option would be to create a new class, call it something like SaveDialogHelper, and expose a static method called ShowSaveDialog or something like that. For example:
public static class SaveDialogHelper
{
public string ShowSaveDialog(IWin32Window owner)
{
// Fill the OPENFILENAME struct, and do any necessary customizations
// ...
// Show the save dialog
// ...
// Return the path that was selected by the user
// ...
}
}
Notice that the ShowSaveDialog function accepts a single parameter (owner) of type IWin32Window, just like the ShowDialog method(s) in the .NET Framework. When you call that function, just specify the form that you want to own the dialog:
SaveDialogHelper.ShowSaveDialog(this);
And inside the function, you can extract the window handle (hwnd in Win32 terminology) using the Handle property, and set the hwndOwner member of the OPENFILENAME structure accordingly:
hwndOwner = owner.Handle;

You can't make it modal if it was not upon creation. But you can achieve similar effect by disabling its parent owner.

How to prevent the Form from opening Multiple Times

I have a application in which i have several forms. In that forms, I have a System Settings form. I have to open this form from the menu as well as a shortcut created on the desktop.
I am able to open the form from 2 places individually. But the problem is, It's opening two separate instance of the same form. it means, first, i have clicked on menu to open the form.Now my Form instance is created and it is displayed on the screen. But whenever i click on my desktop icon, It's creating another instance of the same form instead of displaying the same form. . So it means it's displaying two instances of the same form.
But i have display one form only. I have tried and googled in the net also. I didn't find any information.
Can anybody please help me to fix this issue. Any kind of suggestion will be really helpful to me.

You need a single instance. This construct is already available within the .Net framework. Just check out this post from Hanselman.
Note: I know that the namespace of this class is VisualBasic. But that shouldn't hinder you to use it in your C# application. It's just the name of a namespace. It doesn't meant anything about its functionality. (Microsoft had it better named Foo. In that case it would be much more popular.)

Sounds to me, that you need a mutex to control that only one application instance is running at a given time.
See http://iridescence.no/post/CreatingaSingleInstanceApplicationinC.aspx for further details

You have to implement some kind of locking mechanism to allow only one instance of your program running. I guess your System Settings program could check if other instances are running on computer on program launch, if so terminate, otherwise start a new instance.

To throw in one more link, this post seems to cover (my understanding of) what you are trying to do.
http://dotnetperls.com/single-instance-windows-form

I have used semaphor concept to control this. Whenever the form is opened i am writing an entry into registry. Once the form is closed i am removing this entry.
So, whenever i try to open the form, it will check the registry entry. Based on that it will open the form.

Sounds like you need a modified version of the Singleton design pattern. Try having a public static method within the class that internally calls the constructor for the form. Then as someone suggested use a counter variable to keep track of how may times that static method is called thus giving you a metric you can use to ensure only the desired number if instance are created.

C# - Possible to safely have an owned form in a separate thread?

I am attempting to write a specialized onscreen keyboard (OSK) for an application I'm writing in C#. To facilitate this, I've created a form which has several buttons on it representing keys, and clicking them calls SendKeys and sends out the appropriate keys.
This form is owned by the main window that is shown when the application first starts, using the Owner property. This way, the OSK pops up whenever the user focuses the application, and it stays on top of the main window if it said main window is dragged over it.
This all works great, but because I have modal dialogs that I also want to use with the OSK, I attempted to create it in a separate thread, complete with its own message loop (via Application.Run) so it could still be usable with any modal dialogs in the main thread.
The problem with this is that, obviously, being in a separate thread can cause InvalidOperationExceptions because of cross-threaded calls. One specific example of this is when calling Application.Run(osk) from the new thread, a cross thread error occurs because it is attempting to update the window's handle with the owner (the main window).
My question is, is it possible to have an owned form on a thread that is separate from the owner in a safe manner? And, if failing that, is it possible to emulate an owned form's characteristics (namely being Always On Top for only the main window, and popping up when the main window is focused)?
Thanks, and sorry if this is confusing.

I think this is actually a bug in Windows Forms. Somewhat inevitable due to the way it checks for access to the Handle property by the wrong thread. The SDK docs for SetParent are not explicit about it, it states the requirement is that both windows belong to the same application. No mention of having to belong to the same thread. I know for a fact that the 'same application' requirement is not hard, there's appcompat code in Windows that makes this work for windows from different processes. Adobe Acrobat ab/used this for a long time. Which definitely absolves the 'same thread' requirement.
Well, punt the problem and try it out. Set Control.CheckForIllegalCrossThreadCalls to false before you set the owner, back to true afterward. And test the heck out of it. If you have trouble then try pinvoking SetParent() directly instead of setting the Owner. Windows Forms actually uses SetWindowLongPtr which is not recommended by the SDK.

I'll take a stab at this. Try running the OSK as a separate process.

Try using ShowDialog for the OSK as well instead of Application.Run - ShowDialog creates a message loop and ends it when the window is closed, and perhaps will solve your problems.
new Thread(() => new OSK().ShowDialog());

Why not use Control.Invoke to make cross-threaded calls to avoid InvalidOperationException?