You made some nice commits. Someone in a forms environment could use the native MonoGame mouse state or the basic mouse events from the controls in that way. I like that the user could decide what he wants to use - depending on his needs or developing experience with WindowsForms or MonoGame.
First I will push the recent changes I did together with updated sample projects. After that I will come back to your changes and when I have time I will implement this. In the moment I’m very busy, so updates could take a while.
In this update I show you multiple controls on one form and different mouse actions happening on those controls.
Please watch in fullscreen and 1080p:
I removed the old mouse button click detections and worked with the native windows forms control events instead. You can use all common mouse buttons now:
Left Button
Right Button
XButton1
XButton2
Mouse Wheel
In the new sample project (you saw in the video) I created the abstract MapHost.cs class to show you how you could share a common code base on multiple MonoGame.Form controls, but still treat each controll differently. The controls in the view are both inheriting from the same MapHost, but they are getting initialized independently.
This keeps your main control classes clean and easy to manage, because only the non-abstract classes, which inheriting from a MonoGame.Forms control, are visible in the ToolBox from the designer (compare: Control_A vs Control_B)
For the next update I plan to bring back the native MonoGame mouse input using the updates from @nkast. This also has the advantage of faster click detections in relation to the WindowsForms event system.
You can then use both: WindowsForms Mouse Events and MonoGame Mouse Input.
Added Keyboard input support (now MonoGame native)
Raised MonoGame.Framework to 3.7.0.1114 (DirectX)
The mouse handle is now attached when a new control is created, so you could simply use Mouse.GetState() of the MonoGame framework.
I implemented the nice Enable-Keyboard-Trick to enable the native Keyboard.GetState() method of the MonoGame framework.
At this point big thanks to @nkast for your nice input! (pun detected? )
It automatically enables itself when the control has focus and disables when it becomes unfocused.
I added the flag “AlwaysEnableKeyboardInput” so you can override the unfocused behavior (sometimes you may want to have either the keyboard for text input or game / editor related input and sometimes you may want to have game / editor input no matter where the mouse cursor currently is or rather which control has the focus).
Also thanks to everyone else here for your nice ideas so far!
Regarding extendend input capabillities of MonoGame.Forms I think we managed to get everything from the MonoGame framework working.
You should set AutoScaleMode to None on a Form containing a MonoGame.Forms control, otherwise the whole drawn content of the control would be misplaced due to the different viewport size.
If you still want to use DPI scaling, then you need to get the current DPI scale factor of the user and scale all control content by that factor. You can catch this factor in your Form class like this:
If you create a more complex editor environment you could split the DPI scaling of MonoGame.Forms controls and different controls, which containing text and other form controls, by using a DockPanel system and only turn the scaling off for a particular DockContent - containing a MonoGame.Forms control, and then dock it to a DockPanel.
I can reccomend this DockPanelSuit for this purpose. I’m using it in the Rogue Engine Editor and it’s very nice and easy to work with, but for small editor projects it would be a bit overhelming.
Added the bool property “AutomaticInvalidation” to the DrawWindow and UpdateWindow / GameControl classes, so it’s possible to turn the invalidation of the controls on and off.
This is useful when working with NodeGraphEditors where the automatic invalidations would block the whole NodeGraph.
Disabling AutomaticInvalidation on an UpdateWindow now also blocks the GameLoop (update logic) to further enhance performance when using multiple MonoGame.Forms controls.
MonoGame.Forms 1.6.3.0 - DisplayStyle & DebugInfo per Control
Added DisplayStyle enumeration with the options to place the integrated display in the TopLeft or TopRight corner using the new SetDisplayStyle property, which defaults to TopLeft.
Moved Settings values to GFXService to turn the display options on and off for each custom control individual. The old static Settings class was removed from the class library.
Private display style members according to the changes in IGFXInterface, where the user shouldn’t be confused with basically internal properties.
The ServiceContainer class now checks if a specific service was already added to the services dictionary to prevent a crash after reinitializing a custom control.
Fixed that on reinitializing a custom control of the type UpdateWindow, the GameLoop function was reatached multiple times to the Application.Idle event, which caused that the Update method in custom controls was also called multiple times accordingly.
Fixed that on reinitializing a custom control of the type UpdateWindow also reinitialized the StopWatch, which sets the elapsed time to 0 and so could possibly cause errors in the GameLoop.
Moved the bool AutomaticInvalidation to the GraphicsDeviceControl as it is used by all custom controls.
Added the protected event Action<SwapChainRenderTarget> to the GraphicsDeviceControl to reflect the changes on window resizing and giving the editor service classes the new SwapChainRenderTarget. This fixes a NullReferenceException when working with RenderTargets in custom controls.
It’s now possible to change the font color of the integrated display.
But nothing actually happens when I use the mouse wheel. I noticed similiar code in the MapHost source from the samples, but when running it, the mousewheel also does not do anything.
Please check if the mouse cursor is inside the control of the MapHost when using the mouse wheel. The event won’t be triggered if the mouse cursor is outside of the control.
You could check if the event triggers by placing a breakpoint in the OnMouseWheelUpwards event.
I’ve tried it with the mouse cursor inside the control, and it doesn’t trigger any breakpoints I put on the event. I tried getting a fresh copy of the sample project to make sure I hadn’t made any changes to it as well.
I can get around not using the mouse wheel, but I guess I just found it kinda weird since it looks like it should be working.
Correct. All of those do work, including clicking the mouse wheel button to re-center the map image. It just seems to be scrolling the mouse wheel that isn’t working.