Tim

Any idea at which point we get the single components for Unicode and ANSI
release? So we don't need to install the one or the other and can use both
of them at the same time.

Some time back you promised this to be happen in 2.11 but in 2.12 it's till
not here. Any timeframe? As soon this will arive I will renew my support
plan.

Regards
Rolf

Rolf,

<< Any idea at which point we get the single components for Unicode and ANSI
release? So we don't need to install the one or the other and can use both
of them at the same time. >>

I had to abandon those modifications - they were going to cause serious
performance issues when the chosen character set did not match the native
string type for the compiler being used, so the end result was not usable.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


><< Any idea at which point we get the single components for Unicode and ANSI
>release? So we don't need to install the one or the other and can use both
>of them at the same time. >>
>
>I had to abandon those modifications - they were going to cause serious
>performance issues when the chosen character set did not match the native
>string type for the compiler being used, so the end result was not usable.

In that case how about having different names for the components so there's no clash?

Roy Lambert

Tim

No, no, nooooo!!!!

As Roy, I think you should then make two different component names. Unicode
and ANSI in the same application is extremly importand for me, and I'm very
frustrated now. I was so exited as you announced this feature, but now....

Regards
Rolf


"Tim Young [Elevate Software]"  schrieb im Newsbeitrag
news:B4E7F717-05EA-4DA4-85F0-1891EB83177F@news.elevatesoft.com...

Rolf,

<< Any idea at which point we get the single components for Unicode and ANSI
release? So we don't need to install the one or the other and can use both
of them at the same time. >>

I had to abandon those modifications - they were going to cause serious
performance issues when the chosen character set did not match the native
string type for the compiler being used, so the end result was not usable.

Tim Young
Elevate Software
www.elevatesoft.com

+1 for different name nomenclature so that we can have both Ansi and Unicode installed.  It would make things much easier.  I believe this is how a couple of my DAC's work now with MySQL or something.

Lance



Roy Lambert wrote:

Tim


><< Any idea at which point we get the single components for Unicode and ANSI
>release? So we don't need to install the one or the other and can use both
>of them at the same time. >>
>
>I had to abandon those modifications - they were going to cause serious
>performance issues when the chosen character set did not match the native
>string type for the compiler being used, so the end result was not usable.

In that case how about having different names for the components so there's no clash?

Roy Lambert

Roy,

<< In that case how about having different names for the components so
there's no clash? >>

The string type used in EDB is controlled via a compilation switch, so the
only way that would work is if I were to maintain two sets of everything or
come up with a way to generate two different sets of everything (packages,
units, class names, etc.) for every build.  This sounds fine for you, but
imagine what I would have to do every time I wanted to test one type vs. the
other type when I have a support issue.

Plus, someone (ANSI or Unicode developer) is going to get a rude awakening
when all of their component names have been changed.

The basic issue here is that ANSI vs. Unicode is a compilation decision, not
a run-time one.  I tried to make it a run-time issue last year, and that's
what failed.  There's just no way to do it without introducing a translation
layer at a low level to deal with the fact that a pointer-to-string type
(PChar) is not something that can be changed at run-time.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

>The basic issue here is that ANSI vs. Unicode is a compilation decision, not
>a run-time one. I tried to make it a run-time issue last year, and that's
>what failed. There's just no way to do it without introducing a translation
>layer at a low level to deal with the fact that a pointer-to-string type
>(PChar) is not something that can be changed at run-time.

<Joke Alert>

In that case make ANSI the native string and have the translation layer invoked for unicode. The number of complaints I've seen on the EMB ngs about speed / size in the newest compilers they'll never notice the difference!

</Joke Alert>

More seriously shame but I can understand your problems.

Roy

Tim

As I can understand your point, I have big problems for my self as of this.
You should consider something about this for EDB3 then (different component
names). As you say it is a compiler switch only, will I be able to compile
the ANSI-Source (ANSI-EDB Installation) with producing the Unicode
application and linking the unicode stuff instead the ASNSI-stuff? Or with
other words: is the source of the ANSI-Installation an Unicode-Installation
the same codebase and only a EDB Compiler DEFINE is enough to compile in the
unicode engine? Will I be able to have the ANSI components installed in the
IDE and compile it into a UNICODE Application by setting the correct DEFINES
and using the sorce paths instead the libs (dcu's) of course?

Regards
Rolf

"Tim Young [Elevate Software]"  schrieb im Newsbeitrag
news:2916D20E-3030-4210-9FCD-DBEE978461B2@news.elevatesoft.com...

Roy,

<< In that case how about having different names for the components so
there's no clash? >>

The string type used in EDB is controlled via a compilation switch, so the
only way that would work is if I were to maintain two sets of everything or
come up with a way to generate two different sets of everything (packages,
units, class names, etc.) for every build.  This sounds fine for you, but
imagine what I would have to do every time I wanted to test one type vs. the
other type when I have a support issue.

Plus, someone (ANSI or Unicode developer) is going to get a rude awakening
when all of their component names have been changed.

The basic issue here is that ANSI vs. Unicode is a compilation decision, not
a run-time one.  I tried to make it a run-time issue last year, and that's
what failed.  There's just no way to do it without introducing a translation
layer at a low level to deal with the fact that a pointer-to-string type
(PChar) is not something that can be changed at run-time.

Tim Young
Elevate Software
www.elevatesoft.com

Rolf,

<< You should consider something about this for EDB3 then (different
component names). >>

I've been going "around and around" on this for some time, and unfortunately
there's really no way to "square this circle", at least not that I can see.
In fact, there's probably a better chance that EDB3 will be 100% Unicode.
The ANSI stuff is all being deprecated by EMBT, anyways.

<< As you say it is a compiler switch only, will I be able to compile the
ANSI-Source (ANSI-EDB Installation) with producing the Unicode application
and linking the unicode stuff instead the ASNSI-stuff? Or with other words:
is the source of the ANSI-Installation an Unicode-Installation the same
codebase and only a EDB Compiler DEFINE is enough to compile in the
unicode engine? Will I be able to have the ANSI components installed in the
IDE and compile it into a UNICODE Application by setting the correct DEFINES
and using the sorce paths instead the libs (dcu's) of course? >>

Sure, that's what I do now when running under 2009 or higher.  There is one
single project define (Project/Options/Compiler/Conditional Defines):

EDB_UNICODE

If that compiler define is present, then EDB will be compiled as Unicode.
If not, then no.  Under certain OS's like .NET, this define is set
automatically in the edbversion.inc include file since .NET is 100% Unicode.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

<<<The ANSI stuff is all being deprecated by EMBT, anyways.>>>

This is the most stupid descission of EMBT and this will destroy finally the
Delphi market completly. I will never ever buy a Delphi version with no ANSI
Support or any of the other planned ground breaking changes. This is the
defintiv suicide of Delphi, if they realy do this. Destroy the milions of
millions of existing 3rd party source code components and utilities is so
idiotic, I can't believe they will do this realy.

If they do this I will left the Delphi boat finally and what's then the
future of EDB for me isn't clear to me yet.

Regards
Rolf