Leaderboard

One of the new features of Delphi 10.4 was the new TEdgeBrowser component. It is nice. However the downside is that certain steps are needed for the use and delployment of this component: Install Edge WebView2 package via GetIt. This places a Dll called WebView2Loader.dll in the redist directory of Embarcadero studio (one for win32, one for win64). The appropriate WebView2Loader.dll needs to be deployed alongside your executable. (about 300Kb). While developing you can add a post-build event to do that. Now the difficult one was that you had to replace the stable version of Edge, installed and managed by Windows, with the unstable one from the Canary Edge update channel (daily updates). Event if you did that in your own machine, few users would accept it. The new thing, that is not mentioned in the documentation, is that there is a better alternative to the third requirement. You can use the WebView2 Runtime installer which works independently from and does not interfere with your browser, and can be safely deployed in customer sites. Give it a try.

How to call a private method of a class inside a Berlin+ class via Helper procedure TSomeClassHelper.CheckAccessToPrivate; begin With Self do begin // access via with works FInt :=1; SomeMethod; end; end; // Declared in another unit as: type TSomeClass = class private FInt : integer; procedure SomeMethod; end;

I imagine one of the biggest problems of being self-taught is missing out on some well-documented practices. Well, I confess that I did not know about the use of double-dabble to quickly manually convert a base-2 representation to base-10, for example: 1001000110 to 582. Quick blog post published today: https://www.ideasawakened.com/post/double-dabble-and-conversions-from-base-10-and-base-2-number-systems

OMG, @Anders Melander - I feel for you! Refactoring is hard with mastodont routines like that.

Yes, because with this WITHs it's very hard to do secure refactorings to solve other problems.

VMWare workstation will let you do this. Just add two virtual serial ports to the VM, in the field "connection" specify "named pipe". Both COM ports must use the same name for the named pipe (just call it "serialportpipe") and one port must be configured to be "server", the other must be "client". That way, the two COM ports are crosswired. Now you can start 2 applications, connect them up to the two COM ports and let them talk to each other.

Hundreds of lines of code within one routine and you think that *with* is the problem? LOL

I dnt knw bout u, bt I gt $ 4 the Q of my cde. Not for the amount of keystrokes I can save.

WTF? It's a bloody TMenuItem! That doesn't even have a common ancestor with TPopupMenu (apart from TComponent)! Who in their right mind would do that? Fixed in revision #3325

I am pretty fine with Advanced Virtual Com Port

