Connect win form to xna project

As you know, xna does not provide a standard GUI, so each developer has to decide whether to draw it themselves, connect ready-made GUI libraries designed specifically for xna (there aren’t so many of them), or try to connect standard winform / wpf (wpf connection is already wonderful article ).
I did not understand the numerous options for solving this problem and decided to go as it seemed to me the most simple way - by connecting winform. As it turned out, winform has a number of nuances and limitations.
As a result, after an active search, I came to two possible implementations of the interface:
1. The entire interface without the keyboard, i.e. buttons, lists, etc. If you need to enter something from the keyboard, create an external form and receive data from it.
2. The interface is fully functional and you can enter data from the keyboard. But the creation of external forms is impossible + a couple more nuances.
Details:

1

Links to System.Windows.Forms and System.Drawing must be added to the xna project. Then register the code for creating the necessary controls. Controls will not respond to keystrokes. I could find the reason for such behavior on the Internet, but unfortunately I did not find a satisfactory solution, quote:

XNA uses its class to listen on the state of the keyboard, while textbox uses Windows.Form.Input

.
The author of the quote resolved this issue by creating a method that directly receives the pressed buttons through the built-in xna class and directly passes the selected control to the input field. The disadvantage of this approach is that there is no easy way to find out if the “Q” or “Y” key is pressed (For more information about the method, see link 1 at the bottom of the article).

Connection control to the form:

using Size_ = System.Drawing.Size; // A link to System.Drawing has been added to the solution explorer, but only the size and position are needed from the entire namespace
using Point_ = System.Drawing.Point;
...
...
// Create a control      
NumericUpDown nm = new NumericUpDown ();
nm.Location = new Point_ (0, 50);
nm.Size = new Size_ (125, 20);
nm.Value = (decimal) text2;
nm.KeyUp + = new KeyEventHandler (nm_ValueChanged_f);
nm.ValueChanged + = new EventHandler (nm_ValueChanged_f);

// Get the current form
Form general_form = (Form) Control.FromHandle (Window.Handle);
// Connect the control to the current form
general_form.Controls.Add (nm);

* This source code was highlighted with Source Code Highlighter .

Sources of a simple application with controls inside the form and creating an external form at the end of the article.

2

Unfortunately, the method described above cannot be applied to applications requiring text input from the user. Continuing the search, I found a different winform connection method (link 2 at the end of the article). Its essence lies in the fact that the initialization of the form, controls and only then - the game itself. The peculiarity is that in this way the game will not be able to call the update () and draw () methods on its own - they will need to be called separately.
This method is suitable for many tasks, because all created controls will correctly respond to keystrokes.
However, this method has nuances. Allcontrols should be created after (during) the initialization of the form, but before the initialization of the game itself (unnecessary at a particular moment just hide through Visible). The controls created after the initialization of the game form (the application form and the game form are different forms, although this is not visually visible) will not accept keystrokes, unfortunately I could not find out the reason for this. This also applies to creating forms subordinate to the game form - they will be visible, but textbox and similar controls will not work. Also, controls created after the initialization of the game form may not be visible at all if they are subordinate to the application form and not the game form.
It is useless to create top-level forms with this approach - they will be practically inoperative (they will slow down very much).
Of the shortcomings of this approach, I can also note a barely noticeable drop in performance.
The code is relatively large so I did not post it in the article. The source code of the example can be downloaded below (example 2).

I will be glad to additions and constructive criticism!

Links:
1. Deciding the inaccessibility of keyboard input by entering a special method
2. The way to connect the controls is “vice versa” - first initialize the controls, then the games.
3. Description of a method similar to 1mu in the Russian-speaking community xna

Download example 1
Download example 2