Memnarch

That is not right. Interfaces inherit from each other, and while an class only ever implements explicitly used interfaces, if you inherit IBar from IFoo, IBar has all methods from IFoo. if I do this: IFoo = interface procedure DoSomething; end; DoSomething is not the first but fourth method in the table as it derives from IInterface, which already has 3 methods. If I do this: IFoo = interface(IUnknown) procedure DoSomething; end; My method, when using the IUnknown from System.pas, is still the fourth method in the table. All those interfaces declared in the API deriving from IUnknown expect to have their first method, being the fourth in the table, too. And on the Windows implementing side, it is exactly this. They derive from IUnknown, which has 3 methods and does not derive from anything else. So the windows interfaces start with 4 as their first method slot, just like any interface you write in Delphi. However, given that IUnknown was just copied from the metadata during generation, in Delphi it derives from IInterface, which is Delphis "IUnknown". That way, it introduces 3 more methods to the table, making DoSomething of IFoo the 7th method. Therefore on the delphi side if you call DoSomething on the interface coming from a windows api class, you're off by 3 and call something entirely else. Looked into it. That one looks correct! Thanks for sharing this!

Hello, I need a second opinion on this. Either I am drunk or there is a huge error in the generated Windows units one can install through GetIT from Emarcadero called "Windows API from WinMD". If the following is an error, I'll create a ticket. If not, someone needs to explain this to me. I am trying to use IMMDeviceEnumerator from Windows.Media.Audio.pas. Calling GetDefaultAudioEndpoint, I was unable to get the defaultdevice. This is how the interface is declared: ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/mmdeviceapi/nn-mmdeviceapi-immdeviceenumerator</summary> ///<remarks> ///<para>Supported since: <i>windows6.0.6000</i></para> ///</remarks> IMMDeviceEnumerator = interface(IUnknown) ['{A95664D2-9614-4F35-A746-DE8DB63617E6}'] ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-immdeviceenumerator-enumaudioendpoints</summary> function EnumAudioEndpoints(dataFlow: EDataFlow; dwStateMask: Cardinal; out ppDevices: IMMDeviceCollection): HRESULT; stdcall; ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-immdeviceenumerator-getdefaultaudioendpoint</summary> function GetDefaultAudioEndpoint(dataFlow: EDataFlow; role: ERole; out ppEndpoint: IMMDevice): HRESULT; stdcall; ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-immdeviceenumerator-getdevice</summary> function GetDevice(pwstrId: PWSTR; out ppDevice: IMMDevice): HRESULT; stdcall; ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-immdeviceenumerator-registerendpointnotificationcallback</summary> function RegisterEndpointNotificationCallback(pClient: IMMNotificationClient): HRESULT; stdcall; ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-immdeviceenumerator-unregisterendpointnotificationcallback</summary> function UnregisterEndpointNotificationCallback(pClient: IMMNotificationClient): HRESULT; stdcall; end; Suspecting something in the method declaration (i.e. out) was wrong. I copied it over to my code...and it started to work? Like, I didn't change a thing or did I? So after being confused for a moment, I looked at the interafce it inherits from. When the Interface is in my code, due to the units in my uses, it derives from System.IUnknown which is declared like this: IInterface = interface ['{00000000-0000-0000-C000-000000000046}'] function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; end; IUnknown = IInterface; However, in the generated code, it derives from Windows.Foundation.IUnknown which is declared like this: IUnknown = interface ['{00000000-0000-0000-C000-000000000046}'] ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/unknwn/nf-unknwn-iunknown-queryinterface(q)</summary> ///<remarks> ///<para>Can return errors as success</para> ///</remarks> function QueryInterface(riid: PGuid; out ppvObject: Pointer): HRESULT; stdcall; ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/unknwn/nf-unknwn-iunknown-addref</summary> function AddRef: Cardinal; stdcall; ///<summary>Documentation: https://docs.microsoft.com/windows/win32/api/unknwn/nf-unknwn-iunknown-release</summary> function Release: Cardinal; stdcall; end; So unless I am missing something crucial, this IUnknown-Interface is adding the same 3 methods it already has thorugh the IInterface-Baseinterface and offsets the entire VMT by 3 entries across the board. And by adding/removing Windows.Foundation from my uses I can make the copy of the interface work/break at will. So this seems like an oversight and that IUnknown should just inherit from IInterface or be an alias, or am I wrong?

You are massively underestimating this 😛 If you refactor a base component other visual components dervive from, loading/opening projects might fail. I support the Idea that the ide still loads the dfm as text. Right now it does not allow me to look at it, which is cumbersome. Just like WPF in VS where I always get the XAML editor but not a visual editor when the XAML is invalid.

No that's just confusing wording. The resolution is actually fixed. What the sync comment means is: Expected behavior is seen in fix version. Had the same type of sync comment on one of my tickets and was confused at first, too.

