On Thu, 14 May 2009, Szak�ts Viktor wrote:

Hi,
> > In this case you removed important functionality without leaving any
> > alternative for users. _SET_EOL is not a solution or replacement at all.
> > Now it's not possible to use multiple EOLs in this set of functions what
> > is very important in some portable programs which have to accept data
> > with different EOLs.
> > Can you revert this modification until we will not have any working
> > alternative?
> I can revert it although IMO we should rather think about a proper
> alternative, these options were missing from default builds since
> last year and no one reported them missing, which suggest it
> isn't that important. I've since removed all HB_EXTENSION from
> code, so readding this one looks a bit overkill.

I stoped to use default builds when you disable some extensions so
I cannot say much about it.

> One alternative is to readd all of them with HB_ prefix, but this is
> quite ugly. The other ugly solution is to readd it under a different
> macro like HB_MEMO_EOL_PARAM_EXTENSION.
> What would be a proper solution here, another Set()?

I do not like to use SETs because for structural code I have to
set and restore them what in some cases has serious performance
overhead. In some other it can be even killer.
F.e. we have SET callback functions registered by ADS. It means
that such simple Clipper code:

   func ansidate( dDate )
      local cFormat := set_( _SET_DATEFORMAT, "YYYY-MM-DD" ), cDate
      cDate := dtoc( dDate )
      set_( _SET_DATEFORMAT, cFormat )
      return cDate

Ported to Harbour activates callbacks and ACE function calls if user
linked any of ADS based RDD.
If you use ansidate() function to format some chosen columns in very
long reports then you can imagine the cost.
BTW This part is also not MT safe. I do not believe that ACE
client keeps such sets in some thread local storage.

> [ I personally wonder on the usefulness of this feature, as IMO
> such text handling functions should automatically work on all
> available EOLs on all system without any explicit help from the
> user. ]

I do not find it as good idea. Such extension will always break sth.
F.e. code which tries to make visualization of some printer output and
strongly depends on some strict CR and LF behavior which have to be
compatible with external device he uses.

best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to