Xbox LIVE Indie Games
Sort Discussions: Previous Discussion Next Discussion
Page 2 of 2 (50 posts) < Previous 1 2

A better way to embed XNA into WinForms (full source)

Last post 7/29/2011 2:11 AM by Ant2010. 49 replies.
  • 12/11/2007 6:09 PM In reply to

    Re: WinForms with minimal fuss

    Brandon Bloom:
    I have no idea what the team is planning, but it is my suspicion that whatever solution they come up with will certainly not be 360 compatable and will live in a seperate, Windows-only assembly.

    If I had my way, it would take the form of a XnaView control which you could simply drag out of the toolbox onto a form. That would be nice because then you could easily make multiple viewports and such, but is actually substantially more sophisticated to setup and doesn't directly match the semantics of the Game class.

    It's never as easy as it first looks, especially when you have to write framework code that is going to be used by such a wide range of people. Even the seemingly simplist things have complications which can easily be overlooked by those who are not accustom to the framework-writing frame of mind. For example, a lot of people asked "Why isn't the chat pad supported in v1? Isn't it just a keyboard? It should work the same as any keyboard". The response was "because you can have more than one of them" and people said "oooooh. right." :-)

    I made a XNA Viewport control that you could drag out of the toolbox onto a form. I was trying to get XNA to work with VS2005 in VB and I thought it'd be handy to be able to host XNA as a control on a form. The project kinda died due to not being able to use the content pipeline with VB, but the control works... at least with my tests and limited knowledge of XNA. Anybody's welcome to check it out.

  • 12/15/2007 8:46 AM In reply to

    Re: WinForms with minimal fuss

    Well, this is another way of doing this:

    http://www.youtube.com/watch?v=vc72eYcQODc

    source:

    XNAFormsEditor

  • 12/15/2007 10:56 PM In reply to

    Re: WinForms with minimal fuss

    I've been writing an article for a week or so regarding how to use XNA GS and VS2008.

    In one of the sections (entitled "XNA And WinForms: A Simple Approach") I present a way to avoid all the "fuss". Still, I consider that getting control of the GraphicDevice is the best option, but as I say in the article, I'm lazy ;)

    http://www.thecodeproject.com/KB/game/XNA_And_Beyond.aspx

    BTW, this is my first article for "The Code Project", so please be nice ... :)

     

  • 12/27/2007 2:35 AM In reply to

    Re: WinForms with minimal fuss

    Gibba:
    The last bit of code was very nice, although it doesnt quite serve my purpose and im too much of a c# noob to get it working.

    I've created my own form and i want to display the XNA environment in a picturebox or equivalent, so i can place controls down the sides.  Problem is the main XNA window still opens as well as my form, although the XNA window is not updated.

    Anyway to stop the main XNA window opening and use a control to display the XNA on my custom form?

    To 'hide' the window simply put the following code in your Initialize method:

    protected override void Initialize()
    {
    // TODO: Add your initialization logic here

    base.Initialize();

    Form gameWindowForm = (Form)Form.FromHandle(this.Window.Handle);
    gameWindowForm.Shown += new EventHandler(gameWindowForm_Shown);
    }

    void gameWindowForm_Shown(object sender, EventArgs e)
    {
    ((Form)sender).Hide();
    }
  • 12/28/2007 11:45 AM In reply to

    Re: WinForms with minimal fuss

    I havent tried this, but I would suspect you could just as easily set the Forms visible property to false as well.
  • 12/28/2007 3:39 PM In reply to

    Re: WinForms with minimal fuss

    I have updated my article.
  • 5/14/2009 3:55 PM In reply to

    Re: A better way to embed XNA into WinForms (full source)

    I may be being a tad cynical here but I wouldn't hold my breath on seeing Winforms support being high on the XNA developers list of things to implement. I assume such features would only be applicable to the Windows platform and not Xbox360?

    As far as I can see the road down which XNA will develop with regards to more Windows functionaility will always be hampered by the fact that one leg is shackled to the Xbox360 requirements. Therefore any new features that only target the Windows platform will be dropped (or at least postponed) in favour of features that work on both platforms.

    As much as this bothers me, there are likely sound reasons for this limited development. As soon as you start introducing large numbers of platform-specific features in an API you introduce a split in the development path, which then causes issues for maintainability and slows down development progress for both platforms. Unless of course you also increase the size of the XNA development team to handle this.

  • 5/15/2009 1:08 PM In reply to

    Re: A better way to embed XNA into WinForms (full source)

    I think you are replying to a 2 year old article (?)

    And the team has given this: http://creators.xna.com/en-US/sample/winforms_series2 to help out, from which you can in not too many steps hack together your own winforms application with a game running in it (useful for edtiors n similar)

    :)
  • 2/15/2010 11:00 AM In reply to

    Re: WinForms with minimal fuss

    just to save people the fuss of going through the (not really much of a) hassle of signing up for that site to submit stuff with... here's an xnaCC solution link that was provided as a response to the link Z posted:

    http://creators.xna.com/en-us/sample/winforms_series1

    thanks Z, and good luck everyone!
  • 6/28/2010 5:36 AM In reply to

    Re: WinForms with minimal fuss

    I really dislike that solution^, it's a hack to shut us up as far as I can tell, so I use a version created by someone in this topic(I believe), that is much less of a hack in my opinion. (ie, it doesn't mess with AppIdle, or use Stopwatches, etc,.. It just changes the drawing surface to something else..)

    Anyways, I just wanted to post this updated version by me, that fixes a few problems I had with the original.. (Scaling issues, and other minor stuff.)

    This is source only, nothing assembled, check it yourself, no viri, etc,. Credit goes to the original creator, I just reworked it a bit.. (It was written under C# Express 2008\XNA v3.1)

    Download

    ---

    Hints:

    Just use the game class as usual, the form, and game class both have built in refs to each other, so communicate between them using those refs, changes in the form designer to the Viewport(picturebox), namely, resizing it will reflect on the game window(xna viewport\directx drawsurface\what have you) automatically at runtime.

    You should probably shutdown via the Form(any normal method will work, X'ing out, etc.), the form will shutdown the Game class. (I hooked the FormClosing event up, and have it shut it down..)

    From game class you can do this..

    if (Keys.Pressed(Escape)) // Pseudo code..
      WinForm.Close(); // This part is accurate..

    I forgot and left the default exit code in the game class, don't use it.. (It probably works, but I don't think it disposes the form properly, so call it like above, and it should get disposed properly.)

    To get accurate mouse coordinates, hook the viewports(picturebox) MouseMove event up, and get the e.X\e.Y values.. (You can still use the XNA input stuff for mouse clicks though, in fact I recommend doing that..)

    Hope this helps someone out. :)
  • 12/19/2010 12:18 AM In reply to

    Re: WinForms with minimal fuss

    SharpN:
    I really dislike that solution^, it's a hack to shut us up as far as I can tell, so I use a version created by someone in this topic(I believe), that is much less of a hack in my opinion. (ie, it doesn't mess with AppIdle, or use Stopwatches, etc,.. It just changes the drawing surface to something else..)

    Anyways, I just wanted to post this updated version by me, that fixes a few problems I had with the original.. (Scaling issues, and other minor stuff.)

    This is source only, nothing assembled, check it yourself, no viri, etc,. Credit goes to the original creator, I just reworked it a bit.. (It was written under C# Express 2008\XNA v3.1)

    Download


    Unfortunately, the link to your code seems dead now :(

    I'd love to see what you did - is there a chance you could upload again please?
  • 7/15/2011 5:35 PM In reply to

    Re: WinForms with minimal fuss

    I'm having a problem, and I am going to try this but before I do I think I should ask this noobish question. I am making a tic tac toe game in xna for school. I want to draw a windows form and use that as the game board. Will this code work in doing that, if not how do I tell xna to draw that form I created. I am using Visual Studio 2010 Professional (It was free from my school.) with XNA 4.0 any help would be appreciated.
  • 7/15/2011 5:52 PM In reply to

    Re: WinForms with minimal fuss

    What's wrong with using the method recommended by the XNA Developers?

    WinForms Series 1: Graphics Device
    WinForms Series 2: Content Loading

  • 7/16/2011 10:48 AM In reply to

    Re: WinForms with minimal fuss

    David Hunt:
    What's wrong with using the method recommended by the XNA Developers?

    WinForms Series 1: Graphics Device
    WinForms Series 2: Content Loading



    Because it cuts off the vast majority of the non-graphics portion of XNA framework.

    Still chugging along with the method I developed all the back at XNA 2.0, only really took minor changes along the way to keep it functional.

    My method goes as follows.

    During the game's constructor:
    1) Grab the form via Control.FromHandle(Window.Handle).
    2) Subscribe to the Shown and LocationChanged events of the game's form.
    3) In the game form shown event, call hide on it.
    4) Location changed uses the same event handler as one that will be used later, important to compensate for some odd movements that occur while it's hidden.

    Inside whatever function you use to pass the target form to the game:
    1) Subscribe to Move, ClientSizeChanged, ResizeBegin, ResizeEnd, Activated, Deactivated, and FormClosing events.
    2) Call your event handlers for target form move and client size changed.
    3) Set Microsoft.Xna.Framework.Input.Mouse.WindowHandle to the new window's handle (important for mouse/keyboard input).
    4) Even if your just rendering onto a control in the form, you must do the above 3 steps if you expect input to function correctly, especially mouse input.

    Inside the target form event handlers:
    1) Move - Calculate the new location of the xna game form with: target form screen location - game form screen location - game form location. This compensates correctly for any strange window themes the end-user might have running.
    2) ResizeBegin - just set a local bool (I'll call it resizingTargetForm) to true, need to know while it's being resized.
    3) ClientSizeChanged - inside a try statement, compare back buffer size to client size, if client size is larger set the PreferredBackBufferWidth to that new size, also set a bool (I call it resetGraphicsDevice) to true. In the finally block of the try statement, call the target form Move event handler.
    4) ResizeEnd - set that resizeTargetForm to false, if resetGraphicsDevice is true, set it false and call ApplyChanges() on the GraphicsDeviceManager object.
    5) FormClosing - just call Exit() if Cancel is false in the event args, important if you expect the game to close.

    Inside BeginDraw:
    1) If your target form or control is not visible, just return false.
    2) Perform the same steps as done in ResizeEnd if resizingTargetForm is false, this happens when you use things like panels as the render control.
    3) If base.BeginDraw returns true at this point, good to go for rendering, just be sure to update GraphicsDevice.Viewport with the control's client width and height along with any projection matrices your using.

    Inside EndDraw:
    1) Create a (XNA) Rectangle with the client width and height.
    2) Call GraphicsDevice.Present(rectangle, null, target form/control Handle property).
    3) Do NOT call base.EndDraw(), that will reset in Present being called on the xna game form, which is useless since it's hidden at this point.

    Yeah that's a big hack, but it works fantastically. I have built entire editors using that method with only one thing the clients have noticed, the xna game form flashes on the screen for a short period before the switch over occurs, usually less than a second. The magic on how it keeps the mouse synced is that, even after you switch the xna mouse handle to the new form, it's still using the xna form for it's coordinates, so the bulk of the above is just making sure it stays properly aligned (even though it's hidden).
  • 7/28/2011 7:15 AM In reply to

    Re: WinForms with minimal fuss

    I've been trying to make a game editor and I throught that WinForms Series 1: Graphics Device as mention above would be the way to go. 
    But when I try to use the mouse wheel the value is always 0.  I've tried everything mentioned in these posts like using the control handle but nothing worked.
    I might give your method a go.  Do you have the code for viewing by any chance?
  • 7/28/2011 8:05 AM In reply to

    Re: WinForms with minimal fuss

    You need to listen to the mousewheel event on the form that is hosting the XNA component, you also need to make sure that form has focus as well.
  • 7/28/2011 8:29 AM In reply to

    Re: WinForms with minimal fuss

    If you mean using something like

    this

     

     

    .MouseWheel += new System.Windows.Forms.MouseEventHandler(this.Form1_MouseWheel);

     


    private

     

     

    void Form1_MouseClick(object sender, MouseEventArgs e)

     

    {

      ...

     

     

    }

    using the windows forms mouse and not the XNA one.

    Tried that and it's not picking it up, won't even pick up the click event either?!
    Maybe because I'm using the XNA Mouse object in the XNA control - which I need to do.

  • 7/28/2011 9:04 AM In reply to

    Re: WinForms with minimal fuss

    I wasn't able to get any mouse info when I used the XNA mouse system, which is why I ended up using the events.
    It should be simple but it took a bit of trial and error to find with component to hook the event off.
  • 7/28/2011 9:47 AM In reply to

    Re: WinForms with minimal fuss

    Did you end up getting the mouse wheel to work?
    I can use events to catch the other mouse events, but not the wheel.
  • 7/28/2011 9:51 AM In reply to

    Re: WinForms with minimal fuss

    Yeah, once I worked out which form to hook the event off it all worked fine.
  • 7/28/2011 9:59 AM In reply to

    Re: WinForms with minimal fuss

    You probably have a different setup, but, which form/control worked?
    I have the xna control in a split container control, which is in a tool strip control on a form.
    I tried attaching the Mouse Wheel event to the form and to the xna control but that didn't work.
    The other mouse events work just fine when attached to the xna Control, they won't work on the form.
  • 7/28/2011 10:52 AM In reply to

    Re: WinForms with minimal fuss

    Remembering back (I don't have the code to hand) I had to put it on my parent form (I'm using dockpanels, so this could make things completely different).
    It was a form with 2 scrollbars, 1 text box and the XNA component.

    I couldn't get it to give me the mouse scroll event when I attached it to the XNA control which is where I tried first.
  • 7/28/2011 3:28 PM In reply to

    Re: WinForms with minimal fuss

    I think that the problem is that scroll events are only reported when the Mouse's WindowHandle is for a control that is currently selected. You can call Select() or Focus() on it as described here.


  • 7/28/2011 3:58 PM In reply to

    Re: WinForms with minimal fuss

    I can also only get the mouse wheel to work on the control that has focus.  Even then I have trouble with reliability and you have to remember to click in the model view window.

    For what it's worth the source code is available in the following project:
    http://code.google.com/p/3d-model-prep/

    It works OK for an editor only used by me but I would be reluctant to release code using these techniques as a finished product!

    Regards
  • 7/29/2011 2:11 AM In reply to

    Re: WinForms with minimal fuss

    Looks like I need to set the focus to the XNA control on th mouse enter event.  Then I can catch the mouse wheel event for that control.  That seems to work.
    The XNA mouse still has the mouse wheel as 0 for some reason, but I can still use Mouse.getstate() for the other mouse functions.
    Odd that the mouse works this way.  What is needed is a Windows only version of XNA - that would make things easier.
Page 2 of 2 (50 posts) < Previous 1 2 Previous Discussion Next Discussion