Anders Melander

Marketing strategy? Really? Just because you disagree with the decision to deprecate it doesn't make it a stupid decision, driven by "marketing". The deprecation of "object" was also controversial but that wasn't driven by marketing either. I'm pretty sure management, marketing and sales couldn't care less about these things.

I hope Joe is better at coding than designing web sites 🙂

I too miss Rudy, but to be honest he was also the main reason I stopped participating in the old fora; So many interesting topics deteriorated into endless yes, no, yes, no, discussions. That and the misuse of moderation power that were going on killed my interest.

Sure, except you simply have another version of Windows to support, which is typically another VM to keep around. It would be nice to delete the old Windows VM and simply use the latest version of Windows to support all of your projects, including the ancient ones.

Or even one 😱 ( 🙂 )

You are probably right on that, but do the software running on those systems really need to be supported by Delphi 11? I doubt it.

Yes, they probably realized that there's no reason to resort to hacks when there's better solution

Support for older versions of Windows doesn't come for free. Official support means that they need to test against those versions and that they can't use the APIs of newer versions. Given the minimal market share of XP it hardly seems worth using resources to support it. If support for XP is required then use a version of Delphi that supports XP instead. I myself am on Windows 7 and if (when) that breaks Delphi then I will only blame myself.

It's relevant when you're wondering why they can't get it working properly. I'm not sure but I seem to remember that the formatter was written in J# or some horror like it. Technical debt indeed. Their solution to that appears to be letting those old features rot until everyone has given up on them and then remove them from the product. On that account, the formatter and refactoring features days are numbered. Fair enough; We all have to work within the limits of available resources. So let someone else work on those tools that they can't maintain themselves. What's to lose? Anyway, I known very little about LSP but if it can supply a good detailed DOM then I guess one could write a better formatter on top of that with relative ease. A few years back I looked at writing a formatter, using some of the available Delphi parsers, but none of their DOMs were detailed enough for the purpose.

Please do. The name helps no one and just adds confusion. I don't know why they thought it would be smart to name versions. I have to google it every time someone refers to a version by name.

It's transparent when the mouse isn't near it. When the mouse is over it it becomes fully opaque. Just like the one in MS Office. Personally I don't much care for that control as it usually gets in the way of what you're doing - but as you can see I've used it in a few places (above is from Better Translation Manager).

DevExpress TdxRibbonMiniToolbar https://www.devexpress.com/subscriptions/new-2011.xml#vcl https://community.devexpress.com/blogs/ctodx/archive/2011/02/17/sneak-peek-the-winforms-ribbon-gains-a-mini-toolbar-coming-in-v2011-vol-1.aspx

No. Here's some more clues: https://en.wikipedia.org/wiki/Font https://docs.microsoft.com/en-us/windows/win32/gdi/fonts-and-text

Maybe this is a clue that you're using fonts for something that they were not intended for...

Are you sure about that? I believe TMS purchased their run-time design controls (OI, form designer, etc) from some Chinese gentleman. AFAIK the same person that was the author of the K-Wizard controls. I'm using his original controls in my Resource Editor:

Since you don't want to hear about alternatives the only solution you have is owner drawing the listbox. A Google search would have given you that answer and it would also give you examples of how to do it. Start here: https://docs.microsoft.com/en-us/windows/win32/controls/about-list-boxes ...or simply use a TListView.

Okay. I thought that maybe the typelib you're using had its own declaration of IComparable. I'm guessing the IComparable stuff is a mistake made by the typelib importer. It doesn't make much sense to me otherwise. Since you're using dispatch interfaces (i.e. late binding) anyway the solution could be to simply access the properties through IDispatch and ignore the concrete interface declarations. You can do this quite easily by using the OleVariant type: var Fontsize: OleVariant; begin Fontsize := CoDocumentFormat_OpenXml_Wordprocessing_FontSize.Create; Fontsize.Val := '40'; end; This is basically the way VB does OLE automation.

Can you show us the declaration of IComparable ?

From what I can see, by reading the source, the only place SysUtils.Format is called is in EJSONParseException.Create. TJSONObject.Format ends up calling TJSONString.ToChars to encode the chars and I can't see anything there that would choke on %. Regardless, it would be trivial for you to look at the call stack when the exception occurs to determine where SysUtils.Format is called from.

What errors?

Plastic Merge can do move detection. You might have more luck with that. https://www.plasticscm.com/features/xmerge

I can save you 70 minutes there. The key point of Chandlers Efficiency talk is "Cache locality is very important". The remaining 60 minutes are just circus IMO.

Why not just set the absolute scollbar position of the listbox based on the position of the checklist scrollbar position?

Hardly relevant since it's about GDI+. They are not the same. pfDevice creates a DDB while all the other create DIBs. I don't know why you would prefer DDB when you're working with bitmaps that large. Use DIBs instead. They are backed by virtual memory. There are way too many unrelated things going on in your example for me to investigate it. Instead of juggling different bitmaps just size TImage->Picture->Bitmap and draw on that.