Tom F

I'd been using Alexandria until this morning. For as long as I remember, Alexandria showed the UAC pop-up "Do you want to allow this app to make changes..." when started. In the past, with Alexandria (being run elevated) I occasionally encountered problems with GetIt packages and others (like Quick Access Popup) that I attributed to somehow my not installing Alexandria properly. For example, drag-and-drop using DropMaster didn't seem to work when I ran my app from inside the IDE. I had hoped that doing a clean install with a new version of RAD Studio would eliminate the UAC elevation requirement. However, having just installed Athens, I still get the same UAC elevation pop-up when starting it. Has Rad Studio always required UAC elevation? Are there ramifications to add-ins because of that? Are their ramifications of running the IDE in the required elevated status like not appearing as a drop target when dragging from an unelevated app? Is there any safe and easy way to avoid any of this other than changing my Windows UAC level on the screen below? Here's my current UAC setting:

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

Sorry, I don't recall if there was a problem or if it was improved. It's been a while since I used it.

As Cristian says, use a profiler! I have been happy using NexusQA profiler for many years. There are other profilers out there, some free. But, my time is worth enough that spending a little money to get a commercial product was well worth it to me. There are profiler discussions elsewhere on the forum here. Avoid AQTime. It's a good company selling an archaic, inferior (and pretty-much unsupported in my experience) Delphi Profiler. Also, evaluate your SQL. Look at the execution plan, consider stored procedures, etc. But, don't do anything until you know where your bottlenecks are in code or SQL.

Another vote for Nexus Quality Suite | NexusDB. And, another downvote for AQTime. It's been terrible for years. I'm glad that SmartBear is finally abandoning it.

@Brandon Staggs and @Lajos Juhász I agree: none of this should have been necessary. I've been using Delphi since Delphi 1 and it's only been in the past year that this problem appeared. I don't know of anything specifically on my machine that might have caused this. I didn't have the AppCompatFlags/Layers registry entry. I'm running a "stock" Win10 machine with main stream security software. I suppose it's likely I did something to cause this problem. But, that it happened on a clean install of D12 surprised me. It's hard to imagine how the problem came to be. But, I'm glad it's behind me. 🙂

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

@Brian Evans That's why I'm trying to fix this.

@JonRobertson Cool suggestion! Thanks. I'd never used mt.exe. Unfortunately, the requestedExecutionLevel is as you suggested, "asInvoker" And, I am an admin:

@JonRobertson: This a totally clean install, with no additional components added. I tried your bds -r"clean" suggestion and still had the UAC elevation pop-up. I also tried your suggestion of monitoring with ProcMon and got results that don't seem to reveal anything of interest.

@David Heffernan Good question! Thanks for your suggestion. There are no compatibility settings set on the desktop icon Properties screen. This is the default icon created by the installer. And bds.exe is the same.

Good questions. Yes, default installation and I’ve added nothing to the IDE.

I'm always logged in as an admin user. The desktop shortcut created by the installer does NOT have "Run this program as admin" checked. (Good thought , though!) Running bds.exe from the File Explorer has the same problem.

I know very little about UAC settings, but I think the only way that could happen is if you had the UAC Settings screen set to "Never Notify." Is that the case?

Thanks, guys, for the feedback. Now I just have to figure why my Win10 machine is requiring a UAC elevation for a standard install from the ISO.

I hate to ask it because I've seen it asked for years and years. And, now I'm asking it ... again. And, believe me, I've looked and look in the EMB docs online and elsewhere and can't find an answer. When would the installer require me to uninstall 12, as shown below? This happens on the ISO as well as the web installer. Is this typical behavior?

I wanted to add that despite many tries over the years, the migration assistant has never worked for me, even the new and "improved" ones provided occassionally. Perhaps if I select to Uninstall on the above screen, The assistant asks if I want to back up settings so I can re-apply them in 12.1?

I'm hoping to use Virtual Box in place of VMWare Workstation Pro for development and testing. I'm hoping its snapshot feature has similar functionality to VMWare's. (And, hey, it's free, AFAIK!) But, to be honest, I don't know much about it yet and I haven't gone much further yet than thinking about it. Here's evidence that VMWare is dying. https://communities.vmware.com/t5/VMware-Workstation-Pro/High-CPU-usage-by-vmnat-exe-after-upgrade-to-VMware-Workstation/td-p/2992063

Why didn't you edit the input, changing the coordinates so that there is no confidentional information?

Every once in a while, I've tried each of Delphi's custom styles in my D11 Windows app. Every time I try them, the result looks a bit "off" to me. Often, it isn't quite good enough to look professional. I'm not a graphics designer; I don't know anything about choosing a color palette. I believe that EMB has improved its custom styles (and its implementation in the VCL) over the years. Perhaps I was soured by the initial versions if they were really bad. But, sit still seems with my app that there are glitches where the coloring isn't quite right. Perhaps one component wasn't ever polished by EMB. Or maybe one of my TPanels on which there's another TPanel doesn't get properly colored, etc. I know some of this might be because of the non-standard, third party visual components that I'm using: Raize, and Mitov, although both vendors produce wonderful tools, so I doubt this is their problem. Perhaps my placement of visual components is broken. Perhaps the Parent property on some visual objects is wrong after 13 years of adding and removing components to forms. I know I can modify custom styles if the problem is cosmetic. I'm trying to avoid that (or at least reduce) the learning curve and piece-work of patching up problems. What's the consensus on custom styles? Do they work? Are you using them? How much trouble did you have? Are there any specific dark styles from EMB or others that you think work best? Did you have to modify them or your forms, or did they work out of the box? Are there some styles that are so ugly or buggy that they're unusable? Are there any "best practices" around styles? What about styles from third parties like DelphiStyles? Have you used them? I have no problem paying for a custom style if it eliminates work. Are custom styles from third parties higher quality aesthetically? More thoroughly implemented? More likely to work without modification? Are there any other 3rd party vendors of custom styles that you've used?

