pyscripter

Just reported two QA issues relevant if you are planning to use/deploy TEdgeBrowser: https://quality.embarcadero.com/browse/RSP-31163 https://quality.embarcadero.com/browse/RSP-31170

This one was fixed in 10.4 https://quality.embarcadero.com/browse/RSP-23093 @NamoRamanaYou should provide a simple test case that reproduces the issue. Otherwise we are all guessing and hand-waving.

TControl.SetParent contains the following code: if not (csLoading in ComponentState) and not (csDesigning in ComponentState) and not (csDestroying in ComponentState) and not (csFreeNotification in ComponentState) then begin if not (csDesigning in Parent.ComponentState) then ScaleForPPI(GetParentCurrentDpi); end; Apart from the fact that I would write the if condition as if [csLoading, csDesigning, csDestroying, csFreeNotification] * ComponentState = [] then does anyone have any idea why controls with csFreeNotification are not scaled? This makes writing per Monitor DPI aware applications much harder.

The workaround for both issues is to follow a pattern such as this: Form.SetParent(Panel); Form.HandleNeeded; Form.ScaleForPPI(Panel.CurrentPPI);

This is another tough one to work around: procedure TCustomForm.ScaleForPPIRect(NewPPI: Integer; NewRect: PRect); var LCurrentPixelsPerInch: Integer; I: Integer; PriorHeight: Integer; begin if not (csDesigning in ComponentState) and ((not HandleAllocated and (Parent <> nil)) or (NewPPI < 30)) then Exit; Parented forms with unallocated handle are not scaled (e.g. page-like controls). It becomes even harder since TCustomForm.SetParent destroys the handle if the form had no parent. This is irrespective of FreeNotifications.

https://community.idera.com/developer-tools/b/blog/posts/august-2019-delphi-android-beta-plans-august-roadmap-update It was planned for mid-2020. But it is late.

@Uwe Raabe Thanks! Good to know I am not the only one bitten by this (should have checked QA), but bad to know it has not been fixed for quite some time now. I placed my vote on the first issue. You can work around the bug by manually calling ScaleForPPI(future parent PPI) before setting the parent but it gets difficult to get right with things like docking. Embarcadero will face this issue when they try to make the IDE per monitor DPI-aware as promised.

Does anybody know why WideStringToUCS4String adds 0 zero as the last character? Surprisingly, Length(WideStringToUCS4String('')) returns 1 and Length(WideStringToUCS4String('abc')) returns 4.

The issue is the in-memory representation of USC4. Should it have the redundant (obviously, no need to make the same argument multiple times ) #0 or not? And I argued that for inter-operability (passing a pointer to external functions expecting null-terminated UCS4) it is better that it always includes it despite the redundancy. And this is what the RTL assumes and does.

You don't have to use USC4 for that and using USC4 would not solve this problem. There are mainly two issues: 1) Surrogates pairs (two widechars correspond to one glyph) UCS4 would help with this one. UTF-16 Encoding: 0xD83D 0xDCBC “💼” 2) Combining characters (more than one Widechars shown as one glyph). But UCS4 would not help with this one. Åström ḱṷṓn Precomposed vrs Decomposed ḱṷṓn (U+1E31 U+1E77 U+1E53 U+006E) ḱṷṓn (U+006B U+0301 U+0075 U+032D U+006F U+0304 U+0301 U+006E) Windows provides CharNext/Prev that deals with both issues, but not perfectly. You have to use Uniscribe or DirectWrite for greater accuracy. In SynEdit there is this function: function SynCharNext(P: PWideChar; out Element : String) : WideChar; overload; Var Start : PWideChar; begin Start := P; Result := Windows.CharNext(P); SetString(Element, Start, Result - Start); end; It is very easy to write an enumerator that works with CharNext.

Why should any Delphi program use UCS4? The main use case is for inter-operability. You would need to pass the result to some external function. Having to manually add the null-terminator, would be inconvenient.

I suppose this is understandable. The Windows world is on UTF-16 and the rest on UTF-8. UCS4 (UTF-32) is very rarely used. With the benefit of hindsight, UTF-8 would probably have been a better choice for Windows. Now Microsoft is trying to bring UTF-8 back into Windows via the A routines and by offering to make UTF-8 the default character encoding.

