Setting the start position of the output window.

I have just installed MonoGame as a way to prototype code for other projects. Already though I have one really annoying problem that I don’t seem to be able to find a solution for. With a WinForms project, you can set the start position for when the programme runs but I can’t do that with the MonoGame project. As a result, every time I run the project, the control bar of the window is hidden behind the taskbar… so I can’t move the window away from the code.

As an artist/designer/programmer, I have a lot of applications that I need access to, so I hate having the taskbar appear and disappear all the time with autohide. I found one solution where you can cascade the windows to get access to it but if I have to do that every time I run the project, it’s going to get old really, really quickly.

I run a dual-monitor setup so I prefer to move the output to my second screen while it is running, so I can reference the code and output at the same time. Does anyone have any suggestions/tips on how to get round this? I even tried moving VS to my second screen but the monogame window still opened on my primary screen, hidden behind the taskbar.

In Initialize(), you can set the game window’s position. For example:

Window.Position = new Point(1000, 300);

3 Likes

Brilliant, thank you. It’s a good few years since I have used XNA, so all my knowledge (what little there was of it) has been archived in a place my brain doesn’t want to go, so I am stumbling over simple things.

Your reply was very much appreciated. :slight_smile:

This API was actually not available in XNA :slight_smile:

Also, if I take words from your post here and search google for “monogame set window start position”, I get the answer in the first search result:

https://www.google.com/search?q=monogame+set+window+start+position

I’m not trying to discourage you from asking questions here, but just want to point out that quite a few answers are already out there for MonoGame. I find stuff all the time.

“You could have just Googled it” is a horrible phrase to imply to people new to a site. And when it is used on a question that has already been answered, it makes you look like someone who goes round new posts, looking for people to “correct”.

I don’t want to discourage you from posting answers but when I start typing, I get a big yellow box that asks me “Is your comment contributing to the discussion?” and tells me to “Criticise ideas, not people”. Posting comments like you did, adds nothing to the discussion but does criticise me for not using Google more extensively. Maybe that yellow box needs to be permanently displayed.

So that type of post does discourage people from asking questions but even more damaging, is it discourages people from even wanting to be part of a community. I used to moderate a support forum for 14 hours a day. I used to see the same questions over and over again but not once did I ever say “You could have just Googled it”… In fact, any posts of that kind were removed and the posters advised that it wasn’t tolerated. People deserve a little more respect than that, no matter how lazy they might appear to be.

People sometimes take shortcuts, especially people who have less time in the day than they need to do all the tasks they are working on. I am currently working on around 5 personal projects at the same time. Those people don’t need correcting, then need helping and in a way that portrays the community in a positive light. An intolerant community damages the reputation of the API it belongs to and I’m not sure if that’s something the creators of MonoGame would appreciate.

The first couple of answers I found told me to set “GameWindow.Position”. The Game1.cs and Program.cs show no mention of “Window” being defined, and if I type “GameWindow”, it goes Green as it’s a type, not a property… so I simply asked the question, just for clarification.

I’m sorry you didn’t like that but you could have just followed site etiquette and ignored my question. Next time I will use more search options, because I really don’t want to ask anything else on here… so thank you for your welcome. I’ve probably broken the same site etiquette with my reply but as I’m not coming back, it really doesn’t matter.

@LeeC2202 You took that way too seriously.

I even reread my post for fear that I used disparaging language, outright insults or anything else that would justify such an extensive response, but it’s not there. Maybe I just caught you at a bad time.

And one doesn’t have to quit an entire community or project even if you did have 1 bad experience.

In addition to what @Kimimaru said above, here’s how you make sure your game window is above the Windows taskbar:

// within Initialize():
var form = (System.Windows.Forms.Form)System.Windows.Forms.Control.FromHandle(game.Window.Handle);
form.TopMost = true;

Note:
I’ve been told that using Windows.Forms with MonoGame, due to how the using import adds too much overhead (or some such problem), is generally not recommended. However, in this particular case, this is the only method I know of that ensures that the taskbar goes behind the game window.

1 Like

This is not true. There’s no overhead. Where did you find this information?

If I remember correct, back in the XNA days it was not advised because it would break compatibility with XBox. I’d imagine the same would be true with MonoGame if you intend to build your game for multiple platforms; however, it’s using Xamarin to resolve the .NET dependencies so it may well be that there’s some “magic” there that takes care of it. That magic being, most likely, a different implementation of System.Windows.Forms for different platforms.

If you really didn’t trust it though, it’s pretty easy to implement a solution yourself by creating some sort of window positioning interface, then implementing that on your Windows build with System.Windows.Forms and passing that as a dependency to your game.

I suspect that you actually probably don’t have to worry about it. It should be easy to test though… create yourself an Android app and do stuff with System.Windows.Forms, then run it and see what happens :smiley: