Thank you very much @craftworkgames 
It’s also nice to see a modern Wpf implementation. Good work 
1 Like
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!
Helper class or re-implementation?
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:
- It was a “Single-Task-Job” and you needed to wait till it’s finished.
- It was not customizable.
- It cluttered the output with MGCB binaries in every project - regardless if they use the RCC or not.
- [insert more issues here]
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®.
The Prototype
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.
The Release Date
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!
3 Likes
MonoGame.RuntimeBuilder - out now!
The MonoGame.RuntimeBuilder builds your raw content asynchronously to the .XNB format during runtime.
This library is a part of the MonoGame.Forms project,
but it is fully usable without the MonoGame.Forms library!
Hello Com,
The basic work on the RuntimeBuilder is done and depsite the fact that it is a part of the MonoGame.Forms familiy ( 
), it don’t need to live in the MonoGame.Forms repo or library. It’s generally usable as a standalone library to build your own tool with runtime content builder functionality - hurray 
Using the MonoGame.RuntimeBuilder is fairly easy:
// Creating the property.
private RuntimeBuilder _RuntimeBuilder { get; set; }
// Initialize the RuntimeBuilder.
_RuntimeBuilder = new RuntimeBuilder(
Path.Combine(Application.StartupPath, "working"), // working directory
Path.Combine(Application.StartupPath, "working", "obj"), // intermediate directory
Path.Combine(Application.StartupPath, "Content"), // output directory
TargetPlatform.Windows, // target platform
GraphicsProfile.Reach, // graphics profile
true) // compress the content
{
Logger = new StringBuilderLogger() // logger
};
// Pick Files & Build Content.
private async void ButtonPickFiles_Click(object sender, System.EventArgs e)
{
if (openFileDialog.ShowDialog() == DialogResult.OK)
{
await _RuntimeBuilder.BuildContent(openFileDialog.FileNames);
}
}
And… that’s it!
Read more on GitHub!
Of course it’s also available on nuget:
Feel free to follow me:
I wish you a happy day! 
-Marcel | Sandbox Blizz
1 Like
Yesterday, Friday the 13th, was my lucky day (it has always been my lucky day)
I got 2 beta invites on this special day:
- GOG Galaxy 2.0 at 4:22 pm
- GitHub-Packages at 8:15 pm
I’m telling you this mainly because of the GitHub thingy. As a result packages of all my libraries are also available on GitHub now!
These are the packages of MonoGame.Forms.
These are all packages currently available on my GitHub profile.
Have fun checking these out!
I wish you a nice and lucky weekend! 
-Marcel
Follow me for the extra portion luck in your life:
( lol )
There are similarities as far as I can see, but I followed a different design philosophie. For example in MonoGame.Forms you will not work with a classical XNA/MonoGame Game.cs class. It’s a “game-class-independent-implementation” if you want to call it like that.
The core class is the GraphicsDeviceControl which inherits from a regular System.Windows.Forms.Control and has the following core purpose:
- in OnCreateControl() it creates the GraphicsDevice and a SwapChainRenderTarget
- in BeginDraw() it sets the RenderTarget of the GraphicsDevice to the SwapChainRenderTarget
- in EndDraw() the SwapChain presents the rendered image
It also handles client resizing and user input by converting the pressed keys to the XNA/MonoGame equivalents.
The general idea was to extend the library functionality later by service classes so that users would have a nice and easy time to start their own editor projects.
So if the user wants to have an updateable render surface, then the only thing he needs to do is to inherit from MonoGameControl like this:
using Microsoft.Xna.Framework;
using MonoGame.Forms.Controls;
namespace nugetTest
{
public class DrawTest : MonoGameControl
{
string WelcomeMessage = "Hello MonoGame.Forms!";
protected override void Initialize()
{
base.Initialize();
}
protected override void Update(GameTime gameTime)
{
base.Update(gameTime);
}
protected override void Draw()
{
base.Draw();
Editor.spriteBatch.Begin();
Editor.spriteBatch.DrawString(Editor.Font, WelcomeMessage, new Vector2(
(Editor.graphics.Viewport.Width / 2) - (Editor.Font.MeasureString(WelcomeMessage).X / 2),
(Editor.graphics.Viewport.Height / 2) - (Editor.FontHeight / 2)),
Color.White);
Editor.spriteBatch.End();
}
}
}
"Editor" is the underlying GFXService class, which contains basic XNA/MonoGame functionality as well as helper classes like a RenderTargetManager which makes working with render targets easier (client resizing etc.). Generally you will find additional useful stuff to jumpstart your editor creation process. Fell free to take a look at the Wiki to discover more of them.
Have fun and a nice day 
-Marcel
1 Like
I recently updated the repo and the old MonoGame.Forms nuget and want to share some infos with you regarding this.
- The old MonoGame.Forms nuget package recently reached over 6000 downloads and got his last update mid 2018. Nevertheless I decided to completly unlist the old package from nuget. Why?
With version 2.0 I created new packages with a complete re-design of how MonoGame.Forms should work. Since then the old package was just listed as a reference and to have a stable alternative to the new packages.
Now, roughly one and a half year later, the old package still received ca ~8 downloads per day (~240 / month, ~2880 / year). I don’t know how many new users are in these numbers nor how often they downloaded the old package, but if it were only 2% of them, we would still have ~58 new users per year installing the old package. Yeah, this doesn’t sound much and it is probably not a big deal, but… every single user counts!
So, I kinda “forcing” them now to download the new packages instead. They are containing the latest updates, features and improvements; there is really no need in using the old package anymore and I recommended using the new packages ever since.
There is only one disadvantage on my side: the overall download count of nuget packages on my nuget profile is now misleading because the 6000 downloads of the old MonoGame.Forms package got substracted. Well, i’m getting over it 
-
I also updated the tutorial section of the Readme.md file to make it clearer and more obvious for beginners to start with MonoGame.Forms and better understandable to correctly use the library.
-
I added an ImplementationDetails.md file to the repo, so that I can easily refere to it in case someone asks me about this topic (which happened a lot over the time).
That’s it!
Have a nice day.
:: Marcel
BTW: my old english teacher told me once, that ending a presentation with “that’s it” is unprofessional and stupid. Well, I guess I did something stupid here, but I don’t care 
1 Like
im still not able to use Mouse.GetState() in the Control with the latest source. When i console Mouse.GetState().LeftButton it always return in Released state, and i pressing it all time. FYI i am using attached my control in docksuite https://github.com/dockpanelsuite/dockpanelsuite
@BlizzCrafter i noticed when i change the monogame reference to the official release “v3.7.1.189” the Mouse.GetState() dont work. But when i change the reference back to the version your provide in your github, it actual worked! May i know what have u change from the source?
Yeah, changes are needed:
The original source is included:
https://github.com/sqrMin1/MonoGame.Forms/tree/master/Libs/MonoGame/_src/Windows
Just merge it with the MonoGame version you want to use and make your own specific changes.
And yes, it works with DockPanelSuit.
I have some weird behaviour when using Monogame.Forms: Created a small program and do some keyboard input in Update().
I noticed that it only registers keystrokes when the mouse has been hovered over the control once. After that, it works even when the mouse is outside.
I have set the following though:
AlwaysEnableKeyboardInput = true;
MouseHoverUpdatesOnly = false;
Shouldn’t it register keystrokes immediately? Is this intended? Do I miss something? I am stumped. 
This is normal behavior.
Try to programmatically focus the specific control before doing keyboard input and tell me if this works / solves your problem.
I tried with control.SetFocus() and control.Select(), but to no avail. I also tried overriding OnLostFocus, no chance either. Is there any other way?
Ok, I found the problem; I need to push a small update to make your request possible.
Just to clearify: You want an option to enable the keyboard input right from the start of your application and without that the user needs to hover the mouse over a control beforehand, right?
Edit: try it with this patch (master): https://github.com/sqrMin1/MonoGame.Forms/commit/ef34d49f607bf47bb79d340c45bc6c2d44bbe496
Nugets will follow.
2 Likes
Yes, exactly! 
Thank you very much! Works like a charm now.
Perfect.
Nugets updated acordingly.
Changed the Readme.md file of MonoGame.Forms to show a short description of the Mercury Particle Sandbox. It’s still possible to show the real Readme.md file of MonoGame.Forms by clicking on the respective link in the file.
This is what the Readme.md file now shows:
[start of file]
Mercury Particle Sandbox
The first application on Steam which uses the MonoGame.Forms library!
Click on the image to visit the Steam Store Page and read the full app description.
Following and adding it to your Wishlist is the best way to support the MonoGame.Forms library, the Mercury Particle Sandbox and me!
Thank you very much for your ongoing support!
:: Sandbox Blizz 
[screenshots]
[end of file]
This is a great project @BlizzCrafter thanks for continuing to support this! I’m working on a Level Editor for our game and it was extremely simple to plug in and get things up and running!
However, I’m having an issue I was hoping you could shed a light on. Most everything seems to be working fine, but for some reason I seem completely unable to load any Effect files. Is there a specific shader model that needs used or some special handling I missed somewhere? Whenever I attempt to load an effect file through the editor’s content manager it throws a SharpDX exception. Of course it’s the entirely useless “The parameter is incorrect” message so I’m not sure what the actual issue is, but it fails on loading instead of setting anything which I found interesting.
This has happened when trying to load the same shaders I use (and are working fine) in my game, and I’ve also tried to make an extremely simple shader to nail down the problem, but even as something as basic as the following still throws an exception:
float4 RedPixel(float2 coords: TEXCOORD0) : COLOR0
{
return float4(1, 0, 0, 1);
}
technique CrazySimple
{
pass P0
{
PixelShader = compile ps_4_0 RedPixel();
}
}
My best guess is that there’s an issue somewhere because everything I have is building against MonoGame 3.7.1, but the only reference to MonoGame.Framework in my LevelEditor project is the included DLL from Forms. Is this possibly an issue from MGCB.exe being built against 3.7.1?
Also just to mention, Effects seem to be the only thing I’m having trouble with. Fonts, Models, etc all seem to be loading and working as expected.
Of course as soon as I posted my above question I found the issue. I needed to ensure the GraphicsProfile was set to HiDef instead of Reach. Feel free to ignore me!
Ah, thanks for your message! Nice, that you already found a solution.
Sometimes it’s also possible to resolve such errors when compiling the shader with a different target or feature level like ps_4_0_level_9_1.
Have a nice day 