It needs to be when you interoperate with libraries in which the default character encoding is USC4 (eg. python API on Linux https://www.python.org/dev/peps/pep-0513/).

This was all covered in

Project Magician is wonderful and a must for all Delphi programmers. Thank you @Uwe Raabe. However I recently run into the following problem. As I was debugging, whenever I tried to step into Vcl.Graphics the file would open and get marked as modified. Moreover stepping into the code would not work. Also when I opened Vcl.Graphics and some other files in the IDE, it would automatically marked them as modified. I was puzzled. I thought this was a new bug in the 10..4.1 Delphi IDE. But it turns out this was due to a Project Magician, otherwise very useful option to "Clean Line Feeds" under global settings. Vcl.Graphics has mixed line breaks in Delphi 10.4.1, so whenever it is opened in the IDE it would be automatically marked as modified since the mixed line breaks were detected and marked for fixing. And then debugging is hampered + you get all these annoying messages about the IDE being unable to create a backup. One suggestion to @Uwe Raabe is that Delphi library files are excluded from line-feed cleaning.

@Uwe Raabe One issue I had recently was with the IDE crashing badly when going View Form as Text and then back. I disabled Project Magician and the issue went away. Using Delphi 10.4.1 and the latest version of Project Magician. Delphi Magician options: The crash also occurred with a fresh VCL application and an empty Form.

@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.

InputBox/Query are still broken.

There are a number of ways to reduce scaling time: If you are using VirtualLists with many Icons try RtlVclFixes.pas Use ParentFont := True in child controls to avoid scaling fonts For custom components try to fine-tune/override DefaultScalingFlags

!? Why not 96 to avoid scaling?

procedure TForm1.FormAfterMonitorDpiChanged(Sender: TObject; OldDPI, NewDPI: Integer); begin LockWindowUpdate(0); end; procedure TForm1.FormBeforeMonitorDpiChanged(Sender: TObject; OldDPI, NewDPI: Integer); begin LockWindowUpdate(Handle); end;

The TitleBarPanel is used by the IDE. I guess it was developed to resolve the problem with the disappearing/flickering controls of the IDE title bar (search, layout controls, etc.), It can accommodate Toolbars (including the ActionMainMenuBar) and other controls, so you can place the main menu on the titleBar (see the sample app). And to answer the original question, you would need to manually adjust the Titlebar colors every time there is a style change. This is probably how the IDE styles its TitleBarPanel. @Vincent Parrett I also do not like the overcrowding of TForm and other controls with rarely used properties. (e.g. CustomHint that can be linked to a Balloon Hint all but abandoned - not DPI aware).

Regarding the RenderTarget I showed the code above. For details have a look at https://github.com/EtheaDev/SVGIconImageList/blob/master/Source/D2DSVGFactory.pas) . What I am suggesting is that you build your app as if it was a GDI app. And just use D2D in your painting code (override Paint, OnPaint event etc) utilising a single DCRenderTarget.

You can get a Device context from the Render Target. I am using ID2D1DeviceContext5 which was introduced with the Creators Update. if Supports(RenderTarget, ID2D1DeviceContext5, DeviceContext5) And as I said you do not need (multiple) D2D Windows. Just use standard forms and one DCRenderTarget to use in the OnPaint event of the form or by overriding the Paint method of Controls. And in terms of speed D2DSVG renders 300 svgs to bitmaps in less than 15ms.

The most common way do text-processing in Delphi is to load a file into a TStringList and then process the text line-by-line. Often you need to save the contents of the StringList back to the file. The TStringList is one of the most widely used RTL classes. However there are a number of limitations discussed below: a) No easy way to preserve line breaks on Load/Save TStringList does not make any effort to recognize the type of line breaks (LF, CR or CRLF) in the files it opens, let alone save that for use on saving. b) Information loss without any warning or any option for dealing with that. Internally TStringList uses unicode strings, but when you save its contents to a file using the default encoding (ANSI), this may result in information loss, without getting any warning or having any means for dealing with that. TEncoding.GetBytes also suffers from that. c) No easy way to determine whether a file you loaded into a TStringList contained a BOM When you load a file (LoadFromFile method), the encoding of the file is stored but not the information about whether the file contained a BOM or not. The WriteBOM property is only used when you save a file. d) Last but not least, no easy way of dealing with utf8 encoded files without a BOM The default text file format in Linux systems, in Visual Studio Code and other editors, as well as in languages such as python 3 is utf8 without BOM. Reading such files with TStringList is problematic and can result in errors, because it thinks such files are ANSI encoded. You could change the DefaultEncoding to utf8, but then you get errors when you read ansi files. No effort is made to detect whether a file without a BOM contains utf8 sequences. Overall, it is desirable that, when you load a file using LoadFromFile and then you save it using SavetoFile, the saved copy is identical to the original. I am attaching a general purpose TStringList descendent that deals with all the above issues in case anyone has a use for that. XStringList.pas