MonoGame.Forms - Create your Editor Environment!

I have a small painting application working well, however there are some notable issues I am experiencing, even with completely new projects with the DrawTest object added and not much else.

  • GUI objects including MenuStrips and don’t show up properly on startup (aren’t drawn properly)
  • Message Boxes don’t show properly (sort of hidden behind the DrawTest)
  • Timers don’t trigger unless I set the DrawTest control to invisible
  • And related issues

However the official example projects don’t seem to suffer from these issues.

Please try to exchange the DrawWindow with an UpdateWindow.

I will later write a seperate post about the current situation with Draw- and UpdateWindows, regarding future updates of MonoGame.Forms.

Looks good for the moment. Thanks again.

1 Like

Hello MonoGame!

I quickly want to write down my current thinkings about the next update of MonoGame.Forms.

I experienced that more and more people coming to MonoGame.Forms are struggeling to choose the right forms control to start with or rather how they are technically working or rather what I originally thought about the usage of such controls.

Basically you have two different controls you can inherit from. They are the DrawWindow and UpdateWindow.

The naming of these controls is unprecisely today, because originally MonoGame.Forms worked differently. I overhauled the whole work flow / editing experience of this library, but never changed the naming of classes like them.

So, I plan to rename them to “InvalidationControl” (DrawWindow) and “MonoGameControl” (UpdateWindow) in the next update.


Why “InvalidationControl”?

Simply because it’s exactly like that: it’s a control meant to do your own custom invalidations as soon as you have changes to commit.

This special control is very performant, because it only needs your CPU power this single time it gets invalidated by YOU (after the output is drawn to the surface, it consumes 0% CPU).

You would typically use it like that (example TileMap editing):

  1. Move MouseCursor to InvalidationControl
  2. Place a tile in the control view
  3. Call Invalidate(); on this control
  4. Output gets rendered to the surface
  5. Job is done - no CPU usage

This is exactly like the DrawWindow works today, but with the difference that the property AutomaticInvalidation is turned on by default. This leeds to slow downs and not reacting user interfaces anymore, because of the massive (automatic) invalidations taking place.

However it turned out that most of the people just want to “jump start” into the editing experience MonoGame.Forms has to offer without worring about the invalidations or even CPU usage.

Why “MonoGameControl”?

Simply because it has the complete “Initialize / Update / Draw”-concept instead of the InvalidationControl, which becomes updated through invalidations. This control is bit like “shoot and forget”. You just inherit from this control in your custom class, override the corresponding functions, don’t need to worry about invalidations or performance and just be a happy editor! :wink:


That’s why I will rename the controls in question. The user will surly take the MonoGameControl instead of the InvalidationControl, because if in doubt what the InvalidationControl should be, he would take a look at the GitHub wiki how this control works. On top of it I will also change the xml commentary of this class to make this information clearly available in code.

In the demo project I showed how to use AutomaticInvalidation togehter with a DrawWindow, but i’m thinking of making this option unavailable for a DrawWindow. At least it will be turned off by default in the next update.

Hope this will make using this library more easy and innovative.

Thanks for reading!

Cheers,
Marcel Härtel

May I render models and UserPrimitives?

Yes, but there are no built-in service classes for that.

This means you need to do everything related to 3D on your own - just like with a new MonoGame project.

Everything is. I transfer the XNA project. But nothing is displayed. Only color of a background changes (established for control only).

I’m not sure if I understood you correctly.

Please download the project on GitHub:

and start the MonoGame.Forms.Tests.DX project, which is the sample project demonstrating the library.

If this is working for you then try to create a custom control with a simple polygon and see if it’s showing up.

In your project the primitive is displayed, but only with BasicEffect and without color. Does not work with the loaded effect.
In my project nothing is displayed. Perhaps because of my Camera component.
Deep alteration of your code exceeds my opportunities. I will look for other way.

Sorry for machine translation and thanks for the answer.

Sorry to hear that it’s not working for you as expected.

I think it would be nice to have a small 3D sample in the demo project. Can’t tell when this will happen though.

Anyway, I wish you good luck with your project!

MonoGame.Forms 2.2.0 - Renaming Classes and Bugfixes


  • Renamed DrawWindow to InvalidationControl.
  • Renamed DrawService to InvalidationService.
  • Renamed UpdateWindow to MonoGameControl.
  • Renamed UpdateService to MonoGameService.
  • Removed protected bool AutomaticInvalidation from GraphicsDeviceControl.
  • Fixed a bug which caused a crash when creating a new RenderTarget and the BackBufferWidth / -Height had a size of 0.
  • Ensures that a MonoGameControl invalidates automatically when using the GL library.

If you want to know the reasons for renaming the above mentioned classes, then please read this post:

Cheers!
Oh, and Happy new Year! :smiley:


NuGet
NuGet

2 Likes

MonoGame.Forms 2.3.0 - Video Support & OnMouseHoverUpdatesOnly


  • Added public GameTime to easily get the current game time of the game loop in a custom MonoGameControl.
  • Added public bool MouseHoverUpdatesOnly to enable controls updates when the mouse cursor is inside a custom MonoGameControl to save CPU power.
  • Added public void RunOneFrame() to run exactly one frame of a MonoGameControl to update its contents and immediately show the result to the user.
  • Updated the MonoGame.Framework to 3.8.0.270 and modified the VideoPlayer class to support video playback. [DX]

Video Example:

//Field
VideoPlayer _VideoPlayer;

//Loading
Video video = Editor.Content.Load<Video>("MyVideo");

//Instantiating
_VideoPlayer = new VideoPlayer(GraphicsDevice); //GraphicsDevice
_VideoPlayer.Play(video);

//Drawing
Editor.spriteBatch.Begin();
Editor.spriteBatch.Draw(_VideoPlayer.GetTexture(), new Vector2(0, 0), Color.White);
Editor.spriteBatch.End();

As you can see, you just need to give the new ctor of the VideoPlayer class the current GraphicsDevice.


It’s also possible to donate to the project now. This is taken from the Readme.md file:

Feel free to buy me a Lithium-ion battery so I can code like a machine!

… or simply show your support by donating what you want :>


I hope you like the new update and I wish you a nice weekend! :smiley:

Cheers,
Marcel Härtel

2 Likes

Hi Marcel,

Just tested this in Visual Studio 2017, and I cannot add any of the controls to a form in the designer.

I can run all your test apps from Git, they all work perfectly, but you cannot add a control to a form in the designer.

You cannot add it to the toolbox either.

Have you come across this at all?

Cheers
Paul

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 @BlizzCrafter,

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?