Francois PIETTE wrote: >>> This design would not break any existing code and would ease using >>> the new multiple listen easy to implement in higher level >>> components. > >> It won't break existing code, but remains a hack IMO. > > I don't agree with you. Please explain.
> The main instance keep track of the secondary instances. Yes, that should be a TComponentList owning the instances. > A new r/o property > "MultiListenList" (and btw "MultiListenListCount") would gives the list of > all TWSocketServer, in the order specified in the Addr property. All > TWSocketServer share the same list. > MultiListenIndex would be "-1", > MultiListenList would be nil and MultiListenCount would be 0 if > TWSocketServer is used alone. Each get a new property "MultiListenIndex" > which is their index in that list. At first I would not expose the list but provide public methods to Add and Delete instances and to access instances by index (r/o). I would simply fake the list with count "1" when there are no additional instances and the list is not assigned. Listener[0] returned Self, ListenerCount "1" etc.. All clients should be added to main instance's client list, the Sender argument in server events gives you the server object triggered the event. I'm not sure whether you have that in mind, have you? > All event handlers are > common to all TWSocketServer instances. That should be the default assignment after a call to method Add() only to ease setup of the new instance. > >> All event assignments and unassignments have to be kept in sync. > > They will be easily with setter and getter. That may work, but it is confusing since one can easily change the event handlers of additional instances. It was cleaner to not synchronize event assignments except in method AddServer() to set the defaults. >> Also I would not bind the construction/destruction of the additional >> instances to the Addr string property (grrr), > > Why "grrr" ? Please explain. At least that should be a new string property since Addr and Port identify the instance too. It remains a hack as long as not all relevant persistent properties are available in Object Inspector. What about SslEnable? It's cleaner to let users explicitly create additional instances at runtime. If just a fraction of persistent properties are assigned the component user has to set the rest at runtime, that's confusing. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