Delphi will continue to stagnate. I think that AI and IDE support for C# and other mainstream languages will soon make Delphi programmers fall far behind the productivity and quality of their peers.

I'm trying to untangle a mess I created years ago in a macOS FMX program (formerly 32-bit and now Universal ARM 64-bit,) I've always used the current version of Delphi (now 12) and this app goes back 5+ years, so some of these files were created in earlier versions of Delphi and on older 32-bit versions of macOS. For years, my app created an IniFile for my program's use only, using TInifile.WriteDateTime. My two mistakes: I didn't specify the encoding of the IniFile, which can vary. WriteDateTime (AFAIK) uses the global FormatSettings, which can vary. So, I'm trying to figure out a way to reliably read the IniFile's TDateTime regardless of the defaults in effect when it was created or when it is being read. I'm planning for my app to try to open the file in TMemIniFile with different encodings (starting with the machine's default) and read the date with TMemIniFile.ReadString. I will then TryStrToDateTime with different FormatSettings (starting with the machine's default) until I get valid dates. This seems a bit brute force, but I don't know what else to do. My app is almost entirely US, with a few Canadian, European, Australian, and Asian users, so I hope to cover the majority of cases with a few formats. I know this may not give me 100% success. I've attached a sample of an .ini file I'm trying to reliably read. Here it is in UltraEdit in hex and characters: I've never spent much time with Unicode, but I think that the BOM FF FE here means it's Unicode. But when I open the attached .ini file, ReadString fails to find the Section and Identifier. I've tried different encodings in the TMemIniFile.Create. (I'm testing this code in FMX Windows 32.) I feel like I'm chasing my tail at this point. Am I missing something? Any suggestions on how to proceed? procedure TForm1.Button1Click(Sender: TObject); var IniFileDateTimeStr: String; IniFile: TMemIniFile; begin IniFile := TMemIniFile.Create('C:\Junk\Test.Ini', TEncoding.Unicode); // I have tried other encodings too IniFileDateTimeStr := IniFile.ReadString('Version', 'SourceFileDate', 'Missing'); ShowMessage(IniFileDateTimeStr); //<--- Always shows 'Missing' end; Test.ini

Thanks for adding that reference, Remy. I wasn't aware of Delphi's System.DateUtils.DateToISO8601 and siblings, which is exactly what I needed!!! https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.DateUtils.DateToISO8601

Thanks, Remy. I'm glad it wasn't something totally obvious I was not doing! 😉 Even the simple code below (which doesn't use an inifile) fails. I'd call that a genuine bug worthy of my reporting to EMB. Thanks again for your help on this and so many other things. procedure TForm1.Button1Click(Sender: TObject); var DateStr: String; DateTime: TDateTime; begin DateStr := DateTimeToStr(Now); if TryStrToDateTime(DateStr, {out} DateTime) then ShowMessage('Ok result: ' + DateTimeToStr(DateTime)) else ShowMessage('TryStrToDate failed'); end;

Thanks, @Remy Lebeau. I always value your input. I can't get the simple code below to write and then successfully read a date on macOS Sonoma 14.2 on a MacMini (ARM). XCode version 15. Using Delphi version 12. It works fine on Windows 10 running as a 32-bit or 64-bit app. But on macOS, the TryStrToDateTime call returns false I don't doubt that I'm doing something wrong, but I can't figure out what. procedure TForm1.btnCreateClick(Sender: TObject); var MemIniFile: TMemIniFile; Filename: String; DateStr: String; begin Filename := IncludeTrailingPathDelimiter(TPath.GetDocumentsPath) + 'Test123.ini'; MemIniFile := TMemIniFile.Create(Filename, TEncoding.Unicode ); try DateStr := DateTimeToStr(Now); MemIniFile.WriteString('Version', 'SourceFileDate', DateStr); MemIniFile.UpdateFile; finally MemIniFile.Free; end; end; procedure TForm1.btnReadClick(Sender: TObject); var Filename: String; MemIniFile: TMemIniFile; IniFileDateTimeStr: String; DateTimeFromIniFile: TDateTime; begin Filename := IncludeTrailingPathDelimiter(TPath.GetDocumentsPath) + 'Test123.ini'; MemIniFile := TMemIniFile.Create(Filename, TEncoding.Unicode ); try IniFileDateTimeStr := MemIniFile.ReadString('Version', 'SourceFileDate', 'Missing'); finally MemInifile.Free; end; if IniFileDateTimeStr = 'Missing' then ShowMessage('IniFile entry was missing') else if TryStrToDateTime(IniFileDateTimeStr, {out} DateTimeFromIniFile) then ShowMessage('Inifile contained date: ' + DateTimeToStr(DateTimeFromIniFile)) else ShowMessage('TryStrToDateTime failed when called with ' + IniFileDateTimeStr); end; I've included the project source in an attached zip file. I've also attached the .ini file from the Mac. Test123.ini Complete project source.zip