MonoGame.Forms - Create your Editor Environment!

Showcase
21

I will soon report back with an updated repo which has full mouse support.

Good to hear.
FYI, I posted a PR that enables Mouse on any Wnd
control.

22

Thank you very much, but I canā€™t find the PR. Can you please check it again?

23

Here it is: https://github.com/MonoGame/MonoGame/pull/6081

and hereā€™s the MG setup: http://teamcity.monogame.net/repository/download/MonoGame_PackagingWindows/58823:id/MonoGameSetup.exe

You have to set Mouse.WindowHandle to your Control.Handle.

1 Like
24

Ah, itā€™s in the MonoGame repo - my bad :slight_smile:

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.

Thanks for your help @nkast!

25

Update: Multiple Controls & Mouse Input

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.

1 Like
26

MonoGame.Forms 1.5 Released!

  • Removed old Keyboard Util and Service classes

  • Added Mouse input support (now MonoGame native)

  • 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? :smiley: )

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.

Thanks again :slight_smile:

2 Likes
27

This is only good on windows right ?

Anyways if that is the case i found this it might be helpful.
http://www.pinvoke.net/default.aspx/user32.mouse_event
and this
https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-and-screen-scaling.

28

And how does it work for Linux, Mac and Android and other platforms? :open_mouth:

29

Currently only the windows platform is supported.

I want to add something to the screen scaling:

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:

System.Drawing.SizeF CurrentDPIScaleFactor = AutoScaleFactor;

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.

30

MonoGame.Forms 1.5.7.0 Released!

  • Itā€™s now possible to set the GraphicsProfile during Design-Time (see picture below)
  • Editors from DrawWindow and UpdateWindow are now hidden from the property grid
  • Disposing MouseWheel events to prevent memory leaks in the samples project
  • Added missing MonoGame.Framework assemblies to NuGet with automated referencing, when installing the package

GraphicsProfile

2 Likes
31

MonoGame.Forms 1.6.0.0 - Window Resizing!

  • The SwapChainRenderTarget now gets updated when resizing a Forms window, so that the drawn content wonā€™t get stretched and distorted anymore.
  • DrawService and UpdateService are now both inheriting from IDisposable. Contents of the service classes are now getting disposed automatically.
  • The Camera2D component automatically reacts to the new window resizing feature.

NuGet: https://www.nuget.org/packages/MonoGame.Forms/1.6.0

2 Likes
32

You mean it is like GraphicsDeviceControl? But where is for OpenTK?

33

MonoGame.Forms 1.6.2.0 - Automatic Invalidation

  • 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.

NuGet: https://www.nuget.org/packages/MonoGame.Forms/1.6.2

Progress Video
https://youtu.be/9PrY6TZn6bI

NodeGraphEditor Test
https://youtu.be/Mg_5vNfaygo

34

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.

NuGet: https://www.nuget.org/packages/MonoGame.Forms/

2 Likes
35

MonoGame.Forms 1.6.4.0 - Reinitialization & SwapChain Fixes

  • 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.

NuGet: https://www.nuget.org/packages/MonoGame.Forms/

2 Likes
36

Do you know if the mousewheel events work properly?
I have the following set up:

protected void MapComponent_OnMouseWheelUpwards(MouseEventArgs e)
{
//do something
}

And I have this in Initialize()

OnMouseWheelUpwards += MapComponent_OnMouseWheelUpwards;

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.

37

Yes, it still works for me.

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.

38

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.

39

Just for clarification: does the OnMouseClick, OnMouseUp, OnMouseDown or OnMouseMove event working for you in the MapHost sample?

40

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.