views:

377

answers:

2

I have a C# application which consists of 3 forms:

1: Battleship Game GUI
2: Network GUI (does client/server connections)
3: Chat GUI

Form 1 is loaded first. When the user selects setup network, Form 2 is displayed.

Chats are displayed when the user opts to send a chat or when a chat is received.

I would like Form 2 to process all the messages and pass on the relevant messages to the relevant GUI to decode the message further.

I'm still at an early stage of development. At the moment I am trying to use delegates to communicate between the forms.

Is this the best way of doing this? What are the best practices regarding components of an application sending messages to each other?

+4  A: 

ikurts, this is definitely not good practice. Your UIs, however many there are, should have absolutely nothing to do with communications. You should:

  • read up on model/view/controller in .Net to see a good way of structuring a project like yours
  • read up on using threading for your communications, ought to be simple

It sounds like you want to follow best practices in setting up your app. You're gonna get a lot of feedback on this question i think and all of it will sound something like this. Do yourself a favor and follow it. And stay away from comm logic in forms!!!

A few more thoughts:

i'm not sure why you want to break this up into three screens when two seem logical: 1) network settings dialog 2) game play dialog that could accommodate both the battleship UI and your chat UI. This configuration would also simplify your structure since only one screen, the gameplay/chat screen would need to be updated. The settings dialog would be just that.

Here is an example of a threaded chat application on CodeProject which would server well as a code base to get started. i imagine that your battleship moves would simply be "special" chat messages that specify board hits.

Also, here's an example of a network enabled tic tac toe game that may yield clues as to developing a client/sever game.

Don't shy away from what seems difficult! My suggestion is to first write a chat/communication client which has no UI, perhaps just console output. Then add a screen and you'll see that you won't have to marry the window to the network stuff.

Good luck!

More links:

Here's a nice discussion about MVC/MVP that may enlighten your architecture. And here's another... From a different angle.

Paul Sasik
your info has been of great help. thanks. i will leave this thread open as i still would like info regarding multiple forms inter communication. im employing multiple forms to provide a certain look n feel in the app.
iEisenhower
i feel the need for declaring a game structure that encapsulates and separates game logic from UI logic. i think thats what model/view/controller does. but i havent found any tutorials for that. could you please point some out of a book that focuses on separating app logic from UI logic? thanks.
iEisenhower
@ikurtz: i added some MVC tutorial links into my answer. If you're really bent on two forms communicating directly, you don't need anything more than one holding a reference to the other. It's easy but there's risks of spaghetti coding and potential deadlocks if you end up with circular dependency. Good luck in any case.
Paul Sasik
thanks for all the info. it is of great help.
iEisenhower
i have been programming all application logic at the same time thus losing the clarity between model/view/controller.my forms should really be view. the actual game logic in model. and the controller would be the code needed to exchange data between model and view.am i right in thinking this?
iEisenhower
You're close. The forms are definitely the view. i would put game logic into the controller and use the model for getting the network data. This is all loose btw. You do not have a classic MVC app, the pattern is just a jumping off point to help you separate concerns in your app.... Darn. There's a term i forgot to mention sooner: Separation of Concerns. It's more general and useful than simply saying you should be using MVC. Think like this: What is my class/object concerned with? Form = display, Controller = logic, model = data and data transfer.
Paul Sasik
thanks again. will take a few days to read up on all the info and hopefully come up with something sensible. the work i have so far isnt completely wrong but i need to catagorize them correctly.so far i have been making tiny apps dealing with specific issues like adding runtime controls, controlling app behaviour, updating app state, multimedia issues at runtime etc etc. now that im almost out of ideas for these tiny apps i need to start to design using logic and not bundle all the code in one place, as this completely bypasses the OO concepts! i mean it is still OO but reuse value is none.
iEisenhower
+1  A: 

You should separate the comms into a different class (not in a Form).

However, to keep your forms "in sync" with each other, you can use c# events (and delegates to handle them) to inform one form that something has happened on another form. You're using events to handle all the form actions (mouse button clicks etc) already, so you should have a basic idea of how it works, and there are lots of articles on the net about "c# events" and "c# event handling" (there are some search terms for you) that will give you more info, so I won't go into detail here. The advantage of events is that the system remains loosely coupled, and anybody can subscribe to them, so it's really easy for you to add a fourth form in the future and get it to "listen" to the information it needs.

Jason Williams