Kal_jez, one thing you can do is just add event handlers to the control form that are found in the game form. For example, add Button_Click() function to the Game class, and then set frmContro.button1.click += new Eventhandler(Button_Click);

One question though, is where you are setting the threading model? You said in Main, but for me it always fails to change the threading, and it seems to work without it.

Thanks!

Note that xna does not depend on the game framework. If you're solely targeting Windows and find the Game class too inflexible, choosing to not use it is a very reasonable thing to do. The game class doesn't do anything magical that you can't do yourself. And as an MS developer admitted to me, the Game class isn't designed to be very flexible. It's just there so new users can jump straight in.

Manually initialising the graphics device is actually very easy. Much easier than managed directx. Incidently, you don't need to use the Game class on the xbox 360 either: you can just pass null to the graphics device constructor for the window handle.

If you're happy with your current method, by all means stay with it. I just mention this because I prefer the greater flexibility it gives you when doing something unusual like rendering to an external window or incorporating xna into an existing engine. When I try to do this with the Game class I feel like I'm trying to cram a cube through a round hole.

If that's the case, then does the 360 see the app any differently than the PC in terms of how the device is setup? I have not compared the default code created from choosing a 360 and PC project, but I was under the impression that everything underneath was handled differently. Now I think about it, really, that should all be handled under the abstraction layer that is DX, and not within the C# code itself. Is there by any chance another thread of these conversations we can reference?

When setting up the device manually, the only difference between the pc and xbox is that in windows, you pass the handle to the window to the GraphicsDevice constructor, while on the xbox you simply pass null. Naturally you also need to account for different display modes between the console and pc, but you need to do that whether manually managing the device or not.

Here's a thread where I contributed a very minimalist example of using xna in a form.

For the xbox you'd pass null in place of form.Handle.

I'm interested in what people have to say about the approach to the problem presented by The instruction limit: http://www.zaknafein.hjcrusaders.com/?p=24

It has the obvious flaw of the programmer having to copy and post all the form+designer code from the Form file to the WindowsControl file, but the first comment posted on the page is interesting in that he says that this is not really necessary, however he does not expand much. Does anyone get what he is pointing out?

This blog entry is an example of what I was referring to: someone being too attached to the game class when doing something unusual. A ton of ugly hacks result, as seen there. Using reflection and manually duplicating the Game framework? Wow, that's ugly.

The nice thing is, you don't need the game class to implement the content pipeline. All the ContentManager class needs is an IGraphicsDeviceService to provide it with a GraphicsDevice.



Then you create the graphics device manually as I showed previously. Then create the content manager as follows:

mContentManager = new ContentManager(new GraphicsDeviceService(mGraphicsDevice));

That's it, you now have a working content pipeline. I confirmed yesterday that this works on the 360 (finally broke down and bought one :P ).

Quote:Original post by JustHeath
It has the obvious flaw of the programmer having to copy and post all the form+designer code from the Form file to the WindowsControl file, but the first comment posted on the page is interesting in that he says that this is not really necessary, however he does not expand much. Does anyone get what he is pointing out?

The commenter was right. Copying and pasting the code like that is sloppy (as is the rest of this guys code, I must say). He can just make the panel accessible through a property in the form. I don't know what the problem is with competing input focus: a control and it's parent window don't compete like that. What he describes would occur between say, a MDI child window and it's parent window, but not here. There are minor complications, such as the fact that keyboard input is received through the form, while mouse input is received through the panel, but that's perfectly manageable.

[Edited by - gharen2 on June 28, 2007 3:02:10 PM]

What about a scenario where you have developed something integral to both the game and the editor (such as a tile engine) as a GameComponent? How do you compensate for something like that without either rewriting your code or writing a specialized version of the component for use without a Game object?