Leaderboard

Major improvements: New context sensitive toolbar at editor bottom (eoContextToolbar option) https://www.youtube.com/watch?v=TdWafp0xyPA Image selection toolbar. 40% faster style and layout calculation Support for inlined truetype fonts (@font-face... data:font/truetype;base64) Support for CSS tab-stop decimal and tab-interval CSS word-spacing and letter-spacing properties Magnifier when selecting text on Android and iOS Local links navigation (Click in HtPanel, Ctrl+Click in Editor) Subscript and superscript actions for selection and context toolbars. Linux: support for copy/paste formatted HTML and paste RTF Advanced charts (gradients and more: see Charts 2 section in Reports demo). Full list: https://delphihtmlcomponents.com/new43.html What is HTML Library: the only true native HTML/CSS/SVG engine for Delphi, all Delphi versions, all platforms, VCL and FMX. Rendering using GDI, GDI+, Direct2d, FMX canvas, text canvas and native iOS, OSX and Android canvases. CSS animations and transitions, animated GIF support for all platforms. RTL languages. WYSIWYG HTML editor, import from RTF and DOCX, export to PDF. Interactive HTML/SVG Reports with charts. FastReport, ReportBuilder, VirtualTreeView, SynPDF, Addict and DevExpress spellchecker integration. Pascal scripting engine. SQL library for parsing, analyzing and transforming SQL queries and working with database schema. Universal Email library for sending and receiving emails.

I'm a bit puzzled here, because usually it is a big no-no to assign code to a published event in a descendant component. Because the event is still published and anybody using your component can assign something else to this event and your added functionality is gone. Usually you should override the method which calls the event, add the functionality and call inherited. Only: Looking at the source code I see that this method (DoReceiveData) is both private and not virtual, so there's no chance to do it this way. I wonder whether there's a reason the Delphi developers did it that way, or why have they abandoned the usual component design patterns? Anyway, I would at least unpublish these events, along the lines in https://stackoverflow.com/questions/53677049/hide-properties-and-events-in-new-component

There are TONS of places throughout the VCL where the original developers could be accused of not thinking through the various use-cases enough to have a clear idea of what methods should have been tagged as protected rather than private. I think they tended to err on the side of keeping things private that didn't have obvious reasons to override them at the time. I see plenty of libs where the devs went the other way and stuffed nearly everything into the protected section instead of private, leaving a huge invitation to hack the crap out of things. I've often run into this situation in my own code, where I needed to override a method in a child class but I left it as private in the parent/base class instead of protected. It just didn't occur to me that I'd ever want to use it in a child class. Honestly, this is an area that you could spend a ton of time sweating over prior to a product release, and if you're in a hurry like most projects, it just never gets addressed. And that's why there are hacks for that ...

We need a real RawByteString without ANY implicit conversions. Just show a compiler error when trying to implicitly convert a string. Or improved TBytes with copy-on-write and all manipulation routines.

I would use RawByteString in this case, despite the warning in the manual. (Actually, that's what I do in such cases.) I don't think these strings will be thrown out of the RTL in the future. Use raw byte strings inside the module, explicitly converting them to Unicode strings in the output.

A fix, or rather workaround was to set the main panel's visibility to False and then True again in the FormShow event. fixed in revision #3312 At least I hope so.

That's why hard-coded index should be avoided where possible. @str[1] => Pointer(str) @arr[0] => Pointer(arr) for i := 0 to Length(arr) => for i := Low(arr) to High(arr) / for elem in arr Low and High for strings will also work in modern compilers

Some common RTL string manipulation functions have several overloads - including RawByteString one. If you use such function on AnsiString, you will trigger automatic compiler Unicode conversion. Using RawByteString will just use appropriate overload. There might be other differences, I haven't been fiddling around 8-bit strings (writing new code, besides the one I already have) for at least 5 years now. None that I have found so far. I am using RawByteString for mixed ASCII/UTF8/binary data for 10 years now. No problems.

Marco Cantù has a comprehensive guide to Unicode, ANSI, RawByteStrings etc.

Some of this new fangled stuff is just not worth the effort. Now get off my lawn! 😉 OK, I'm getting old. More and more grey hair and receding hairline are obvious telltales. (My grandma was using the German expression "neumoderner Kram". Back then (in the 1960s) she was talking about the telephone with a dial. Having a private phone line was still something special in many areas of Germany in that time (so I heard). She never really learned the customary protocol for using it, that is, stating her name when calling. That was back then when phones didn't even display the caller's number, so you didn't know who was calling. Some kids nowadays are the same, they never learned it, because "nobody uses a phone for calls any more". And they are basically right: I rarely use my smart phone to make calls.)

