   Server GUI
  I have a working console server that works fine as a console server.  I want to get rid of the console and add a windows form GUI to it.I have the GUI working and it starts the server with the correct parameters, but, the GUI locks up and stops responding to input once the server is started.Any ideas?   
  The classic solution is to put all network activity in a separate thread, or to use a non-blocking approach.Personally, I like the separate network thread - you can react to the thread terminating unexpectedly (catch exceptions) and allow your persistance mechanism to back up your gamestate.;  Ok, I've begun the multi threading process.  This does appear to be the solution to my problem.  Thanks.Now, one more question.  If I don't specifically assign a process to a thread, is it, by default, assigned to a main/default thread?  I'm writing this server in C#, using .NET 2.0, if it matters.~rantI do hope these questions don't sound too stupid.  I am completely self taught, so there are lots of holes in my knowledge and, in my opinion, MS's API documentation is practically useless.  They've gotten so used to obfuscation, even their documentation is obfuscated.rant~[Edited by - DwD on May 24, 2006 7:33:14 AM];  I have NO knowledge of .NET or C#. I'm afraid it's old skool C / C++ for me. When you create a thread (in C++ windows api) you specify a funtion pointer to a threadmain function. The OS level thread is created as a child of the process that created it (actually the process forms a primary thread when started, so you'll notice two threads in your debugger) and executes the threadmain function. Destroying the process should terminate the child threads, but may not close files, or perform any cleanup.It's bad practice to uncleanly terminate a thread. It's much better (and safer) to have a state variable to trigger the thread to die properly and do whatever housekeeping it has to do.I have a thread object, which for the sake of illustration consists of three virtual functions a single pure virtual, and a flag. There's initialise( ), run( ), and m_bQuit. The pure virtual is update( ).The threadmain function takes a pointer to an instance of a thread object. It calls initialise( ), then run( ), then shutdown( ). run( ) enters a while(!m_bQuit) loop, which calls update( ). update( ) is implemented in derivations of the thread class.An application wanting to stop a thread therefore sets its m_bQuit flag, and the thread will call its cleanup stuff in shutdown( ). Obviously, you can put a lot more control in than that, but it's the general idea. You'll need to implement a number of things on top of this - mutexes for making stuff threadsafe, and at least a waitForThread( Thread* pThread ) style function so you can block until a particular thread is done if you need to.;  .Net threading (at least in 1.1) is a bit basic. Basically, any method calls you make are in the same thread as you are when you make them; only the method you pass to the Thread constructor (and anything it calls) is in the other thread.If you're using .Net then asynchronous sockets are probably the way to go. Look up Socket.BeginReceive and friends in the .Net documentation.   ;  Most people don't embed GUI's directly into server apps, for various reasons, one of which is to avoid the kind of complexity and trouble you're running in to.   ;  Bob and winterdyne;Thanks for the help guys.  I have the GUI and the server working now.  With your help, I know that I need to make sure all threads are cleaned up before I allow the application to exit.Mike;I may be incorrect with this, but, I don't think I am embedding a GUI into the server.  Rather, I am including a GUI with the server. I could exit the GUI and leave the server running in the background.  I don't think I'll do this though.  The reason I am including a GUI, is to make it simple for others to operate.  The server will be distributed to end users with little or no ability to write a batch file and pass correct parameters.  With a GUI, clearly explaining the required parameters, and with examples/default settings already in place, I'll spend less time supporting and answering questions.  At least, this is my hope.... and besides, its prettier  ;-);Quote:Original post by DwDMike;I may be incorrect with this, but, I don't think I am embedding a GUI into the server.  Rather, I am including a GUI with the server. I could exit the GUI and leave the server running in the background.  I don't think I'll do this though.  The reason I am including a GUI, is to make it simple for others to operate.  The server will be distributed to end users with little or no ability to write a batch file and pass correct parameters.  With a GUI, clearly explaining the required parameters, and with examples/default settings already in place, I'll spend less time supporting and answering questions.  At least, this is my hope.... and besides, its prettier  ;-)You should be able to do both. Write a completely seperate GUI app, which COMMUNICATES with your game server - don't actually have the GUI app BE the game server. There are many advantages to this, including performance issues.Consider making your server completely data driven off data pulled from a database. Then you can throw togeather a very simple web app which allows a user to modify and adjust settings. Web apps are perfect for this situation for many reasons (distribution, commonly known UI, etc.).   ;  Yeah, in general a GUI on a server app is not a good idea, because there's a good chance the server machine will be in a rack somewhere with no screen! It's good practice to provide some remote admin capability anyway, so you might as well administrate it 'remotely' from the local machine too instead of writing two UIs.Having said that, the advice about asynchronous networking still holds, because you don't want to be blocking database access/remote admin/other clients anyway.There aren't really performance issues with adding GUI to an app under .Net AFAIK.   