search

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.
Other
287 stars 28 forks source link

Events >.> #7

Closed SpiceyWolf closed 6 years ago

SpiceyWolf commented 6 years ago

Hey, thought I should mention as looking through your documentation it still requires that old poopy method of inheriting a class to generate a control to use for rendering when you could simply have an invokable event that people can hook onto (The native winforms style development, after all you did all this in trying to use winforms to begin with didnt you? :P ) Ill throw a fork with that change u can pull from - Also as stated on the MonoGame thread concerning this, if they fix the stupid artificial block from using GL with multiple MonoGame Contexts im totally down for fixing up the GL support on this too :D

SpiceyWolf commented 6 years ago

I uploaded on the fork, And since Clearing is a required step I added functionality to use the BackColor of the control as a means of automatically setting what the ClearColor would be (And having the Clear automate on the draw code)

SpiceyWolf commented 6 years ago

Made an update simplifying how i was doing the event (And correcting bugs i didnt realize were there till compile attempt, stupid VS delayed error reports) And decided to go ahead on the Update Functions i didnt know you had to Event as well so everything can be done external of inheritance, (But still allowed via inheritance)

BlizzCrafter commented 6 years ago

Hey and thanks for posting your suggestions!

The inheriting of specific classes to generate custom (updatable) render controls, which are draggable from the ToolBox in Visual Studio is a design philosophy for MonoGame.Forms. Note that also only the custom controls created by the user will appear in the ToolBox for a better overview and clearness.

I also created the GFXService class which becomes available when inheriting from a DrawWindow or UpdateWindow which makes it easy and clear to use functionality from the MonoGame.Framework.

Example: DrawService.

If you take a closer look at the DrawService class, you will also note that the clearing of the back buffer already was automated and is publicity settable.

But I like your idea of connecting this color with the native BackColor property from the UserControl and I will keep that in mind.

SpiceyWolf commented 6 years ago

Thats fair, Design Philosophy or not i submit you the change just because it simplifies the work as well keeps the usage and design style of winforms consistent which I know plenty of people (I would argue most but thats debatable) would appreciate the event driven version more.

I take no offense if you don't want it however, I intend on using my old version anyway I just gotta decompile the stupid thing cause I lost my original source -.-

Also super sorry if it seemed like I hijacked your thread xD TLDR: I may not have came off clearly and appeared hostile toward the MonoGame Developers and contributors and pissed someone off and had to get a bit more in depth to hopefully clear up the confusion ; Aside I did try to specify more in depth the issues you would encounter between consistency getting GL and DX to work in the control why it was.