Possible starting point for playing: unit FrmMain; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, System.Math.Vectors, FMX.Controls3D, FMX.Objects3D, FMX.Viewport3D, FMX.MaterialSources; type TFormMain = class(TForm) Viewport: TViewport3D; procedure FormCreate(Sender: TObject); private Text: TText3D; Camera: TCamera; MS: TColorMaterialSource; end; var FormMain: TFormMain; implementation {$R *.fmx} procedure TFormMain.FormCreate(Sender: TObject); begin ReportMemoryLeaksOnShutdown := True; Width := 800; Height := 600; Viewport.Position.X := 10; Viewport.Position.Y := 10; Viewport.Width := 640; Viewport.Height := 480; Camera := TCamera.Create(Self); Camera.Parent := Viewport; Camera.Position.Z := -100; Viewport.Camera := Camera; Viewport.UsingDesignCamera := False; MS := TColorMaterialSource.Create(Self); MS.Parent := nil; MS.Color := TAlphaColors.Dodgerblue; Text := TText3D.Create(Self); Text.Parent := Viewport; Text.WordWrap := False; Text.Stretch := False; Text.Depth := 3; Text.Height := 10; Text.Width := 100; Text.Scale.X := 1; Text.Scale.Y := 1; Text.Text := 'Sample Text'; Text.RotationAngle.X := 20; Text.MaterialShaftSource := MS; end; end.

I sympathize with the OP, I have the same problem often, data streams containing a mixture of text and binary. - Many communication components for RS232 (such as good-old Async Pro) have receive events which pass a string. So far I haven't seen any that has the decency to pass a tBytes. - With modems (both the old-fashion ones and modern cellular 4G ones) one communicates in the "Hayes" protocol which is text-based until the connection is established, then the data stream becomes binary.

Have you planned to release a compiled update?

NetHTTPClient has one huge advantage... When working with SSL/TLS it uses the system api and you don't have to fight with openssl, certificates etc.

Even AnsiString is back, but you can safely use RawByteString and UTF8String. Original version of NextGen compiler didn't have support for 8-bit strings, but it is not brought back just because of community demands, but because UTF-8 is commonly used Unicode encoding, especially on Linux. So RawByteString and UTF8String were introduced in NextGen as a step toward supporting Linux. Now when NextGen is gone, you can also use AnsiString, but that type is really legacy nowadays and it makes no sense to use it beyond that.

TBytes.

The work around looks like it has done the trick. I have tried to replicate the original problem in 10.3.3 and 10.41, both appear to operate fine now... no more blank screen. Thanks heaps.

Here is another idea - instead of flashing the Button itself, place it inside a Panel whose borders appear slightly beyond the Button's edges, and then flash the Panel as needed. Or, create an alpha-blended overlay window, place it over the Button, and then hide/show the window as needed.

For those on older Delphi versions, there is still Andreas "DDevExtensions", which offers a function to disable the Explicit*-properties when saving the DFM file: https://www.idefixpack.de/blog/ide-tools/ddevextensions/

In fact first attempt was to integrate this little patch into GExperts. There is already GX_VCLFixPack.pas, which is a slightly modified version of Andreas' VclFixPack.pas. It is currently not in use (disabled by $IFDEF) and needs some cleanup, e.g. remove unused and old Win95 code 🙂. But for a "complete" GX Expert it would be neccessary to have at least an on/off configuration switch in the IDE settings section; but I did not dig deep enough to implement such a thing. And some kind of documentation would be helpful, too. Maybe I'll find some spare time at the weekend for creating a patch to GExperts.

Reminds me of the time I tried to teach the great grandparents to use a mobile phone...

Flashing can be quite visually aggressive. It is often preferable to highlight a control in some other way.

Imagine if you have users with names that don't begin with one of the 26 letters used in the English language? What you should do is abandon this UI approach and let the user type.

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

I'm thinking about not bothering any more. Maybe have a generic installer for the additional files and registry entries required and letting the user compile his own DLL.. On the other hand there seem to be many Delphi developers who are adverse to compiling it on their own.