MonoGame.Forms - Create your Editor Environment!

[sqrMin1]

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

[sqrMin1]

MonoGame.Forms 2.3.5

https://github.com/sqrMin1/MonoGame.Forms

---

• 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

https://github.com/sqrMin1/MonoGame.Forms

[Shadowblitz16]

@sqrMin1 is monogame.forms native looking to the os's current theme?

[sqrMin1]

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.

[Shadowblitz16]

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

[sqrMin1]

MonoGame.Forms 2.3.7

https://github.com/sqrMin1/MonoGame.Forms

---

• Refactored Camera2D component.
• Added public float DefaultZoom/DefaultRotation/DefaultPosition properties, so that it's possible to reset these values to specific default values.
• Added overloads to the ResetCam method, so that it is possible to reset specific camera values like Position, Zoom and Rotation.
• It's now possible to quickly set the default values of the camera to the current ones with SetDefaultsFromCurrent().
• Added Buy me a Cola-Light support button.
• Added a GitHub Sponsor button.

---

MonoGame.Forms is now 21 month old and recently reached over 20.000 views here in the MonoGame community. This makes it the second most viewed thing in the "Showcase" topic.

Additionally we achieved 9.868 downloads of the library on nuget.

So, it's time to raise a glass or two

Huge thanks for your ongoing support and furthermore happy editing!

Cheers,
- Marcel

https://github.com/sqrMin1/MonoGame.Forms

[cra0zy]

A bit of a side note, since I realized I never mentioned it, I have published Gtk version of MonoGame for quite some time (sorry @SpiceyWolf, I know I hijacked the package from you). Gtk for those of you who don't know is a GUI toolkit mainly used by Linux apps, however it works under Windows and Mac as well. To try it out do:

# install templates
dotnet new --install MonoGame.Template.Gtk.CSharp

# create project in current dir
dotnet new mggtk

# run project
dotnet run

