Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 14 total |
When is the ANSI/Unicode single code base ready? |
Wed, May 29 2013 2:40 PM | Permanent Link |
Rolf Frei eicom GmbH | 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 |
Thu, May 30 2013 1:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Fri, May 31 2013 4:12 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Fri, May 31 2013 7:40 AM | Permanent Link |
Rolf Frei eicom GmbH | 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 |
Fri, May 31 2013 7:34 PM | Permanent Link |
Lance Rasmussen CDE Software Team Elevate | +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 |
Tue, Jun 4 2013 12:56 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Jun 4 2013 1:42 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sat, Jun 8 2013 10:57 AM | Permanent Link |
Rolf Frei eicom GmbH | 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 |
Wed, Jun 12 2013 2:17 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Mon, Jun 24 2013 8:44 AM | Permanent Link |
Rolf Frei eicom GmbH | <<<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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |