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?
ikurts, this is definitely not good practice. Your UIs, however many there are, should have absolutely nothing to do with communications. You should:
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.