Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
My apologies for the continued rant, but I had another thought to share. ;) On Sun, Sep 5, 2010 at 2:31 PM, DZ-Jay wrote: > Since a new compiler is an absolute unknown factor, it cannot be assumed to > be supported by default. If the only objection to using CompilerVersion is to avoid implying

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
On Sun, Sep 5, 2010 at 4:29 PM, Olivier Sannier wrote: > Yeah, that's the problem I have. Maybe it's humor for the "compile then > ship" part, It was humor. I was trying to make the point that just because something compiles does not mean it is ready to ship. I never meant to imply that adding

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
On Sun, Sep 5, 2010 at 2:31 PM, DZ-Jay wrote: > > It can never be known in advance what new features will be added or which old > features may be deprecated by a new version of a compiler; and whether any of > it will break existing code or not. Of course not. > ICS, like many other components

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Olivier Sannier
On 05/09/2010 23:22, Jon Robertson wrote: But then again, you must know what you are talking about... Wow. I'm surprised by the hostility. Sorry, bad day, you're the last one on the long list of weird remarks to day... Based on your JVCL experience, are you aware of anything that should be

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
> But then again, you must know what you are talking about... Wow. I'm surprised by the hostility. Based on your JVCL experience, are you aware of anything that should be reviewed in ICS for XE support? Isn't JVCL is a little more dependent on the core VCL components than ICS is? For the most

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread DZ-Jay
On Sep 05, 2010, at 15:06, Jon Robertson wrote: > If ICS works in D2010, why can't the same source be recompiled in > Delphi XE without change? Why must component vendors insist on > forcing source code changes (even if just the .inc file) for every > version, when there is very likely nothing i

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Olivier Sannier
On 05/09/2010 21:06, Jon Robertson wrote: If ICS works in D2010, why can't the same source be recompiled in Delphi XE without change? Why must component vendors insist on forcing source code changes (even if just the .inc file) for every version, when there is very likely nothing in the new ver

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
> Which problem do you  have exactly ? > I never had any complain about Delphi version detection. If nothing else: If no VER defines are detected, then assume the latest. Which, in this particular case, would be VER210. Even better: Use {$IF CompilerVersion >= } conditionals to determine Delphi

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
If ICS works in D2010, why can't the same source be recompiled in Delphi XE without change? Why must component vendors insist on forcing source code changes (even if just the .inc file) for every version, when there is very likely nothing in the new version of Delphi that will break the components

Re: [twsocket] Request for better Delphi version detection

2010-09-05 Thread Francois PIETTE
So, while installing my copy of ICS (currently used in D2009 and D2010) in Delphi XE, the compile dies on: {$IFNDEF COMPILER7_UP} Bomb('This component requires Delphi 7 or later'); {$ENDIF} Why can't component vendors use more reliable means of detecting versions of Delphi? Which problem d

[twsocket] Request for better Delphi version detection

2010-09-05 Thread Jon Robertson
So, while installing my copy of ICS (currently used in D2009 and D2010) in Delphi XE, the compile dies on: {$IFNDEF COMPILER7_UP} Bomb('This component requires Delphi 7 or later'); {$ENDIF} Which reminds me of one of my pet peeves regarding third-party components and Delphi upgrades: Why can'

[twsocket] Bugfix in the experimental timeout source and conditionals renamed

2010-09-05 Thread Arno Garrels
Hi, I just checked in revision #586. Log: Fixed a bug in the experimental throttle and timeout source which made it impossible to use both features at the same time (EListError). Renamed conditionals EXPERIMENTAL_THROTTLE and EXPERIMENTAL_TIMEOUT to BUILTIN_THROTTLE and BUILTIN_TIMEOUT. It's now

Re: [twsocket] TSmtpCli and bad spam score

2010-09-05 Thread Fabrice Vendé
Le 03/09/2010 23:03, DZ-Jay a écrit : Fabrice, I do not have Delphi available at this moment, so could you test the code below to see if it is treated as spam by SpamAssassin? Hello, There is a tools to check SpamAssassin score here : http://www.mailingcheck.com/ Best regards, - Fabrice

Re: [twsocket] TSmtpCli and bad spam score

2010-09-05 Thread Fabrice Vendé
Le 03/09/2010 23:03, DZ-Jay a écrit : Fabrice, I do not have Delphi available at this moment, so could you test the code below to see if it is treated as spam by SpamAssassin? Hello, There is a tools to check SpamAssassin score here : http://www.mailingcheck.com/ Best regards, -- Fabrice V