If I am understanding correctly, you use LoadControl in the page load or the init handler and cast it to your user control class. You will now have all the properties avaialable to you including all controls within that user control. Be careful however, if you cache the user control the control that is returned to you from the LoadControl method will be a PartialCachingControl which I am unable to find a way to retrieve any of the properties. I just made a post after you as why is this the case.

I created a User Control that contains a button. I have the handler for the button called Button1_Click etc... Now if I cache this control within a page, the event does not get "wired up" and I am unable to execute the handler for the Click event because the control is cached. How do I get around this?

Hi, In adition, I want to be able to send a message to a specific client - not to all of them together ! When you "accept" a request, you then get the socket, whereby this socket responds solely to the requesting client and no other. But, I need my server to distinguish between the various clients. I want to know who send a message to the server. The client will have to pass some identification from itself to the server within the buffer that it sends. The server can then identify the client. Cheers

Yoe'll have to send a snippet of your code.

Not exactly. Again, in most cases you want to do more than add a message box. Say for instance that when the process is finished, you want to write something to a textbox on that form. You MUST NOT update the textbox in the new thread. That is a no no in Windows. You must only update controls on the windows main thread (the win proc). The article I've already mentioned explains all this. Take the time to read it, it's informative and it helped me alot as well.:)

I'm noy quite sure what you mean exactly? Are you saying that an accept is required for every client? If so, and if I'm understanding exactly your situation, this is not correct. You only need one server socket and it will be "accepting" ALL client requests. Again, all clients will be making a request to the one server listening socket. Now when the server "accepts" the a request you can process that one request as you see fit while at the same time the server may be "accepting" other requests. All these things happen concurrently. That is why we call the server an asynchronous socket.

The problem here is what happens if you want to be notified, when your thread is complete. That may be the case for many UI apps. The article I have mentioned explains all this. Cheers

It would be a mistake for you not to call the parent's code, just as it is in MFC. Can you imagine if you override the OnPaint event and not call the parent's code. That would be dangerous, because the parent code most often than not is critical for it to function properly. That being said however, if you really don't want to call the parent's code, then yes, you would have to derive your own Button class and override the OnClick. Cheers

Your server socket must use the Accept method to handle incoming client requests. Actually you should use BeginAccept uses the thread pool) for server apps for performance. In accepting these requests a handler handles the request and it is in this handler that you can add all incoming requests to wherever you want.

The XmlNodeClass is cannot be created. Notice that the constructor is protected. Therefore this class was meant to be inherited from. Basically the class is essentially abstract and so are the members for which you are receiving errors. Therefore, if you inherit from this class, you must implement all methods and properties that are abstract on this class. ie you must define these methods in your class. That is why you are getting the above errors. It's complaining that you haven't implemented them.

Rememebr that you must override the method that generates the event. You're not in fact overriding the event. For example the OnClick method raises the Click event. The OnClick method is virtual and therefore can be overriden. To call the default you simply would call the base's OnClick method ie base.OnClick(). For example: protected override void OnClick ( System.EventArgs e ) { base.OnClick(e); }

Well this involves some long explanation. It involves some windows understanding before you begin. What's important is that once the process is finished , it must call back on the windows message loop's main thread. I have the perfect article for you. Tale the time to read it. It's worth it. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms06112002.asp

You can fix the size of the ArrayList like so ... // Creates and initializes a new ArrayList. ArrayList myAL = new ArrayList(); myAL.Add( "The" ); myAL.Add( "quick" ); myAL.Add( "brown" ); myAL.Add( "fox" ); myAL.Add( "jumped" ); myAL.Add( "over" ); myAL.Add( "the" ); myAL.Add( "lazy" ); myAL.Add( "dog" ); // Create a fixed-size wrapper around the ArrayList. ArrayList myFixedSizeAL = ArrayList.FixedSize( myAL ); An exception will be thrown whenever yuo add or remove an item from the array. However, you can modify the items currently in myFixedSizeAL.:)

This example exists within the examples of on your computer. \Samples\Technologies\Remoting\Basic\RemotingHello Take 15-30 minutes to look at it. It's worth it.

Try putting the following attribute in your client app. Remove the [STAThread] and put [MTAThread]. [MTAThread] static void Main() { Application.Run(new Form1()); }

You could also and is probably better than spawning a new thread is to use the BeginInvoke(string str, AsyncCallback asc, object stateobject). You then call the EndInvoke(IAsyncResult result) to retrieve the answer from the function. You pass a reference to the Arraylist in the stateobject and your AsyncCallback method handles and the parameter within it's function. The good thing here is that you don't have to create a new thread, but rather the delagate function is executing on a thread from the thread pool - no creation is necessary. I understand that this is probably hard to understand if you've never seen it before but you can look up BeginInvoke. .NET supports asynchronous method calls wonderfully with delagate.BeginInvoke.

For your WebService to talk to your C# application you would again need something like .NET remoting, which brings you back to the first scenario anyways. You are crossing app domains, so communication has to be dealt with anyways. My suggestion would be use .NET remoting. It's really not an overkill at all. The server (which would be you C# application) simply needs add a couple of lines of code. And your client app can add a couple of lines of code and voila!!! You're done!!! The good thing here is that with .NET remoting you have all the flexibilty you want and it's very extensible. You can communicate TCP/IP or Http (through IIS or not) etc... If you need some samples respond back. Steve