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