Leaderboard

New video - 3D in WebUI

I would be concerned... This sounds like you have something else causing trouble. It could be an indication of some corruption in your installation, or some other software that is causing the trouble. If things are working then no need to mess with it, but I would recommend using this as motivation to make sure you have a good backups of your data, so you will be ready if you need to create a fresh Windows install sometime soon.

Hello Everyone! I am an experienced Delphi Developer, currently available and exploring opportunities for full-time remote employment with a long-term commitment (via Upwork platform). If you have any openings, please feel free to contact me. https://www.linkedin.com/in/alexander-shyshko-1709992b1/ Primarily looking for full-time opportunities, but open to considering all options. I am flexible with time zones and can adjust my schedule to meet your needs. Thank you for your time.

Another more elaborate example that will show why is compiler strictness for var parameter necessary, and why without it we could easily and unintentionally write the code that can corrupt memory otherwise Pass the Dog, Get the Cat

Perhaps this will help: Magic behind FreeAndNil

It is pretty simple - imagine if the code below would work that way: procedure ReplacePet(var pet: TPet); begin pet.Free; pet := TCat.Create; end; procedure Main; var dog: TDog; begin ReplacePet(dog); dog.Bark; // meow?! end; FreeAndNil is special because it just destroys and assigns nil. But a var parameter does not give that guarantee.

A word of advice - in C++, NEVER use the Form's OnCreate and OnDestroy events! (they are perfectly safe to use in Delphi only). The events are based on Delphi's object creation model (derived classes created before base classes), which is different than C++'s creation model (base classes created before derived classes). Also, their behavior has changed a few times over the years (due to internal changes [and bugs] related to handling of the TForm.OldCreateOrder property), so they are not always consistent in C++. As such, the events can be called before the Form's C++ constructor and after its destructor, respectively (I've seen it happen), which leads to undefined behavior in C++. In C++, ALWAYS use the Form's actual constructor/destructor instead.

I'll never understand people like you. Every project except CScript has a Requirements section where he mentions that Delphi 12.2+ is supported, or at least that it is made and tested with Delphi 12.2. You really should RTFM more often.

Here an example: program Crcr32Demo; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.ZLib; var Buf1 : AnsiString; Buf2 : String; Crc : UInt32; begin Buf1 := 'Hello World!'; Crc := System.ZLib.Crc32(0, PByte(Buf1), Length(Buf1) * Sizeof(Buf1[1])); WriteLn('AnsiString ID=', IntToHex(Crc, 8)); Buf2 := 'Hello World!'; Crc := System.ZLib.Crc32(0, PByte(Buf2), Length(Buf2) * Sizeof(Buf2[1])); WriteLn('UnicodeString ID=', IntToHex(Crc, 8)); ReadLn; end. The output is: AnsiString ID=1C291CA3 UnicodeString ID=E2106423 AnsiString and Unicode string doesn't produce the same result because character code are different (8 bit and 16 bit per character). and CRC32 work at the byte level.

The TRecordA/TRecordB relation leads to a structure of infinite size. I would question the design choice, but having no knowledge of the underlying API that is not more than just a gut feeling. IMHO, you should use the approach that fits best. There is no general rule for all cases.

I disagree the use of pointers directly for a waste use. In the past I had some side effects not "beauty" ... especially if they were targeting structures with "managed types". In the state of Darian exposition, I will prefer the mix solution. CodGen projects are always "beasts", I wish you good luck in your job @Darian Miller

@Gex99 It's always nice to know that someone benefited from the work I put it in to solve a problem. It was a tricky problem that, as you saw from my posts, took a while to solve. The solution I eventually found was easy to implement. I'm glad it worked for you too. Thanks for saying something.

Thanx TOM F, your fix to run as invoker worked for me beautifully.

FIX FOUND! My bds.exe is no longer insisting it is run with Administrator privileges. This area of Windows is new to me, so perhaps my analysis and solution below are incorrect. Please be gentle on me if I'm wrong about all this! I know of four ways that Windows determines whether an exe requires UAC Admin elevation (Run as Admin). 1. The flag/checkbox on a desktop icon's Property screen's Security tab 2. The standard registry. 3. An Application Compatibility database (?) described by wosHub (or is this just the registry as edited by Microsoft's Application Compatibility Administrator?) 4. The .exe's manifest I found an easy way to view and edit the registry keys using Nirsoft's AppCompatibilityView (https://www.nirsoft.net/utils/app_compatibility_view.html) (Of course, RegEdit would work too, but you'd have to know all the fields and flags to do it manually like that) Nirsoft's AppCompatibilityView showed that the registry contained an entry that was forcing Windows to launch bds.exe with administrative rights. (See attached screen capture of the Nirsoft app) After I deleted that entry, the bds.exe Ran as Invoker and did not require UAC elevation. I believe that the D12 installer must have added an entry to the registry that forced UAC elevation for administrative rights. I don't know why the installer would do that. Nor do I know how else that entry could have occurred. After I deleted the registry entry using Nirsoft's app, I uninstalled (thoroughly with Revo) and re-installed D12. Now, when I launched the bds.exe, it started without the UAC popup. But... I then got: Exception Exception in module coreide290.bpl at 0000F3B3. Internal Error: AppIniFile was not initialized. If I ran as Admin, I did not get that error. Other than one unresolved RSP in the old JIRA database, I could find nothing about this error. I couldn't find a file on my machine with the name "AppIniFile." And, Procmon didn't give me any further information about what was going on either. I was able to follow the instructions at https://woshub.com/how-to-disable-uac-for-specific-applications/ to create a batch file that when run, causes the bds.exe to run with RunAsInvoker. I wasn't happy with a batch file sitting between my keyboard and launching bde.exe. (For example, what would happen if I double-clicked on a .dproj in the Windows Explorer? The .bat file wouldn't be run so bds.exe would again require UAC elevation.) As an alternate approach, I followed the instructions on the above woshub page to create a registry key that would flag bds.exe to be always RunAsInvoker. Here's the key: [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\\Program Files (x86)\\Embarcadero\\Studio\\23.0\\bin\\bds.exe"="RunAsInvoker" You could do the same thing more easily with Nirsoft's app using its Action menu or right-clicking on app there. I did not take the time to try the Application Compatibility Toolkit method (as described at woshub) to modify the Windows compatibility database. Like I said, this is all new to me... and apparently it's new to most people. I don't if my thinking is correct, but bds.exe is launching properly... at least for the time being. If this write-up helped you solve a problem you've been having, DM me to let me know it was worth the time I spent writing it out here! Tom