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.