RE: Delphi 2009 and Strings
Okay, that makes sense. I thought perhaps there was some other reason I wasn't getting. Thanx. from Robert Meek dba Tangentals Design Creative Concepts Programming for Windows Vista E-mail: ffo...@comcast.net Most people would sooner die than think; in fact, they do so! [Bertrand Russell 1872-1970] -Original Message- From: delphi-talk-boun...@elists.org [mailto:delphi-talk-boun...@elists.org] On Behalf Of Francois Piette Sent: Monday, May 04, 2009 7:44 AM To: Delphi-Talk Discussion List Subject: Re: Delphi 2009 and Strings Simply do a search and replace to change all occurrences of String type to AnsiString type. The compiler will automatically convert AnsiString to UnicodeString when it is necessary. This will work although you will not benefit from Unicode. I realize I'm missing something obvious here, but why won't it benefit from Unicode if the strings are converted? To benefit from Unicode, you must use Unicode all the way between user input to user output, passing by database and everything. If a single element in the chain handle strings as AnsiString, then you won't be able to handle Unicode properly. -- francois.pie...@overbyte.be Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be __ Delphi-Talk mailing list - Delphi-Talk@elists.org http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk __ Delphi-Talk mailing list - Delphi-Talk@elists.org http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk
RE: Delphi 2009 and Strings
Working for a firm where someone else can make such decisions like this is a bear I guess, and its the same in any firm. At least it has been for every company I've ever worked for. I've always been happier working for myself and being a little poorer. I guess I should be ecstatic these days, huh! g Btw...have you tried to port Imagelib yet? I had no problems porting the last release which was for d5 or 6 I believe, over to D2007, but I haven't yet tried for D2009. from Robert Meek dba Tangentals Design Creative Concepts Programming for Windows Vista E-mail: ffo...@comcast.net Most people would sooner die than think; in fact, they do so! [Bertrand Russell 1872-1970] -Original Message- From: delphi-talk-boun...@elists.org [mailto:delphi-talk-boun...@elists.org] On Behalf Of Cameron Cole Sent: Monday, May 04, 2009 10:20 AM To: Delphi-Talk Discussion List Subject: Re: Delphi 2009 and Strings With all respect, but the code samples presented are really examples of bad coding. Personally I wouldn't expect this kind of code to survive such a transition. While again not my code and in 3rd party components, I think you will find a large number of 3rd party components that are older are written in a similar way. Also while I think it could be written better, I wouldn't consider it bad. Code works, is fairly fast and readable. Changing SizeOf was the problem in the first and StrPas while out-dated was a necessary evil for a long time and most components we use date back to Delphi 1. They have been upgraded along the way, but older code that works still remains. Switching between AnsiString and String in definitions is bad though. I would also point out that code was from a fairly well known 3rd party component package. I won't name names, but I know several companies that continue to use their products. True, but the boss sees a port as necessary at some point. So long as we keep the product patched and low maintenance there isn't any justification to move it. In that case you might as well keep your old Delphi version on your system. That is on the table, but getting to x64 would be a big selling point to our customers as our middle tier servers could actually take great advantage of it. This is a step in that direction. We could maintain our servers in 2009 (or whatever the next Delphi is with x64 support) and client in 2007, but that would be a PIA and a difficult sell to management. Plus I am not sure how our middle tier would react to having client side String routines work one way and server side work another. We could cast everything going out server side as AnsiString but another PIA. Oh and the middle tier is an easy Delphi upgrade since all the code there is very generic. However, we deal with a lot of encryption, compression and multi-platform code C# is no option with multi-platform code. You would be wrong there. I have written several apps in C# using mono that work great. Besides, the code I am referencing doesn't need to be multi-platform for us but was written that way to handle data from other OSes. We only use the Win code, but the other OS considerations in the code couldn't be easily uncoupled. Besides, we have been waiting for some time to have a window to upgrade as we don't get many lulls in our workload to perform these types of upgrades and testing. Since it will probably be another couple years before we can pull off an upgrade of this scale, C# has to be considered and we would be fools not to. I realize your problems are a lot more varied, but if you switch to C# you're going to have to re-purchase all your components anyway! We already have most the components and licenses since our shop does work in C#. Until now C# has been limited to HTTP based front ends and some back end services. This really wouldn't be that difficult for us, C# already talks to our Delphi middle tier (the real bear to rewrite since all the business logic is there). It would take a lot longer for us to port the client, but our client that uses these components is UI only and some utility code that handles various file inputs. It's a matter of money for time or money for purchase, and if you can simply hold on for a year, porting only those components you must, the third-party vendors are going to have to update their offerings anyway. Whether we port a component or buy it makes no difference to them financially since both cost money. Also, we have a lot of components that simply aren't in business any longer. Granted it would be best to get off those components (Jasmine, XDom, ImageLib and some others) but in some cases the change is as drastic as writing all new code. The big minus for Delphi is that any changes look to management as money wasted which makes getting funding for these projects difficult. If we put the same effort and money into C#, it is a pretty easy sell
Re: Delphi 2009 and Strings
Simply do a search and replace to change all occurrences of String type to AnsiString type. The compiler will automatically convert AnsiString to UnicodeString when it is necessary. This will work although you will not benefit from Unicode. I realize I'm missing something obvious here, but why won't it benefit from Unicode if the strings are converted? To benefit from Unicode, you must use Unicode all the way between user input to user output, passing by database and everything. If a single element in the chain handle strings as AnsiString, then you won't be able to handle Unicode properly. -- francois.pie...@overbyte.be Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be __ Delphi-Talk mailing list - Delphi-Talk@elists.org http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk
Re: Delphi 2009 and Strings
Borland may have made a change that will cause us to leave Delphi. The change in strings is creating a near epic conversion for us. We use a lot of third party controls and apparently it was pretty common to interchange AnsiString with String as well as use functions like StrPas. Bad code. I won't argue that it is bad form to interchange AnsiString and String, but in many cases it is just a holdover from dealing with old Unicode problems. In other situations it was one way of getting the job done... For example, can't do this any longer (not my code): MTime: Array[0..11] Of Char; IntToOctStr(UnixDate, SizeOf(MTime), True, MemBuf); CopyMem(@MemBuf[0], @MTime[0], SizeOf(MTime)); MTime[SizeOf(MTime) - 1] := #0; In other places the functions themselves have to be reconciled. For example, this requires a casting to work: StrPas(@SomeString[1]); So now we have weeks of hacking through code casting, changing, etc. After our pilot project to convert a small set of controls that normally would take about ten minutes to upgrade to the latest Delphi over about three days. The boss is asking if we would be better off spending that time and money converting our client to C#. This could be the end for us using Delphi. Shame. Converting to C# would be tremendously more time consuming and you'll have the risk to introduce a huge number of bugs because not only will you change language but also all components and runtime. True, but the boss sees a port as necessary at some point. So long as we keep the product patched and low maintenance there isn't any justification to move it. However, why spend a month upgrading objects and buying more source when we can take that money and time and start on a port they see an inevitable. Sort of like an old car that has a head gasket blown on it. Is it worth it to put another $2000 in repairs into the old car or should you just bite it off and take that money and use it as a deposit for a new one. By creating additional work and in some cases substantial work, CodeGear has opened the door for leaving them. Maybe not as bad as VB to VB.net but worse than all that CLX crap they put in a few years back. A good example for us is the XDom. It no longer exists, has a lot of old Unicode string manipulation that needs to be redone and we use it all over the place. The alternatives are to fix the old XDom (ouch), swich components to ADom or some other control (ouch) or create our own XDom objects built on top of another control (ouch). All of those options requiring new unit tests to be written. The big dumb question of the day is there any directive to turn off UnicodeString or to force String to be defined the old way? Simply do a search and replace to change all occurences of String type to AnsiString type. The compiler will automatically convert AnsiString to UnicodeString when it is necessary. This will work altough you will not benefit from Unicode. If only it were that easy. That is the tact we took on our test project, but the samples above (and another couple dozen) required a programmer to sit down and figure out the right course of action. If your app has no strange old Unicode support or funky string manipulation, it probably wasn't a big deal. However, we deal with a lot of encryption, compression and multi-platform code so we have a lot of components that cost to upgrade or are no longer in business so we have to upgrade/replace. It wouldn't even be a conversation if Delphi had unified onto one string. I am sure there are good reasons to have AnsiString, UnicodeString, etc but from our standpoint making them all the same thing or a Defines that would have allowed us to keep the backwards compatibility in a unit would have been better. __ Delphi-Talk mailing list - Delphi-Talk@elists.org http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk
