>> (for some reason people seem to prefer to come up with their own >> ideas about what I think). > > Don't flatter yourself. I don't really care what you think at all ;-)
What can I say.... http://blogs.embarcadero.com/abauer/2009/10/08/38901 <shrug> (I didn't mean you specifically) > How would such a solution work with runtime packages? Two different packages? This was all discussed at length before the Unicode implemented was delivered. There is even less point going over it now that we're stuck with what we have. The problem is that what we're stuck with is a mess, so all we can do is talk about the mess as a way of finding our way out of it (in the sense that by talking about the mess we might one day understand the mess well enough to be able to live with it). i.e. a new user coming to Delphi 2009/2010 for the first time is going to have a hard time understanding even the simplest things, such as why ANSIUppercase() takes a UnicodeString parameter let alone treats it as Unicode whilst Uppercase() also takes a UnicodeString yet treats it as ASCII. Why isn't there simply: Uppercase(ANSIString) Uppercase(UnicodeString) Uppercase(WideString) ? And why is all this stuff scattered around SysUtils, and StrUtils and Character ? I remember that when I started out with Delphi I learned a great deal by exploring the VCL source - it was one of the things that made Delphi so accessible. But I feel sorry for anyone following the VCL code down the ANSIUppercase() rabbit-hole in Delphi 2010. Not least they are going to be thoroughly confused by the presence of {$IFNDEF UNICODE} directives (what? you mean I can UNdefine UNICODE...? Um, no, you can't) and FastCode licensed versions of routines that can't now ever be called (hmm, I like the idea of "Fast" code... now how do I go about using these "Fast" functions..?. well, you can't do that either). Not to mention the {$ifdef MACOSX} directives! The VCL these days looks a real mess, especially in the string handling areas which are going to be source of great interest for anyone dealing with the new, more complicated strings in Delphi these days. And OK it perhaps was never a particularly shining example of how to "do Delphi" in some areas, but it wasn't ever this confusing. The help isn't much, uh, help either. Older hands may be used to that these day but again, new-comers to Delphi aren't going to be very well served by the muddled mess that is the "String Types" topic. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
