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.
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
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,
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)
@BlizzCrafter Some of my random thoughts.
I remember seeing that Gtk version of MonoGame somewhere. I believe it was on GitHub. But I haven’t tried it so far.
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.
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.
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.
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.
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
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: GitHub - BlizzCrafter/MonoGame.Forms: MonoGame.Forms is the easiest way of integrating a MonoGame render window into your Windows Forms project. It should make your life much easier, when you want to create your own editor environment.
Template Source: https://github.com/sqrMin1/MonoGame.Forms-Templates
Tested on visual studio 2017, worked perfectly first time.
Well done.
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
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!
@BlizzCrafter 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.
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?
@BlizzCrafter 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?
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!
@BlizzCrafter 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.
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.
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:
Like for your problem:
There is also a RenderTargetManager, which simplifies work like that:
Class: Home · BlizzCrafter/MonoGame.Forms Wiki · GitHub
Create: https://github.com/sqrMin1/MonoGame.Forms/blob/master/MonoGame.Forms.DX/Services/GFXService.cs#L395
Sample: Home · BlizzCrafter/MonoGame.Forms Wiki · GitHub
@BlizzCrafter 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!
The source is now up:
Sorry for the late reply.
@BlizzCrafter Thanks! I built a modified version of the DLL with your modified Monogame code and my PR and it works great!
@BlizzCrafter Hey mate. I added MonoGame.Forms to MonoGame Awesome when I added MonoGame.WpfCore because I think they are both equally awesome projects.
I was surprised it wasn’t in the list already
Thank you very much @craftworkgames
It’s also nice to see a modern Wpf implementation. Good work
Just wanted to inform you what i’m currently working on.
It’s the Runtime Content Compiler (RCC) for MonoGame.Forms (suggested by @harry-cpp) . It’s a WIP but I thought it would be nice to share my current state and what decisions I made. So, let’s start!
I originally thought about how the implementation of this thingy would look like or rather what would be the best possible way of having the RCC integrated into the MonoGame.Forms library.
I started creating a simple helper class which interacted with the original MGCB and the PipelineManager from the MonoGame.Framework.Content.Pipeline namespace. It worked but I was not satisfied with it because a couple of reasons:
However, I rethought everything and came to the idea / conclusion that it would be way nicer to integrate the original MGCB class (BuildContent.cs), the PipelineManager (and adjacents) and re-implement it at least asynchronously and as a seperate project which can be installed per NuGet on demand.
This also has the advantage, that the RCC will have all the original features of the MGCB as well as its exception- and log system.
So, I decided to go that route and just created a small wrapper around it, which is easy to use by the end user and very practial in a MonoGameControl, but still works independently from the MonoGame.Forms library - yup, that sounds nice®.
I already created all the basics. Take a look:
I picked a bunch of .jpgs & .pngs and let the RCC do the rest. You don’t need to set importers or processors for regular content, because it will fallback to the default ones based on the extension of the raw content - thanks to the features of the original MGCB!
Basically you can do everything what is possible with the MGCB now and the content compilation happens asynchronously - that’s why I wanted to re-implement all the pieces.
I think during this week.
Still need to do a couple of things and general cleanup. The MonoGame.Forms version to be expected is 2.4.0, which is the next milestone (we are currently at 2.3.8).
See you then and have a nice day!
-Marcel | Sandbox Blizz
GitHub: https://github.com/sqrMin1/MonoGame.Forms
BTW: The Visual Studio templates went pretty well. In about 2 Months we received 2,477 installs
Thank you very much for your ongoing support!