Tommi Prami

With OmniXML dom I got slightly closer procedure TForm10.Button2Click(Sender: TObject); var LXMlDocument: IXMLDocument; LDomList: IDOMNodeList; LValueNode: IDOMNode; I: Integer; begin DefaultDOMVendor := sOmniXmlVendor; LXMlDocument := LoadXMLData(Memo1.Lines.Text); LDomList := LXMlDocument.DOMDocument.documentElement.getElementsByTagName(TAG_IBAN); for I := 0 to LDomList.length - 1 do begin LValueNode := LDomList[I]; Memo2.Lines.Add(LValueNode.nodeName + ': ' + LValueNode.nodeValue); end; end; it find the tags, but nodeValue returns empty. -Tee-

Wrong Group... Sorry

Please don't hijack the conversation to offtopic.

Current 24" monitor with 1920x1200 has DPI/PPI (what ever) that makes most of the default fonts, like in Delphi ide too small (for me). Solutions I can think of Monitor with lower DPI but not smaller resolution (Cause now the desktop size is pretty limited). But all larger monitor seems to be 4K Way to change IDE font(s) to larger, not just code, which I use now size 12, but it gives me already just barely room horizontally to see code. Get large 4K display (if can) and raise DPI from windows. but at least previously et opened kind of can of worms. Delphi really should normalize the dfm always to the native 96 DPI, so it would be consistent and easy to compare. Is that a problem, are there teams that coders use different DPI? And if problems, does it really matter? Am I missing some obvious solution, than Quitting my job and move into wilderness, away from all the technology?

"Our current LTS release is 1.0.2, and it will be supported until the end of 2019." Seems that 1.0.x is close at its end of life. -Tee-

My experience is that, if you are unlucky, bugs can lurk in multithreaded code way longer than in single threaded code. I have encountered (own and others) code, even single threaded, that should never have worked, but for reason or other, it always has been. Until it'll present it self in worst possible, time, place and way :D -Tee-

Added: -x-fpr generates 3 times faster stack memory page probing code (RSP-19826) Added: Options -x-O1, -x-O2, -x-O3, -x-Ox that enable other optimization options More info.... Hope these optimizations would come to Delphi compiler directly. https://andy.jgknet.de/blog/2017/10/ide-fix-pack-6-1-released/ https://andy.jgknet.de/blog/2018/06/ide-fix-pack-6-3-released/

As stated above, using other Dpi than 100% is not good. Because it'll affect into Dfm-files. And you just can't know is there true changes between two, if edited with environments with different Dpi. If Delphi woulöd normalize the dfm into 100% font sizes, and Form editor would be totally Dpi agnostic, at design time, it would be way easier to work in a team with different Dpi environments, -Tee-

How sharp was the text in that situation? -Tee-

Any models available for those specs... That would be better than nothing. Not more desktop area tough. -Tee-

Might be, but I would specifically need more than 100% font size if use 4K monitor, even on very large one. -Tee-

Pumped into this on, somewhere in here : https://github.com/zMotoR/IDEFont Seemed like perfect solution, but it'll change the Font size of the Form editor also, which leads into resized components on the form. Filed an issue for the projects, don't know is it possible to set font form by form, in the IDE; but that plugin is very close what would be good enough for me. -Tee-

At least we had to set all of our desktops (Previous versions of Delphi at least) to 100% font size/DPI setting, because Delhi will save the Dpi value to the Dfm, and sizes of components are scaled also. Should do quick test tough...

I use Win10, latest version. Previously Delphi saved the higher DPI to the dfm, and therefor you jsut can't compare changes on saved on different machines (with different DPI). Would be super cool if deDelphi would always save as standard 96dpi not the one dev machine happens to use. -Tee-

That issue is closed, is there duplicate, or why is that? Any idea? Issue states fixed in 10.2 if I understand...

Removed the experts from my Tokyo installation, works not, not optimal tough...

Yep, I also had XTokyo one, but will it just load wrong one...

Seems that there is only one ParnassusCoreEditor.dll in my system drive, and it is of version 1,6.0, and most likely not compatible with older plugins. -Tee-

I can confirm this... Damnation. 10.2 installation is pretty useless... 😞 Wouldn't matter too much, but that will be main IDE for a couple of weeks or so 😞 -Tee-

I would like to see this plugin to get more support, now that code is already there, and installer, maybe, to speed up the start... Edit, how anyone can understand what I menat, coz I can't 😄 Would be nice to have installer for different IDE-versions, so it would be easier to start using it. I would suggest, if possible, add some standard colorizxation of properties, but it should be configurable, but editing INI-file would be OK, to me anyways. Because there are so many components and different properties, and some are interested in very different properties... -Tee-

Seems pretty cool. Would like to have some way to set this up, maybe an .ini-file etc, to give some custom properties. Did not check the code, so don't know that was it your plugin, but colorization of properties would alonne help a ton. Sometimes you spend very long time for property like Name etc. -Tee-

This seems to be simple problem, but nothing but trivial. I think is very hard to get 100% right. Depending on use cases. Is it about user input or random set of Xml-files to read etc. This is one of those things that if there would have been solved by any standard from dawn of times. Too much variations. Dates and/or times are even worse, at least the Date part. If someone has tons of time and good test sets, would be good to have "Fuzzy string conversion library" which would at least try to make conversions like this. -Tee-

Sounds like a interesting project. Would be way better to use library for that kind of things than to make one of your one. most likely. -Tee-

Thanks for info. Benchmarking and measuring is not easy indeed.

Has anyone done benchmarking against regular Delphi lists (Generic or not). Would be interesting to see how much this helps. I was just pondering that I can't even make guess what the difference will be.