We're already evaluating it. First impression: Promising! However, I'm not sure using GPLv3 is something he should've used, for what he tries to archieve with the dual license.

Exactly. An application has to identify itself as HDPI aware in its manifest. By default this is enabled for your Delphi-Application, but you can disable it. If not enabled, windows passes 96ppi to the application, and all width/height values of all controls are in 96ppi space. Windows then scales up the rendered picture to the actual ppi. This is the reason old applications look blurry. Today, Windows 10 implements a more enhanced gdi virtualization (called System enhanced) where the drawcall is scaled up, instead of the final render, which avoids blurry text/lines. But it's still noticeable on graphics of old applications, being stretched and blurry. You can switch to the old "System" method on an applications compatibility properties tab to see how applications were scaled up pre W10 180x(or was it 190x?) Something you have to credit Microsoft for, is their humongouse backwards compatibility. That's why HDPI was made an opt in, because applications have to manually deal with it. Similar to the WinVer thing they did with Windows 8 and 8.1. If the application didn't say it was aware 8.1 exists in its manifest, the system lied and looked like 8 on the api and file layer. The Delphi-IDE is not marked as HDPI-aware, and recent UI revamps of the IDE made it more incompatible with HDPI than ever. PS: Trick of the day: If you have an old non HDPI application were you draw text or shapes to a temp bitmap, make it device compatible using CreateCompatibleBitmap (TBitmap creates only device dependend ones). That way, when you set it to a resolution of x, the internal resolution of that bitmap is x*systemscale, the gdi system enhanced virtualization will affect it and it won't look blurry. Something the VCL does wrong for some temp buffers 😕

Nope, it's a windows issue The IDE is not supposed to "see" the 115 ppi -.-

WOW i just found out: The reason was me using "custom dpi scaling". I only wanted 115% and not one of the existing settings like 125%. Now it does work as expected....

Hi, At my company, I have 4K screens and a HDPI scale of 200%. The IDE works as normal, because it is not hdpi-aware. Windows is 10 1809 At home I have WQHD Screens and some slight scaling enabled. All IDEs from XE to 10.2 show a PPI of 115 instead of 96 in the Designer. Windows 10 1909 And i can't wrap my head around the issue. I told Windows to disable the system enhanced stuff. But for some reason the IDE is still fed with the true PPI instead of emulated, like normal non hdpi ones do. Anybody has any idea on what i can do? This does screw with ui i write for IDE-Plugins 😐

Hi, I just updated my header translation for LLVM 10. It's available on Delphinus or on my Githubrepo and comes along with the precompiled binary. http://memnarch.bplaced.net/blog/2020/04/llvm4d-llvm-c-headers-for-delphi/

Hi, Some might already know Delphinus. But for those who don't i thought i make a little introduction post, to have a thread for discussion, as I never made one for the international Delphi-Praxis. Questions are always welcome. Delphinus is an opensource Packagemanager for Delphi, which I started in 2015. It has support for Delphi XE and newer. In addition to an IDE integration for package-management, Delphinus comes with a commandline, too. This has the benefit of having a single interface for managing multiple IDEs or run setup-scripts automatically. Currently, packages are provided through Github by preparing a repo to appear in a special Github-Query Delphinus uses to detect packages (See wiki link below). For optimal use, you should add a OAuth-Token to the Delphinus-Config(See wiki link below). Otherwhise you'll hit rate-limits. Offline installation from a folder is provided through the IDE-UI(Folder Symbol). Adding support for creating local folder based repositories for mirroing is planned. Delphinus packages have support for: Copying (source) files Compiling and (if Designtime) installing BPLs Compiling and installing IDE-Experts setting up Search/Browsing path Dependencies to other Delphinus-Packages Optionally, BPLs and Experts may be included as precompiled binary, if your project is closed source. Packages are installed per IDE. I'm working on per project installations. GithubRepository of Delphinus: https://github.com/Memnarch/Delphinus Wiki: https://github.com/Memnarch/Delphinus/wiki My Blog were I (in addition to ther Delphiprojects) post updates about Delphinus: http://memnarch.bplaced.net/ Websetup: http://memnarch.bplaced.net/blog/delphinus/

I started working on support for installing packages per project, instead ide. http://memnarch.bplaced.net/blog/2020/03/delphinus-working-on-per-projectfolder-installation/

In the end, i did summon demons. And succeeded 😄 I'll share what this was all about soon(TM), once the stuff it's for is presentable. Edit: @Dave Nottage here is a blog with details on what it is for:

Hi, Before I start to summon demons, i wanted to ask if it is possible to add non-file related entries under a Project in the Project-Tree through the toolsapi? A Node like the existing ones, for example "Build Configurations" or "Target Platforms". From what i can tell, i can only add something, if it is an existing file?

My Softwarerenderer written in Delphi is now public under MPL-2 :) http://memnarch.bplaced.net/blog/2020/03/mundus-a-softwarerenderer-in-delphi/