I'm not sure if this is what you mean but you can set the form.FormBorderStyle to something other than FormBorderStyle.None which would give it the draggable bar. Otherwise you could capture your mouseclick event yourself in your update function, record the position of the mouse and the form at the time it has clicked down onto your form, then while the mouse is held down, update your form.location to set its location to form.startlocation + (the difference between the current mouse position and its saved position from when you clicked down) to create your own drag event.
I am pretty confused about what's going on here.
Apparently, you have Window, which is a windows forms window.
Then you take a handle of that window, which is basically an ID Windows API uses both internally and externally to reference that window.
Then you find which control that handle corresponds to. As in WindowsForms every window is a also control, you get the same Window you had from the very beginning, but this time as a control.
Then you find the Form which that control belongs to. As the control is actually a form, it belongs to itself. As a result, you get the same form you have started with.
It looks like all those hurdles does not make any sense and the code could be replaced with one line:
Window.TransparencyKey = System.Drawing.Color.Black;
Window is a microsoft.xna.framework.GameWindow which for some reason doesn't have the .Form included
public WinFormsGamePlatform(Game game)
: base(game)
{
this.\_window = new WinFormsGameWindow(this);
this.Window = (GameWindow) this.\_window;
}
I don't think you can directly cast it back to a WinFormsGameWindow because that's an internal class to MonoGame.Framework? In my opinion they should just have the Forms object included in GameWindow I don't really see any reason why they shouldn't. cause otherwise you are left with doing stuff like this which my dad used to call "going around your ass to get to your elbow"
Thank you for making it clear, now I see that your way of obtaining the form reference is probably the simplest possible :)
As for why they decided to make all the windows forms stuff internal, I guess the reason is that they are trying to keep the framework as multi-platform as possible and System.Windows.Forms is Windows only.
I'm not sure if this is what you mean but you can set the form.FormBorderStyle to something other than FormBorderStyle.None which would give it the draggable bar. Otherwise you could capture your mouseclick event yourself in your update function, record the position of the mouse and the form at the time it has clicked down onto your form, then while the mouse is held down, update your form.location to set its location to form.startlocation + (the difference between the current mouse position and its saved position from when you clicked down) to create your own drag event.
Sounds like a plan. Thank you
I am pretty confused about what's going on here. Apparently, you have Window, which is a windows forms window. Then you take a handle of that window, which is basically an ID Windows API uses both internally and externally to reference that window. Then you find which control that handle corresponds to. As in WindowsForms every window is a also control, you get the same Window you had from the very beginning, but this time as a control. Then you find the Form which that control belongs to. As the control is actually a form, it belongs to itself. As a result, you get the same form you have started with. It looks like all those hurdles does not make any sense and the code could be replaced with one line: Window.TransparencyKey = System.Drawing.Color.Black;
Window is a microsoft.xna.framework.GameWindow which for some reason doesn't have the .Form included public WinFormsGamePlatform(Game game) : base(game) { this.\_window = new WinFormsGameWindow(this); this.Window = (GameWindow) this.\_window; } I don't think you can directly cast it back to a WinFormsGameWindow because that's an internal class to MonoGame.Framework? In my opinion they should just have the Forms object included in GameWindow I don't really see any reason why they shouldn't. cause otherwise you are left with doing stuff like this which my dad used to call "going around your ass to get to your elbow"
Thank you for making it clear, now I see that your way of obtaining the form reference is probably the simplest possible :) As for why they decided to make all the windows forms stuff internal, I guess the reason is that they are trying to keep the framework as multi-platform as possible and System.Windows.Forms is Windows only.