Hi Przemek,
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.
Which extensions do you miss? or what extra settings do you use?
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.
Most probably non-MT safe. In this case I can't really decide as
I'm not and RDDADS user and I have no idea why these callbacks
were added back then. If it's unsafe or kills performance we
should IMO disable it or find better solution. Fortunately with
HB_DTOC() this specific problem can be solved.
[ 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.
Can be, yes, however I still can't see a good solution without
adding a new "memo" API with such feature. If we readd it like it
was (but as default), we also readd a hidden parameter extension,
which may collide with other implementations and create usual
back-port problems.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
