CODEWITHSUNDEEP
c#.netwinformsipcmessaging
iTEgg
iTEgg

Reputation: 8340

c# forms communication

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?

Upvotes: 1

Views: 1450

Answers (2)

Paul Sasik
Paul Sasik

Reputation: 81537

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.

Upvotes: 5

Jason Williams
Jason Williams

Reputation: 57952

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.

Upvotes: 2

Related Questions