Leaderboard

I guess in the IDE, you draw for example 12 px box, but whole IDE is scaled by Windows, so that it is displayed as 24 px (example). In running application, if your application is HDPI enabled, than Windows does not do the scaling. So original checkbox is drawn 24 px, because it is able to do it by itself, but your component is drawn 12 px, because it does not calculate proper size.

Dear visitors, I like to notify you that new version of NextSuite (VCL) is released. NextSuite includes always growing set of VCL components. Most important components are: NextGrid6 (StringGrid/ListView replacement, written from scratch). NextDBGrid6 (Db variant of the grid) NextInspector6 - An object inspector component. and many more. Now we also offer huge 40% discount for visitors of this website. Use DELPHIPRAXIS coupon code when ordering. Few screenshots:    Download big demo project from: http://www.bergsoft.net/downloads/vcl/demos/nxsuite6_demo.zip Please read more at: http://www.bergsoft.net/en-us/article/04-04-20  Website: www.bergsoft.net

Look at StartDomSrv in OverbyteIcsSslX509Certs.pas which sets up the simple web server with a newly generated localhost certificate, and CreateAcmeAlpnCert which will create a normal non-ALPN certificate if you leave KeyAuth blank, but that does not matter for your purposes. Which OAuth2 system requires HTTPS for the callback? Seems over the top since only your local browser displays the result. We should probably handle that in the REST component properly. Angus

Android Apple the same. See your Delphi publishing to the market. You can compile for the market. When you compile for Android under configuration there is "Application store". On D10.2.3 See Delphi help

No problems here either. It really looks like a problem with your system and not with Delphi. So you might think about the title of this topic a little more.

Is your component visual (derived from TControl)? Or is it non-visual (derived from TComponent)? Non-visual components can be used in both VCL and FMX without splitting up the implementation (just IFDEF the pieces you need). But visual controls take more work to design for separate frameworks. Then those lines should be in separate units. The rest of your code should be in a common unit(s) that the framework-specific units can then use. This is where Unit Scope Names come into play. Create separate VCL-specific and FMX-specific projects with appropriate Unit Scope Names specified in the Project Options, and then don't use any Unit Scope names in your code. That way, you have less IFDEF'ing to do. Your common gtDocumentPrinter code should be in its own separate unit, not in an include file. All the more reason not to use an include file.

Probably because the IDE is not HighDPI-aware, so it gets stretched by the OS. It wasn't necessary to show EVERYTHING, most of that code is not related to painting.

Not so much thanks to resources https://stackoverflow.com/questions/388506/displaying-splash-screen-in-delphi-when-main-thread-is-busy/45465592#45465592

You can not change an signed iOS, MacOS or Android app, if the app is not yours. But if you have the source, the app is your, you have many options to save the resources strings, you can save in particular files for it. When we are talking about resources strings for translation, this will allow the store to make smallest packages of your app, because it will not delivery the unnecessary data to the user. For example, a French language will not be included in a user that use English language ... However, this languages files isn’t usually big, and I personally prefer to make a cross platform solution, languages in the source code. Other solution is storing it in a SQLite.

I would love that too!

@Primož Gabrijelčič From the wishful thinking department: I'd love to see OTL evolve to support Linux/MacOS, iOS and Android. Hence, I'd love to see solutions that do NOT use Windows messaging - or at least hide it inside the notification implementation.