tag:blogger.com,1999:blog-2428374771421713311.post7484627714469942772..comments2024-03-10T12:04:17.661-07:00Comments on The Oracle at Delphi: More FAQs about Unicode in TiburónAnonymoushttp://www.blogger.com/profile/10119008505905401707noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-2428374771421713311.post-43130578734862856772008-01-10T03:35:55.000-08:002008-01-10T03:35:55.000-08:00For a form which contains many images and/or other...For a form which contains many images and/or other binary data, the binary DFM format will be more preferable than the XML-format.Kryvichnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-10422217349554983502008-01-10T06:28:52.000-08:002008-01-10T06:28:52.000-08:00For now (D2007) you can not write in an UTF8-coded...For now (D2007) you can not write in an UTF8-coded source:<br><br>private<br> var FLänge : Integer;<br>published<br> property Länge: Integer read FLänge write FLänge;<br><br>The private var is OK but the property identifier makes an error.<br>I just wonder if Unicode will also be enabled for RTTI structures.?Franz J. Bauernoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-4266161864983779142008-01-10T07:10:38.000-08:002008-01-10T07:10:38.000-08:00Franz (excellent name ;-), That is correct. Righ...Franz (excellent name ;-),<br><br> That is correct. Right now, non-ascii identifiers in published sections is not allowed. We're going to be reviewing this limitation for Tiburon.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-68249697702786997392008-01-10T12:46:22.000-08:002008-01-10T12:46:22.000-08:00(In D2007)privatevar FLänge : Integer;publishedpro...(In D2007)<br>private<br>var FLänge : Integer;<br>published<br>property Länge: Integer read FLänge write FLänge;<br><br>Put your cursor before the "ä" in "var FLänge : Integer;". Then press down arrow key. works as expected<br><br>Put your cursor after the "ä" in "var FLänge : Integer;". Then press down arrow key. cursor is positioned 1 character to the rightJonathan Moranoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-33051547639150600582008-01-10T18:06:58.000-08:002008-01-10T18:06:58.000-08:00Ref. #13 - Personally, I would believe that the po...Ref. #13 - Personally, I would believe that the possible advantages that I mentioned in #9 outweigh the relatively minor parsing overhead. <br><br>In my previous position we handled realtime datastreams in XML for some 30.000 instruments from 25 exchanges on a low end PC (10's of millions of packets over a day) without any mentionable impact on CPU load. Surely we can handle reading and manipulating a DOM tree during coding/design and parsing a few changed .dfmx files during compile? <br><br>In context of post #16, if you take a more .rc like approach to .dmfx files and keep f.x. bitmaps external to the file in design time, it would be possible that you may actually save space by referring an external bitmap file in multiple .dfmx's rather having multiple embedded copies in each .dfm.<br><br>Before someone go "but thats an advantage to have all resources in one place" and "you will forget what bitmaps you need"... Would you forget what units your project need? Include bitmap or include unit - same concept. Actually the "embeddedness" of f.x. ImageList have always been a challenge when you need to change it's contents.<br><br>IMO, having the descriptive .dfmx form as XML at design time have definitive benefits that are not easily added to the existing .dfm format (again see #9).<br><br>As for the linked .dfmx - why would it need to be in XML in the .exe? A BISON (Binary JSON) approach would be possible - essentially removing the human readable portion of XML and leaving a compact binary stream.Lars Fosdalnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-44079198849310858792008-01-10T22:12:13.000-08:002008-01-10T22:12:13.000-08:00If you are going to adjust RTTI for unicode, why n...If you are going to adjust RTTI for unicode, why not please adjust RTTI to handle private and protected published sections also. As a stepstone toward good object structure also in TForm etc. descendants.<br><br>Actually, the good effects of XML inside .DFM could cover a big article. <br><br>You say bigger files from XML, then tell me how? I did a little samle with a lot of different types in .DFM. The textbased was 1413 bytes and the XML was 1027 bytes.<br><br>Here's the textbased:<br>object fmMain: TfmMain<br> Left = 416<br> Top = 45<br> ClientHeight = 745<br> ClientWidth = 781<br> Color = clBtnFace<br> Font.Charset = DEFAULT_CHARSET<br> Font.Color = clWindowText<br> Font.Height = -11<br> Font.Name = 'Verdana'<br> object gridResults: TcxGrid<br> Left = 0<br> Top = 0<br> Width = 781<br> Height = 255<br> object viewResults: TcxGridDBTableView<br> OnMouseMove = viewResultsMouseMove<br> OnCellDblClick = viewResultsCellDblClick<br> OnCustomDrawCell = viewResultsCustomDrawCell<br> DataController.DataSource = dSOAP.srcTrips<br> DataController.Summary.DefaultGroupSummaryItems = <br> DataController.Summary.FooterSummaryItems = <br> DataController.Summary.SummaryGroups = <br> OptionsBehavior.CellHints = True<br> OptionsCustomize.ColumnFiltering = False<br> OptionsCustomize.ColumnGrouping = False<br> object viewResultsdeparture: TcxGridDBColumn<br> Properties.Alignment.Horz = taCenter<br> Properties.Alignment.Vert = taVCenter<br> Properties.Items = <br><br> <br> <br> <br> <br> <i><br> <br> <br> <br> <br> <br> <br> <br> <br> <i><br> <i><br> <br> <br> <br> <br><br><br>And actually, when you update VCL RTTI to a better level with object reference handling etc. then you really would want the XML model.<br><br>But all that could only be covered in a big article.<br><br>And what tells you that XML loading have to be slower than the textbased? It all depends on how you choose to load it. I do not recommend using MSXML for this, you need to do serial loading top to bottom, moving data to properties as you go (just as today). You don't need to create a complete object tree representing the values before you move them into the properties...</i></i></i>Atle Smelvaernoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-59261974359664894742008-01-10T22:16:08.000-08:002008-01-10T22:16:08.000-08:00Looks like the samplecode did not get through.If y...Looks like the samplecode did not get through.<br><br>If you want to see the XML and DFM sample, I've posted them inside borland.public.attachments with "XML versus textbased DFM" as subject.Atle Smelvaernoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-84797262411530184432008-01-10T23:20:56.000-08:002008-01-10T23:20:56.000-08:00XML size will only be a problem if you embed binar...XML size will only be a problem if you embed binary data (bitmaps, etc) in the XML file. It suddenly struck me that this is currently done in the .dfm files too... Hence, the size issue is not really a deciding factor.<br><br>IMO, binary content in forms that are not component stream generated should be stored as separate file references where possible.Lars Fosdalnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-11058143726899948692008-01-15T16:18:55.000-08:002008-01-15T16:18:55.000-08:00Any information on when the Tiburón field test wil...Any information on when the Tiburón field test will start?Rasmus Møller Selsmarknoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-13135332415489679452008-01-20T20:58:03.000-08:002008-01-20T20:58:03.000-08:00It's nice to see that the Unicode support with...It's nice to see that the Unicode support within Delphi evolves.<br>therefore I only wanted to say something about that *.dfmX thingy.<br>I'd prefer it to stay as it is as XML is too overrated when it comes to storing information.<br>After all, I like the way the *.dfm's look like as they can be handled intuitively (they look like pascal code)...Kevin Niehagehttp://www.coltishware.comnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-91636631371984276682008-01-09T08:47:02.000-08:002008-01-09T08:47:02.000-08:00Some folks have complain about the compatibility w...Some folks have complain about the compatibility with old apps.<br>In Delphi we have a {$H+} or {$H-} switch. Can we do the same with the Unicode stuff:<br><br>$UC+:<br>string = UnicodeString (UTF16)<br>char = 2 byte char<br><br>$UC-:<br>string = old Delphi string<br>UnicodeString not known<br>char = 1 byte charPeternoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-25547804688012472952008-01-09T14:01:01.000-08:002008-01-09T14:01:01.000-08:00Well, much as I hate to be the one making odd pani...Well, much as I hate to be the one making odd panic-stricken comments :) I did a "dir *.pas /s" on my components directory. 1377 Files, 33 megabytes of source code. And that's not counting several component suites that install elsewhere, like DevExpress. Sure, some of those components are still supported and might be updated in a timely manner, until I hear either "your existing components will work" or "codegear will fix them for you", I remain shaken.<br><br>It seems much more sensible to support chars and wide chars side by side and let people migrate at their own pace. The community managed to make stings and unicode strings work side by side without help from codegear (ala TNT)... Codegear could do that even better, and make it standard for people to build on. But forcing us all to migrate in an all or nothing manner... ouch...DanBhttp://www.digitaldominion.comnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-23011259027260082272008-01-09T15:16:55.000-08:002008-01-09T15:16:55.000-08:00I agree with C. Johnson in regard to not using XML...I agree with C. Johnson in regard to not using XML as .DFM file format for the IDE.<br>My experience (better our all inside our companies area) has shown that the software products we use to develop controllers slowed down dramatically since they had been ported from Win32 to the .NET platform.<br>Don't get me wrong - it is nothing in general against .NET but it is somehow easy and state-of-the-art to put all data into XML files there and those have to re-read later as well during a build or compile run (and that takes longer; in our case around 2,5 to 4 times slower than before XML files usage).<br>This makes us losing time doing programming (during compile we can't code...)HHoffmannnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-13510075450138922232008-01-09T16:26:24.000-08:002008-01-09T16:26:24.000-08:00Peter Wrote:> $UC-:> UnicodeString not known...Peter Wrote:<br><br>> $UC-:<br>> UnicodeString not known<br><br>IMO, the compiler should not map UnicodeString to a String type when the $UC- switch is in use, but the UnicodeString type should still be available.Simonnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-73345002768886399652008-01-09T17:32:36.000-08:002008-01-09T17:32:36.000-08:00I have to convert dfm's from text back to bina...I have to convert dfm's from text back to binary on a weekly basis. When there is more than around 32MB of dfm-files to compile, the linker craps out with an internal error, especially when compiling bpl's. Converting a few dfm's to binary so that the total is under 32MB usually helps. This is io Delphi 6. Are newer versions bettar at this?Ottar Holstadnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-1991896557961465092008-01-09T17:49:56.000-08:002008-01-09T17:49:56.000-08:00C Johnson, HHoffmann, he explicitly said .dfm XML ...C Johnson, HHoffmann, he explicitly said .dfm XML discussions should not be done here. Since you dropped the apple: I think what you say about slowdown from .dfm text to xml is bull* (excuse the language). This is entirely dependant on how the parser is done. Old .dfm style are limiting and generate just as big or bigger files, and actually have less potential to be fast. But they should do their own (or free existing fast) traverse parser instead of using MSXML.Atle Smelvaernoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-11460548852501253702008-01-09T18:00:57.000-08:002008-01-09T18:00:57.000-08:00I assume old string indexes will still work the sa...I assume old string indexes will still work the same for the new?<br><br>var<br> s: string;<br>s := 'Test';<br><br>length(s)=4 and s[4]='t'?Atle Smelvaernoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-73908190529603598182008-01-09T18:37:17.000-08:002008-01-09T18:37:17.000-08:00As most, I am somewhat divided on the .dfm's a...As most, I am somewhat divided on the .dfm's as xml (.dmfx?), but I see one clear advantage: Future component versions that add/remove attributes can allow using the same .dfmx on two different Delphi versions without the unknown or missing property problems. Unknown/unused properties can be preserved.<br><br>Another advantage: Making tools that can interact with the .dfm files without actually knowing the classes on the form will be significantly easier with an xml based format than working with today's typed .dfm contents. <br><br>In theory, a .dfmx could support adding additional attributes to form content that doesn't necessarily map to delphi class published properties. One idea would be to embed help comments linked to fields for a help generation tool.<br><br>In addition, you have significantly improved the possibilities of seamless localisation of f.x. form texts.<br><br>As for space consumption - there is always the .dmfxz option? :)<br><br>On the Unicode String mapping - What actually happens to Char? Will it also become Unicode? The impact of changing the implicit underlying string format to Unicode will prolly need some new errors/warning for us that like to fiddle with individual characters in strings. Maybe we need some new string tools to make it more efficient?Lars Fosdalnoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-16610181096797167352008-01-09T21:49:51.000-08:002008-01-09T21:49:51.000-08:00I agree that the DFM should be XML and that openin...I agree that the DFM should be XML and that opening up the XML parser as an open source project would mean the community would make is scream (FastMM project). But we are here to talk about Unicode.<br><br>What I would like to see sooner then later as we could start looking at our code now, is a tool that would point out possible problem areas in your code.Tom Millernoreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-60559641879122050872008-01-10T00:20:34.000-08:002008-01-10T00:20:34.000-08:00Chris, That code would work just fine.Allen.Chris,<br><br> That code would work just fine.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-51914829932536943432008-01-10T00:22:42.000-08:002008-01-10T00:22:42.000-08:00Exactly what advantage do you get from a DFM as XM...Exactly what advantage do you get from a DFM as XML? The extra size and parser overhead seem to negate any advantages.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-15546157931412410692008-01-10T00:23:50.000-08:002008-01-10T00:23:50.000-08:00Atle, Element index is no different than before. ...Atle,<br><br> Element index is no different than before. That code works fine.<br><br>Allen.Allen Bauerhttp://blogs.codegear.com/abauer/noreply@blogger.comtag:blogger.com,1999:blog-2428374771421713311.post-28601089951990206242008-01-17T12:21:20.000-08:002008-01-17T12:21:20.000-08:00Ad #1, #3 :I think it is very important for us to ...Ad #1, #3 :<br>I think it is very important for us to have the "compatibility switch" between Unicode and non-Unicode (similar to {$H+} . <br>I am not so concerned about my applications in which I could change easily all types from String to AnsiString but about all my third party tools, many of which are pretty legacy and whose inner workings I do not understand so much.<br>Without the compatibility switch many of us would be stuck with D2007 for a very long time which could have quite a negative effect on sales of new Delphi versions. It would also create a demand for a long-time support of D2007.<br>Summing it up : not having this compatibility switch would be a very unfortunate decision IMO.Pavel Snoreply@blogger.com