Com0Com works for me (on Windows XP and 8.1 (haven't tested Windows 7 or 10), or simply a serial null modem cable that connects two serial ports, native or USB serial adapters.

Hello all, when Delphi didn't know about unicode yet people would often stuff binary data into strings because strings were soooo practical and easy to manipulate. Yes that is and was bad practice and highly frowned upon, but as we all know it was done anyway and people got away with it because Delphi didn't care about code pages at the time so it just worked. It was even done in professional libraries. Code like that is very hard to port to newer Delphi versions which are unicode-enabled and codepage-aware and when you attempt a conversion, subtle errors may happen where you least expect it. If you still have precious old code libraries that do such things and which would be too costly or too complex to rewrite, you may consider trying this workaround as a quick & dirty fix: Type Binarystring= type Ansistring (437); The nice thing about code page 437 is that all 256 possible ansichar values map to valid unicode code points so you can safely assign these strings to Unicodestrings and back again without data loss and Delphi's built-in string functions won't break the binary data contained in these strings. So you just may me able to salvage some legacy code by declaring this new type and then replacing all "string" declarations in the code with "binarystring" and all (p)Char with (p)Ansichar. And yes, it's still bad practice... (The idea is originally from Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20200831-00/?p=104142 )

Thank you Dave, that was the solution to my problem....you save my life 😁👍

They are. That's the a very plausible explanation. File corruption is something that does happen. You'll want to reproduce the issue before trying to solve the problem. And if it is file corruption then the solution is somebody else's problem.

If you don't need anything fancy, you can use System.ZIP (or the updated System.ZIP2, which is a drop-in replacement offering some extras). I'm using Zip2 with smaller modifications, works like a charm.

True, though 437 does not map every byte (in fact, many bytes) to a Unicode codepoint of same numeric value. For this task (when I have needed to use it in the past), I would use codepage 28591 (ISO-8859-1) instead, which has bytes use the same numeric values as their codepoints. Agreed. More accurately, there is no conversion only when an AnsiString(N)-based string type is assigned to it, as it will simply inherit N as its current codepage, but it does perform a character conversion when a UnicodeString or WideString is assigned to it, and when it is assigned to another non-RawByteString string type. So, even if you were to use RawByteString, you still have to be careful with how you use it.

Best way, 1- Export SDK from Delphi IDE Tools->Options->SDK Manager select SDK and export and import it in the new Delphi IDE

I know I am late to the party, but you might try the attached package for Delphi 10.4.1. It uses the hooking code from Andreas Hausladen's VclFixPack v1.4 to patch the TControl.DefineProperties method to a modified code, which does not write those Explicit* properties to the DFM file. Unpack the zip archive, open DControlsFix.dpk in Delphi 10.4.1, compile & install. There is nothing to customize. If this package is installed, the patch is active. If you like to get the default behaviour back, just uninstall the package. Use at your own risk 😉 DControlsFix.zip

I don't know the answer to the question, but it may be useful: https://github.com/malcolmgroves/FluentLiveBindings

Sure, but then XCode 13 will be out....

You have to use the Helper, only it and the use of WITH get you access, see my test code above. Plus that's not enough code for anyone to help you.. // Your helper should have a method like SetPrivateVar which uses 'With Self do' SomeClass.SetPrivateVar(TMyClassA2.Create());

I have this test setup to let me know if this is ever changed in a new version of Delphi. Should be simple enough to replace TCustomTextFile with whatnot and run the test which I just ran in 10.4.1 and it passed: //MMWIN:CLASSCOPY unit _MM_Copy_Buffer_; interface implementation type TTestAccessToPrivateFieldHelper = class helper for TCustomTextFile function SetPrivateOwnsStream(AValue: boolean): boolean; end; { TTestAccessToPrivateFieldHelper } function TTestAccessToPrivateFieldHelper.SetPrivateOwnsStream(AValue: boolean): boolean; begin with Self do begin FOwnsStream := AValue; Result := FOwnsStream; end; end; end. //MMWIN:MEMBERSCOPY unit _MM_Copy_Buffer_; interface type THelperTests = class(TObject) public [Test(True)] procedure TestAccessToPrivateField; end; implementation procedure THelperTests.TestAccessToPrivateField; var F : TTextFile; begin F := TTextFile.Create('testing.txt', TEncoding.UTF8); try Assert.IsFalse(F.SetPrivateOwnsStream(False)); Assert.IsTrue(F.SetPrivateOwnsStream(True)); finally F.Free; end; end; end.

You cannot access private fields of a class declared in a different unit. [Period] That is, if you play by the rules. There are various ways to still achieve that, but each of them relies on either some compiler quirk (e.g. class helpers could access private fields in some Delphi versions, but that loophole has been closed) or directly use the knowledge about the memory layout of the original class. The latter is done either with pointer arithmetic or by declaring a new class with the same fields and hard typecasting an instance to that class, which then allows accessing the private fields. Of course that would mean this class or pointer arithmetic must be adapted to every change that Embarcadero makes to the original, so the memory layout matches.

That almost sounded like an insult but assuming that wasn't the intention; I didn't write the code but I've been tasked with maintaining, fixing and modernizing it. with isn't the only problem but it's the one that makes refactoring the code a much harder task than it should have been - and it makes the code undebuggable. Among the other beauties in this code base are the local procedures; The above was actually found in a local procedure, several levels down. The top level method is a few thousand lines of pure horror.

I'm still hoping that with will be completely eliminated from the language. Here's a few lines from the code I'm currently working on: begin ...3-400 lines of code... with vPlan.DataController, dbSlaktePlan, BLPlan, Grupper ,Data[Id] do begin ...a few hundre lines more... with vPlan, BLPlan.SiteSum, Plans[Id] do begin ...and it goes on...