Francois, thank you for packages advise. It is quite unulual but looks convenient.
> You don't need to change the FTP component or any other else. It takes careof > everything. You should only change TWSocket because you don't want to dothe > initi in your application. So, suppose I inherit a class TNewTWSocket = class (TWSocket) ... AssignDefValues ... end I don't see how this would affect on TFtpCli which I use > You should not disable a "strange method" unless you fully understand whatit > does and if it is not used elsewhere. You can of course disable it foryour > own applications or components but surely not for existing applicationsor > components. If you do, you'llk probably break something because > theapplications or components are developped assuming the behaviour > youconsider "strange". I looked at the sources, and decided that it is safe to remove field clearing. Of course this modifications will be for my own apps only, and so on. > Clearly here, the "strange method" is not a bug. It is a feature. By > designTWSocket reset some properties to default values. There is a good > reasonbehind that design, even if that reason is no more really applicable > today,that behaviour must be preserved because existing code may rely on it. Obviously it is. Bugs look differently)). But I can find no reasons for that and consider such behavior very embarassing. I have never ever saw a class where programmer has to re-assign fields he already assigned before. > As a side note: When you think something must be changed in ICS > components,then sublit your proposal here, explain why your change is needed, > eitheradding a new feature or fixing an issue, and let's discuss it. If it > isapproved, then your change will be done in the component for everyone. > Onegold rule with ICS is "do not break existing code unless really > reallyreally needed". Yes, I've already reported (http://lists.elists.org/pipermail/twsocket/2008-August/038568.html) about it when I nearly chashed my brain on this underwater stone. First time connection establishes OK, but second time it fails, wth? I've lost hours before I found the trouble source. Moreover. Another head-breaking bug-or-feature: necessity to manually specify binary or text mode. Also many hours of step-by-step debug. to find an answer why received files are broken. I reported about it, but was said that I should implement mode selection by myself. Another issues: * External FLocalStream issue, when FTPCli destroys an object which it didn't create. * Unuseful host name resolving when using socks5 - these things I've reported too, but got no reaction. So what's the meaning of further reporting about exceptions in log and received file creation if directory doesn't exist, great lack of timeout mechanism for stopping socket from waiting eternally, and so on? Looks like I have to implement all needed behaviors by my own. -- Regards, Anton -- 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
