Leaderboard

Rethinking Delphi Floating Point Control Register Management.pdf

One thing worth mentioning because you seem to take interface-class relation backwards. The whole purpose of interfaces (COM or native, or whatever) is that they are abstraction. They just define API, not the implementation. It is class that implements interface and knows about the interface, not the other way around. In other words, interface should never ever know anything about classes that implement interface and any proposals that violate that are practically useless.

What happened to that document? https://web.archive.org/web/20171221023547/http://qc.embarcadero.com/wc/qcmain.aspx?d=107411 Edit: I took the liberty of splitting David's answer into a new thread.

For me it is not money. I have later versions than XE7. For me there is no benefit to updating. Nothing released since XE7 has any significant benefit for me. For sure there are some minor things but nothing that really makes it worth the effort. And it is an effort for me because I have a whole bunch of patches that I apply to the RTL to address design flaws primarily in its handling of floating point. That requires bespoke code for each version and I don't currently think it is worth it. Plus I'd have to spend some time working with multiple versions because I need to maintain recent releases of our software. Now, if Emba did something about the very poor performance of the compiler code that dcc64 emits, I would upgrade without hesitation.

The way the Ctrl+Tab shortcut works in the Delphi IDE was always very inconvenient for me. Actually the Delphi IDE is the only program I can think of that does not navigate open documents based on the order in which they were last activated but instead on the order in which the tabs are arranged in the editor. So if you are were working in DocumentPrevious and switch to DocumentNext, I am used to going back to DocumentPrevious by hitting Ctrl+Tab. But in the Delphi you will navigate to whatever document is on the right side of DocumentNext. This has always been very annoying for me. Anyhow I made plugin that makes Ctrl+Tab behave to what I am used to from other programs, like Visual Studio for example. Might be of use for some. https://github.com/santiagoIT/DelphiCtrlTab Precompiled binaries are available for Delphi Seattle, Rio and Sydney.

What you display is known as "default interface methods" in other languages. Java has them and they are in the making for C#8 from what I know. However in both implementations those interfaces can just operate on other interface methods and not force fields of the implementing object - that would be more like scala traits (not exactly sure how they implement that ontop of the JVM)

They both have seen the document already.

It's usually simply money. Delphi updates nowadays cost an arm and a leg and on top of that you also need to upgrade the 3rd party tools and components. (I just bought 3 TeeChart licenses and accounting was having a fit. 😉 ) Others don't want to go through the trouble of updating because they can't see the advantage. And of course, it takes time and there is a certain amount of laziness involved. In my (the company I work for) case it's a mix of all the above. We are now in the process of upgrading to Delphi 10.2 + latest update (the last version that didn't annoy the hell out of me) after staying with Delphi 2007 for a long time due to the Unicode change. And I hope that one of the 10.4 upgrades will fix all those annoying bugs so maybe we will even upgrade to that version. That process proves painful as we still need to keep compatibility to Delphi 2007 with our internal libraries because we will probably never finish upgrading all those internally used tools. There are just too many of them. Oh, and then there are those who - for years - have been phasing out Delphi (because it's so 1990ies and nobody uses it nowadays) and porting their software to a different development platform, so they keep the old Delphi version around to maintain the programs that work until (in some far far way future 😉 ) the new software is actually ready.

In addition to constraining the window's size, you should consider giving the user visual feedback for their attempts to resize. Do this by handling the WM_NCHITTEST message: https://docs.microsoft.com/en-gb/windows/win32/inputdev/wm-nchittest type TForm1 = class(TForm) protected procedure WMNCHitTest(var Message: TWMNCHitTest); message WM_NCHITTEST; end; .... procedure TForm1.WMNCHitTest(var Message: TWMNCHitTest); begin inherited; case Message.Result of HTLEFT,HTRIGHT: Message.Result := HTCAPTION; HTTOPLEFT,HTTOPRIGHT: Message.Result := HTTOP; HTBOTTOMLEFT,HTBOTTOMRIGHT: Message.Result := HTBOTTOM; end; end;

Yes, as soon as you have the storyboard file created, it's going to be fullscreen. If you have a storyboard file, delete it. Launch Delphi, select iOS as your target and run the app. That should be enough

Delete the info.plist.TemplateiOS.xml file and rebuild. Alternatively, make it look like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <%VersionInfoPListKeys%> <%ExtraInfoPListKeys%> <%StoryboardInfoPListKey%> </dict> </plist>

@Kas Ob. Am happy it was useful for you and that you got it to work with D2010. 🙂 No idea about the crash when rebuilding the plugin. The oldest Delphi Version I have tested it with is Seattle and that problem does not occur there. I have never used D2010, that was before I got started with Delphi. If possible you could submit a pull request, might be useful for others as well.

Yeah, that's Quality Portal, the new place for reporting bugs. I submitted loads of reports at the old place, Quality Central, and then Emba killed it, along with all the bug reports. We were asked to resubmit the reports that we cared most about. Which was a load of work that I couldn't face.