MonoGame.Forms - Create your Editor Environment!

Hi @StainlessTobii,

Do you tried the tutorial from the readme file of the git repo?

It should successfully lead you through the creation process of a custom control. When you build your solution the corresponding toolbox item will appear automatically inside your toolbox.

If this doesn’t work for you, can you please tell me if you are receiving any sort of error messages when trying to drag and place a custom control?

Hi @SandboxBlizz,

That’s the frustrating thing. No error messages.

When you try to drag it into the designer view the cursor changes to the “no fecking way” cursor.

When you try and add it to the toolbox, it fails silently.

I have made a lot of custom controls before and never had this problem.

Cheers
Paul

Ok, so when you create your control class it generates the MonoGame.Forms control successfully but it isn’t possible for you to drag this control onto the designer.

I just tried the tutorial from the readme and it still works for me in Visual Studio 2015 and Visual Studio 2017. In the moment it’s not possible for me to reproduce this issue.

Some questions:

Are you using the NuGet or source from GitHub?
Are you creating a fresh Windows Forms project with just MonoGame.Forms specific stuff referenced?
Can you drag and drop Windows Forms native controls from the toolbox onto the designer?
Can you upload your project somewhere so I can take a look?

NuGet package
New windows form project
Yes
No, but I may be able to do a new one and put it somewhere.

Also the project from github won’t allow me to drag a control onto a form, so I don’t think it’s nuget.

Hope this helps
Paul

Hm, this sounds strange to me. In the moment I can’t explain why this is not working for you.

If it’s realy just a fresh Windows Forms project with the installed MonoGame.Forms library, then it will work on my machine.

But yes, upload it somewhere and I will take a look. Would be nice if I could help you.

MonoGame.Forms 2.3.0.1 - Hotfix Mouse.GetState()


  • Updated the MonoGame.Framework to bring back Mouse.GetState() functionallity from the MonoGame.Framework, which got overriden by the newer develop branch of MonoGame.Framework 3.8.0.270.

I just released this update as a hotfix because I detected that Mouse.GetState() always had the default values.

Then I realised that an old PR from @nkast:

wasn’t merged so far. Back in time this PR solved the problem, that when using the MonoGame.Framework independently from its Game class, the user wouldn’t have had any mouse input events through Mouse.GetState() in his editor environment anymore.

This PR seemed good to me to become merged, but instead it became closed and I don’t know why, because it’s actually pretty helpful and, as far as I can see, it wouldn’t have had broken game specific stuff. But who knows, maybe i’m wrong.

Here, just for you to compare (current develop branch vs. fix from nkast).


Anyway, this problem is fixed now for MonoGame.Forms (again :P).

Cheers,
Marcel

PS: NuGets updated accordingly (2.3.0.1).

is there any framerate limit like, wpf?

It’s limited to 60fps.

Question : Any pro and cons between WPF and Winform.
Which 1 is preferred for editor like solution ?

Both will work to create an editor but there there are many differences between them.

  • WPF is a newer technology, WinForms is older.
  • WPF uses an XML based language called XAML, WinForms generates code based designer files.
  • If you use WPF you’ll learn about things like MVVM using a declarative Binding based approach, WinForms is all C# code (at first it feels easier, but many people prefer the declarative XAML based approach).
  • You can embed MonoGame into either, but doing so requires different code (if you look around you can find other people that have done this).
  • Both technologies are Windows based, although there are projects around to try and make them multi-platform (I’ve never seen one that works really well though).
2 Likes

@craftworkgames put it well together, but just for the sake of completeness I also want to mention the awesome imgui library (C++).

There is also a .Net wrapper called ImGui.Net.

From the readme file:

This is a .NET wrapper for the immediate mode GUI library, Dear ImGui (https://github.com/ocornut/imgui).
ImGui.NET lets you build graphical interfaces using a simple
immediate-mode style. ImGui.NET is a .NET Standard library, and can be
used on all major .NET runtimes and operating systems.

There is a sample program which shows you how to use it together with MonoGame.

The advantage here is that you can integrate it into a DesktopGL project which makes your editor available on multiple platforms without extra work.

I also managed to make it work with MonoGame.Forms so you would have additional designing options in a WindowsForms environment, where it’s often painful to design things (like a property grid).

Another advantage is that you can still use WindowsForms controls / user controls or file dialogs which makes working with directories and files pretty easy.

But in the end it really depends on your ambition and technology knowledge. I would say:

  1. Are you skilled with WPF? Then try to create your editor with the MonoGame.WpfInterop.
  2. You just want a little tool window for manipulating level files? Maybe then MonoGame.Forms is simple enough.
  3. You want a full blown multi platform editor? Maybe then you should try the ImGui.Net library with the MonoGame.Framework.
  4. Are you experienced with WindowsForms but not with WPF and you want fast results without missing designing capabilities? Well, I can show you how to integrate ImGui.Net into a MonoGame.Forms project.

Hope this helps with your decision.

2 Likes

Thanks for all the detail information !! :grinning:

1 Like

how rendertarget work on MonoGame.Forms. When i try to use do my rendertarget, it show red color output. 2nd Question can Mouse.GetState() work in Monogame.form?

It works likewise but you need to set the render target back to the SwapChainRenderTarget afterwards (GraphicsDevice.SetRenderTarget(SwapChainRenderTarget))

I recommend using the integrated RenderTargetManager. Here is a sample.


Yes, Mouse.GetState() should work as well as the WindowsForms input events.

thanks , ermm i dun get any mouse input and position is always 0.

It seems you are using an outdated version. Try upgrading to the newest release.

Regarding mouse position I recommend working with GetAbsoluteMousePosition and GetRelativeMousePosition to get the exact mouse coordinates:

Editor.GetAbsoluteMousePosition
Editor.GetRelativeMousePosition

MonoGame.Forms 2.3.5


  • Added void RunFrames(int) to run a specific amount of frames of a MonoGameControl, when the bool MouseHoverUpdatesOnly was set to true.
  • Open up the ResourceContentManager to enable content loading from a resource file .
  • Using void ResourceContentManagerInitialize(ResourceManager) to initialize the ResourceContentManager, which is available for the user to load custom content from a resource file (.resource).
  • Property bool IsMouseInsideControl is now directly accessible through the GraphicsDeviceControl, so there is no need of using the editor service class for this.
  • Added protected bool IsMouseInsideControlArea(int, int, int, int), so the user can check if the mouse cursor is inside a specific control area.
  • Reattaching the Mouse.WindowHandle when entering a different GraphicsDeviceControl in case it gets lost.

Cheers,

  • Marcel

@SandboxBlizz is monogame.forms native looking to the os’s current theme?

No, MonoGame.Forms itself does no theming. Just what WindowsForms has to offer.

But of course you can do your own themes or load various user controls with different themes.

So, theming is completly up to you.

my issue is I want to make the control always look native to the os