(On Windows you need to install Gtk beforehand: https://github.com/GtkSharp/GtkSharp/wiki/Installing-Gtk-on-Windows)

---

@sqrMin1 Some of my random thoughts.

• We could make an Eto.Form control
• you can specify the MonoGamePlatform property in the nugets themselves
• you can compile content during runtime by using MG.Content.Pipeline dll file found next to the Pipeline Tool, its what MGCB/Pipeline Tool actually use to compile content
• What are you doing regarding input handling, if anything? With Gtk version I made a limitation of only 1 active control so I fully implemented input handling based on widget position and focus

[sqrMin1]

I remember seeing that Gtk version of MonoGame somewhere. I believe it was on GitHub. But I haven't tried it so far.

1. An Eto.Forms version of MonoGame.Forms would be a great addition, because our GL implementation would be slower than a more "native" multi platform integration through the original graphics context rather than just converting the back buffer to a bitmap like in our case.

2. Oh, never thought about that, but this is a nice idea. So the end-user has less pre-setup to do before using the library. Now that you addressed this, I think about setting up a seperate .targets file which also imports the MonoGame.Content.Builder.targets file and includes a basic MonoGameContentReference file (.mgcb). I'm sure one could also create a template for this, but I never did that so far and would need to read a bit into this topic.

3. Yeah, personally i'm using the MGCB.exe in a different project to do this. I'm not sure how I would implement this in the MonoGame.Forms library for the end-user so that it would makes sense in his editor project. I now it's possible to directly use the MG.Content.Pipeline.dll and make the content compilation available without an extra tool. Maybe I could write a helper class for it and let the user decide how to use this functionality.

4. It's the same for MonoGame.Forms. Only the control with active focus receives input from the user. We are using the original input functionality from the MonoGame.Framework for mouse, keyboard and gamepad interaction. The DX version utilizes a nice little keyboard trick using reflection (@nkast showed it to me first ). The GL version uses the SDL-Input capabilities from the MonoGame.Framework by using SDL.PushEvent() (same for mouse input). The DX version receives mouse input by setting the window handle to the control handle as soon as the mouse enters the specific control. We put that not in the initialization of a control to avoid null pointers, when the user disposes the specific control in a multi viewport application. To make this available we needed to refer to an older PR from nkast and merge that with a custom build of the MonoGame.Framework, because this PR wasn't merged with the original source so far.

Can you point me to your Gtk repo if available? I would be happy to link that in our README.

I also saw that the GitHub repo of the MonoGame.Framework has a support button now. I will update the MonoGame.Forms repo with this additional support url soon.

Thanks for your input!

BTW: I'm not experienced with Eto.Forms, so I would need to read into this topic too. I think we would need something like an EtoViewport for GL rendering which gets the graphics context from the MonoGame.Framework (SDL). Is there something like that in existence? Because then such an implentation would be not that hard, I think.

[cra0zy]

For now the Gtk version lives in my fork but I'll try to get it into main repo once again at a later point: https://github.com/cra0zy/MonoGame/tree/gtk

[sqrMin1]

I'm sure one could also create a template for this, but I never did that so far and would need to read a bit into this topic.

As a small update on this:

Turns out it was easier than expected. Visual Studio 2017 templates are now available for Windows, Mac and Linux (Windows and DesktopGL templates):

They are completly pre-setuped to jumpstart the editor creation process. So they include all necessary libraries (nuget), the MonoGame content response file (.mgcb) included as a MonoGameContentReference and the MonoGamePlatform based on the selected template.

The MonoGame.Content.Builder.targets and MonoGame.Common.props are imported as well (like it would be when the user creates a new MonoGame.Framework project).

I also included a SampleControl which inherits from MonoGameControl of MonoGame.Forms to demonstrate the general usage idea of the library.

If the user builds and runs the solution he should be greeted with this welcome screen:

It shows the content of the SampleControl.

---

Library: https://github.com/sqrMin1/MonoGame.Forms
Template Source: https://github.com/sqrMin1/MonoGame.Forms-Templates

[StainlessTobii]

Tested on visual studio 2017, worked perfectly first time.

Well done.

[sqrMin1]

MonoGame.Forms 2.3.8 - Combined NuGet-Packages

https://github.com/sqrMin1/MonoGame.Forms

---

• Now importing the MonoGame.Content.Builder.targets and MonoGame.Common.props file and setting the MonoGamePlatform property in all MonoGame.Forms.target files (DX, GL). @cra0zy
• Added MonoGame.Content.Builder content/libs/nuspecs/targets for DX and GL platform.
• Added combined NuGet-Packages which containing pre-setuped .mgcb files and the corresponding toolset as well as a custom MonoGame.Content.Builder.targets file to build MonoGame-Content.
• Added new doc image to visualize the available nuget packages in the readme:

---

To comply with the recently added Visual Studio templates, now there are also NuGet-Packages available which containing all necessary files and setups to build content with the MonoGame-PipelineTool to make content compiling a breeze:

These packages are containing both, the library and the content builder, so you can install the complete setup in one go.

I created seperate packages to still allow library-only-installations just in case content compiling is not needed by the end user (like the sample projects in the repo. They are containing pre-compiled content for example).

There is still a difference between the combined NuGet packages and the VS templates; the templates containing a sample control, which demonstrates the general usage idea of the library. The NuGet packages are full 'skeletons'.

Hope you'll have fun!

Have a nice day,
-Marcel

---

https://github.com/sqrMin1/MonoGame.Forms

PS: The regular NuGet packages also containing properties like the MonoGamePlatform and they are also importing MonoGame targets and probs files, just in case the user started with these libraries and wants to integrate the .mgcb file in a later state. So he really just needs to include this file and is ready to go!

[YTN]

@sqrMin1 Neat project!

I am testing it out and have a basic project going.

I am running into a minor issue where I am currently using a slightly modified version of the Monogame DLL (I have a PR with my changes still pending review and merge) which doesn't quite work when I swap out the monogame DLL that comes in the nuget package with my modified one.

If I use your DLL, then my code doesn't compile. If I swap out your DLL for my DLL, then everything works and runs, but the form designer no longer works.

On the github page, you mentioned that you are using a modified version of the Monogame DLL. Can you clarify what changes you made?

The weird thing is, the code compiles and runs with my Monogame DLL, but the form designer won't work.

[sqrMin1]

Hey @YTN and thanks!

Yes, you can't easily swap the MonoGame.Framework in the moment.

Are you using the DX or the GL library?
What error are you receiving when you try to open the form designer?

[YTN]

@sqrMin1 Thanks for the reply!

This is the DX version.

There was an option to ignore the error which allowed the form to render. Now I can't get back the original error. I do get a different error now whenever I change or set any properties for the Monogame control. The error I get when I try to save after changing the property is "Code generation for property GraphicsProfile failed. Error was 'Type Microsoft.Xna.Framework.Graphics.GraphicsProfile is not available in the target framework'"

The only way for me to modify and save the form properties is if I restore the original DLL (which means I can't compile my code). I then switch back to my dll in order to build and run.

Would it be possible for you to build me a new Monogame.Framework.dll with this PR integrated?

Fix for #6732 - Exposes the instancing base index

This will have the changes I need so I can use the form designer and build and run without issues.

The PR should be fully backward compatible, so shouldn't impact any existing behavior if you leave it in.

Thanks!

[YTN]

@sqrMin1 Separate question... my current framework can draw directly to the screen (GraphicsDevice.SetRenderTarget(null) ) or to a rendertarget which I can then draw on the screen.

I tried shoehorning that into MonoGame.Forms, but I don't get anything displayed. I suspect it's because my framework is setting the rendertarget back to null (physical screen) when it's done, and that's breaking your stuff.

Are you using a RT internally?

If so, how do I get access to your RT?

How does MonoGame.Forms work with existing frameworks that usually have direct access to the GraphicsDevice?

Thanks.

[sqrMin1]

Would it be possible for you to build me a new Monogame.Framework.dll with this PR integrated?

I think I will push the modified source of the MonoGame.Framework to the repo, so you can modify it for your own custom build as you wish.

But I currently don't know when I have time for it. Maybe during this weekend.

GraphicsDevice.SetRenderTarget(null)

Yeah, this don't work like this in MonoGame.Forms. You would need to set the render target back to the SwapChainRenderTarget: GraphicsDevice.SetRenderTarget(SwapChainRenderTarget)

You can generally find alot of hints/examples/explanations in the wiki:
https://github.com/sqrMin1/MonoGame.Forms/wiki

Like for your problem:
https://github.com/sqrMin1/MonoGame.Forms/wiki/671B92F5

There is also a RenderTargetManager, which simplifies work like that:
Class: https://github.com/sqrMin1/MonoGame.Forms/wiki/ADAA9059
Create: https://github.com/sqrMin1/MonoGame.Forms/blob/master/MonoGame.Forms.DX/Services/GFXService.cs#L395
Sample: https://github.com/sqrMin1/MonoGame.Forms/wiki/E2A82597

[YTN]

@sqrMin1 Thanks for the details!

I figured out my RenderTarget issues. The only thing left is the dll problem.

If you could upload your modified MonoGame source to GitHub, I'd be more than happy to build my own modified version with the PR I submitted.

Thanks again!

[sqrMin1]

The source is now up:
https://github.com/sqrMin1/MonoGame.Forms/tree/master/Libs/MonoGame/_src/Windows

Sorry for the late reply.

[YTN]

@sqrMin1 Thanks! I built a modified version of the DLL with your modified Monogame code and my PR and it works great!