Olivier Sannier wrote: >> Thanks for the information. I did moved to v6 and had to adapt a few >> things (would have been nice if Disposed in TIcsWndControl had been >> protected and not private) but it did not help at first. >> Why? >> Because as soon as all connected clients would disconnect, the handle >> allocated for them would be released. And the next time a client >> comes in, the handle cannot be created anymore because the Indy part >> of the process has taken it.
How comes that this part grabs any handle and does not cause an 'out of handles' error itself? Do you use a thread pool that never shrinks? How many client connections are served when the error happens? >> What I did was to instantiate a dummy TIcsWndControl component per >> message pump thread instance, attach it to the thread and only >> release it when the thread ends. >> Then I made the threads start at the beginning of the process >> instead of "on demand". There are only two of those threads, so >> that's not too much of a hassle. >> This way the handle is created at the very start, when there are >> still handles left for the process and is never released even if all >> clients disconnect. >> >> Note that I created a dummy "TIcsWndControl" instance as it seems the >> easiest way to do keep the handle opened, if you know of a better >> way, please let me know. It's a workaround only, since one hidden window can handle a maximum number of const WH_MAX_MSG = 100 registered message IDs only, hence it won't prevent ICS from creating new hidden windows on demand depending on the number of concurrent client instances. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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
