Hi All,
Hi,< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
I have 3 questions that I have described here, I will be very much thankful to you if you can provide me some pointer for it.
Chats, Forms, multi-threading
We are building Chat like application using Forms and as a result our programming is becoming complicated to display messages received on different threads in the chat window (due to STA requirements of Forms). Is there a way to build Chat like application WITHOUT using FORM, so that one can use free threading model (The link http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpguide/html/cpcondevelopingmultithreadedwindowsformscontrol.asp has statement “Outside Windows Forms, classes in the .NET Framework use the free threading model. For information about threading in the .NET Framework, see Threading.”). IS THERE ANY WAY TO BUILD CHAT-like application without having to do complicated programming to satisfy STA requirements)
Socket and multi-threading
Socket class documentation says that it is not thread safe. We understand that if do simultaneous sends on ONE socket then it will be a problem (or simultaneous receive). Can we create TWO threads on OUR OWN such that one will do SEND and one will do RECEIVE using the SAME socket reference This means that two threads WILL BE in the same SOCKET object – one doing receive and one doing send. We know we can use asynchronous calls on the socket to achieve this but whether we can do this using our own threads. Any pointers to official documentation that shows this is permissible
Saving the state of UI
User can adjust the size of columns of a table or the position of splitter in UI. We want these adjustments to be remembered when we restart the application. Currently, we are saving these adjustments by the user in an XML and saving that XML. We read the XML upon restart and make calls to set the adjustments. This approach becomes difficult as we add more controls and more settings can be made by the user. What other techniques can be use to save (perhaps automatically) the STATE OF < xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />UI As in Java, can we use Serialization of UI to save its state [Swing controls in java are Serializable while in Net, Forms and Controls are not] Any pointers to articles on various approaches to SAVING THE STATE OF THE ADJUSTMENTS made by the user will be greatly appreciated.
Thanks in Advance,
Thanking you,
Regards,
Mahesh Devjibhai Dhola
"Empower yourself...."
Problem: Forms, Multithreading, Socket and saving state of UI [Forms and controls]
Dustin Mihalko
Great technical design questions. If you haven't already found a resolution to your questions, I would suggest posting the question to a couple of more specific developer forums.
RE: Chats, Forms, multi-threading
Windows Forms code is built on top of Windows(Win32) message pumps, hence the need for STA, single threaded message pumping. If you want to use Windows Forms code from multiple threads, there are APIs to help with the thread transitions (e.g. Invoke, RequiresInvoke, BeginInvoke, etc.). See the ISynchronizeInvoke for more information (http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpref/html/frlrfsystemcomponentmodelisynchronizeinvokeclasstopic.asp).
Typically, when I have designed a networked GUI application, I perform all graphical updates on the UI thread, all data crunching on thread pool threads, and all network access on dedicated background threads (since network blocking is fairly common and unpredictable). This would be a great question for the Windows Forms General Development Forum (http://forums.microsoft.com/msdn/ShowForum.aspx ForumID=8).
RE: Socket and multi-threading
This question would be best asked in the .NET Networking Development Forum (http://forums.microsoft.com/msdn/ShowForum.aspx ForumID=40).
As a general rule of thumb, a large part of the BCL is not thread safe for the simple reason that most application code is not multi-threaded and the performance cost of locking, synchronization, and thread-safety is definitely non-zero. Instead, most of our libraries use an opt-in/pay-as-you-go perf penalty model, where the default is to be as fast as possible, and only incur perf taxes/costs when you need those features.
RE: Saving the state of UI
I would suggest posting this to the Windows Forms General Development Forum (http://forums.microsoft.com/msdn/ShowForum.aspx ForumID=8). Windows Forms classes do support Serialization. However, the Windows Forms team would be more knowledgeable about the best solution for saving your UI state across control evolution, Windows Forms versioning.
Hope that helps,
Stephen [Microsoft Common Language Runtime: Security - Developer]
http://blogs.msdn.com/stfisher