[twsocket] I wan't to stop the server from listening then start it
IMO, this will even be worse. When you'll use the next update, you'll be introuble whatever change you've done in the source. No troubles, I add my signature in comments to track what I've changed in source, and use WinDiff to inject your improvements. The correct way doing such behaviour change is to derive your own class fromTWSocket and override AssignDefaultValue procedure. This is a nice exampleabout what OOP is for. It could be nice when using only non-visual TWSocket. Otherwise we receive additional troubles: derive our own component; install it into IDE. And what if we have to use other class, for example, ftp client? What we should do in this case? Derive our new ftp client class, redeclare Controlsocket and Datasocket properties? No, thanks... I'd better put several // in the code and will be happy )) -- 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
Re: [twsocket] I wan't to stop the server from listening then start it
QUOTE: It could be nice when using only non-visual TWSocket. Otherwise we receive additional troubles: derive our own component; install it into IDE. And what if we have to use other class, for example, ftp client? What we should do in this case? Derive our new ftp client class, redeclare Controlsocket and Datasocket properties? You do not need to redeclare the properties; all you need to do is override the AssignDefaultValue() method, like Francois said. This method is virtual for precisely this reason. But, in general: yes, that's exactly what you should do. That is the essence of Delphi and Object Oriented Programming (OOP) in general. This separates functionally the underlying ICS classes from your specific implementation and needs, which means that if anything in ICS changes in the future, you most likely only have to update the TWSocket libraries and not have to worry about merging your changes back in, which is time consuming and error prone. Likewise, if you need to add new functionality or update your own implementation, you do not need to worry about ICS at all. This avoids potential conflicts, saves maintenance time, and streamlines development. Also, keep in mind that you do not necessarily have to install your custom components into the IDE; you can very well instantiate any component by calling it's constructor directly. Of course, you will not be able to drop the component on a form, but sometimes this is not a big deal. QUOTE: No, thanks... I'd better put several // in the code and will be happy )) As you wish. But, in my opinion, this is a slippery slope which ends up in trouble eventually. One of the worse potential problems with this tactic, which I've seen before, is that it leads to developers delaying or avoiding future ICS (or any thrid-party library) improvements, revisions, and sometimes important bug-fixes because of the overwhelming thought of having to track down all possible modifications and figure out how to merge them back into the code-base; which ones have been obsoleted by the update; and which new ones will be needed. -dZ. -- 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
Re: [twsocket] I wan't to stop the server from listening then start it
The correct way doing such behaviour change is to derive your own class fromTWSocket and override AssignDefaultValue procedure. This is a nice exampleabout what OOP is for. It could be nice when using only non-visual TWSocket. Otherwise we receive additional troubles: derive our own component; install it into IDE. And what if we have to use other class, for example, ftp client? What we should do in this case? Derive our new ftp client class, redeclare Controlsocket and Datasocket properties? No, thanks... I'd better put several // in the code and will be happy )) You don't need to change the FTP component or any other else. It takes care of everything. You should only change TWSocket because you don't want to do the initi in your application. There is no problem to install you derived component in any package. Personnaly, I always have a package for all components used into an application. A package specific to that application. I never use the packages provided by the component editor (being mine or any other one). I find this much easier to know what exactly an application needs and move the development on another computer. This also help avoiding to have tons of installed components when you don't need them. The only drawback, which is also an advantage in clarity, is that you have to reinstall the right package when you switch from one application to another one. And in my case, this is very easy since the package is always the first in the project group. This has been proven very effective for years now. Note that I understand that each one has difference preferences for his development environment. I only explain how I work. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- 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
[twsocket] OT RE: I wan't to stop the server from listening then start it
Francois... Note that I understand that each one has difference preferences for his development environment. I only explain how I work. Thanks for the info on your package approach, Francois. Interesting approach that I hadn't thought of. Two questions... 1. Would you use this approach across different machines? Meaning, are the packages sufficiently portable across hosts? So, the bpl or whatever form you are using, could just be moved that way? Sorry, but I don't have time to keep up with the package format changes anymore. That got old forever ago. :) 2. How do you handle packages that get frequently updated? For example, I have a specific component provider that FREQUENTLY updates their stuff with bug fixes and feature enhancements. I have others that do the same, but less frequently. Do you rebuild all your packages every time one dependant package gets updated? Or, does D2007 handle the specific inter-dependencies automatically? No hurry on an answer to this. I just thought your approach was interesting and might be a real benefit for me, but I would need to solve those two issues for it to be applicable to my environment(s). Thanks... Hoby -- 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
