Leaderboard

We used a workaround in our application to make a smooth transition from one monitor to another. I think the problem is not so much as refresh time but the fact that refresh kicks in when crossing monitor boundary. As a result user cannot continue moving the form (for refresh period) and this does not feel right. For smooth transition we detect the start of crossing using WM_ENTERSIZEMOVE and WM_MOVING. At that moment we ensure that the form does not update (e.g. WM_SETREDRAW) . Once movement is finished (WM_EXITSIZEMOVE) we let the form update. Still a lot of code gets executed even without refresh, so an additional trick was helpful. In our case the content of the MainForm was on an embedded form, so on crossing we set embedded form invisible and without parent. In that case it was not scaled so we avoided this on crossing. After crossing was finished we reinstated content visibility and the parent, which finished the scaling. To improve visual outlook we captured content onto scaled TImage and put it on top of the MainForm. As a result only TImage gets quickly scaled on crossing and provides (possibly blurred) visual feedback until content finishes scaling and is ready to show.

My version, is portable. I have installed it on a notebook

function (const arr: TArray<T>): RecWithTwoFields (Pointer, Integer) Bonus: inlining that function looks like this - go go eax, you got it eventually!

Please vote if you think the compiler could help us writing more robust code: https://quality.embarcadero.com/browse/RSP-33504

Hi there, I want to show you my approach how to organize and ease modular designs. Usually I like to have one main access unit, and all much granularized sub-features distributed in separate units. The main and sub-units build a kind of tree of functionality, where each unit can stand alone, but usually all units are highly related between each other. To access and open those deeper layer units is usually much of a click-drill-down the unit tree, or a lot of search and select via search function or other tools. Here is the general layout I like to use, which has a lot of advantages for me: unit My.Thing; interface uses My.Thing.Intf , My.Thing.Factory // // , My.Thing.Impl // QuickAccessUses // , My.Thing.Events.Intf // , My.Thing.Events.Carrier.Intf // , My.Thing.Events.Carrier // , My.Thing.Common // , My.Thing.Features // , My.Thing.Features.Factory // , My.Thing.Features.Impl // , My.Thing.Feature.Intf ; You can place the cursor on the unit names, even if its inside of a comment, and with right click "Open file at cursor" you can directly open the desired unit. The advantages I see from my point of view: - a single point of access, for a larger structural, modularized tree - immediately all of the close-related units are visible on the screen - directly see the kind of structure, maybe leads to further unit refactorings - it is a most easy and fast way to find and navigate to the desired unit, and to open it - no tipping of unit names into searchboxes The disadvantages: - None ( except putting some extra lines in comments ) I like this a lot, and this works only due to the fact that "Open file at cursor" works also within comments. Thats why I want to ensure that the Embarcadero team is aware of this, and never is going to change the open behaviour in the future editors

I prefer "Warror". It sounds better.

The correct word is "Warror", sometimes also called "Errning" /s

That is useful if you get paid by the LOC compiler generates-

Am I the only one annoyed that these are in System.Math?

Let's hope Embarcadero will soon finish testing the hotfix and will release it.

In my demo on a form full of different controls this line is not executed at all.

This is almost certainly due to old project library directories not suiting your new set up. You need to go through all the directories specified in your project options and make sure they match 10.2 requirements. As an aside: seems strange to upgrade at this point in time to 10.2 - are you sure you don't mean 10.4.2 (the latest version) ?

For start you can use the fix here https://quality.embarcadero.com/browse/RSP-30931 See also this Per monitor DPI awareness - how to prevent flickering? - VCL - Delphi-PRAXiS [en]

@Vandrovnik Brutal. Voted too. But I don't think they touch the compiler in the near future, however, I've noticed that reports regarding to the IDE are opened in a couple of workdays at the time and also being fixed. I'm surprisingly satisfied with that.

Install to Vm, take Vm file wherever you want = portable enough?

The proxy setters changes are now in SVN, with an updated OverbyteIcsSocksTst sample that now also tests HTTP Tunnelling, which we did not seem to do. Will be zipped overnight. I tested the HTTP Tunnelling changes against the ICS proxy server, which currently deliberately only tunnels HTTP, need to fix that, but have not tested socks since 7Proxy failed my 10 minutes to find out how to configure it limit, sure it works fine once you find some non-empty help files. Angus

@dummzeuchAll these limitations of LockWindowUpdate are well known and noted. Yes you should avoid using LockWindowUpdate if you can and prefer WM_SETREDRAW. Fully agree. WM_SETREDRAW was the first thing I tried and did not work. As Raymond Chen says in the above articles One can well argue therefore, that dragging a Window from one monitor to another is a valid case for using LockWindowUpdate. If it is OK to lock the whole desktop when you do OLE drag&drop it should be OK to lock a single window while dragging it between monitors, just for the time it rescales.

The basics of the HighDPi support origines from @Uwe Raabe. But his silution wasn't implemented in full range. https://www.delphipraxis.net/196643-high-dpi-patches-delphi-von-uwe-raabe.html https://www.delphipraxis.net/1419242-post4.html