HaSo4

Hello Delphi community, I'm unsure about the setup for Delphi 13 Patch 1 library paths. Usually I do this with the editor in Delphi under Tools/Options/Language/Delphi/Library/ Since I've installed the Spring4D library by its build.exe and moved its DCUs to another folder, I wanted to ease the whole setup process by editing the general EnvOptions.proj File under C:/User/AppData/Roaming/Embarcadero/Bds/37.0/*.* There is has entries like this ... <DelphiLibraryPath>$(BDSLIB)\$(Platform)\release;$(BDSUSERDIR)\Imports;$(BDSUSERDIR)\Imports\$(Platform);$(BDS)\Imports;$(BDSCOMMONDIR)\Dcp;$(BDS)\include;C:\MY_DCUs\Vendor\Spring4D\Rx1301\Win32\Release;$(BDSCatalogRepository)\VirtualTreeView-13\2025.03\source\</DelphiLibraryPath> ... <DelphiDebugDCUPath>$(BDSLIB)\$(Platform)\debug;C:\MY_DCUs\Vendor\Spring4D\Rx1301\Win32\Debug</DelphiDebugDCUPath> which would be an easy find&replace for all platforms: Spring4D\Library\Delphi13\Win32\ Spring4D\Library\Delphi13\Win64\ Spring4D\Library\Delphi13\OSX64\ Spring4D\Library\Delphi13\OSXARM64\ Spring4D\Library\Delphi13\iOSDevice64\ Spring4D\Library\Delphi13\iOSSimARM64\ Spring4D\Library\Delphi13\Android\ Spring4D\Library\Delphi13\Android64\ Spring4D\Library\Delphi13\Linux64\ This is how I replaced all these in the global EnvOptions.proj file and thought the IDE will take these values from the next start. But it seems doesn't, because there were copies stored under HKCU/Software/Embarcadero/Library too, which seems to override these settings fully or partly. Located here: [HKEY_CURRENT_USER\Software\Embarcadero\BDS\37.0\Library\Win32] [HKEY_CURRENT_USER\Software\Embarcadero\BDS\37.0\Library\Win64] and so forth. What is the best strategy for changing these global libraries in a central place, so that they remain permanently in the IDE? One way could be to simply delete the [HKEY_CURRENT_USER\Software\Embarcadero\BDS\37.0\Library\* folder, in the hope that the IDE will restore it, from the EnvOptions.proj file. Is that possibly working, before I crash my whole installation? Who can help to find the best strategy to ease these setups, because visual editing more and more platforms in the IDEs tools editor is somewhat cumbersome.

That is currect, in the case that you mean absolute paths, but for those experiments how it behaves, this shall make no difference. Those absolute paths came originally from Spring4D in the first place, which were listed in the EnvOptions.proj and HKCU_..._Library. Thats why I keep it as is, because I don't know what side-effects they may have in other places. I still try to figure out the whole concept of storing from the IDE in two different places. If manual changes in the IDE seems to land into HKCU_..._Library, why to have a copy in EnvOptions.proj at all? My first idea was the EnvOptions.proj is only a kind of template, for the first IDE start, but my tests seem to say that its not the case. Thanks, thats clearly matches with my tests here. It would mean its vice-versa than I expected, editing the HKCU_..._Library entries would land into EnvOptions.proj, I will check if it behaves like that. Thanks for pointing to this, I was not aware of this tool. Also to bring in the option of symbolic links opens some new ideas. For me its clear now, I have to edit the HKCU_..._Library settings, in case I want them took over in the IDE.

I would not call it "global paths", but I simply want to put the automatically generated DCUs into a well defined place, some levels up. The reason is, that I have a Vendor folder, which includes a few 3rd party libraries sources, which usually generate their local DCU folders into it too. The desired structure is similar like this: VendorSrc/Spring4D/Source/* <-- just for the sources VendorSrc/Spring4D/Library/Delphi13/Debug/* <-- from here VendorSrc/Spring4D/Library/Delphi13/Release/* VendorDcu/Spring4D/Library/Delphi13/Debug/* <-- to there VendorDcu/Spring4D/Library/Delphi13/Release/* The DCU's pollute my VendorSrc folder, which should contain only sources, in an ideal case. I used to have project based libraries in the past, but I wanted to change back to the usual Tools/Options based folders. The problem with project based paths is, that they doesn't always work well for me, especially with pre-defined debug DCU's. The right way should be using Tools/Options based folders, isn't that the case?

Thanks for the proposal, that sounds like a good approach too, I will try that later. Unfortunately the initial settings were added during the Spring4D build.exe setup, perhaps I could try to uncheck the "Update Delphi Registry" option, which maybe proceed no library path settings at all. Nevertheless, this issue points me to the more general question, where are those settings stored and how to be handled. Would be great to know what measures are save to be used. Editing a few paths URL should not be that system critical. One option could be to export the whole Library entry from the RegEdit, then edit it and import this back into the registry. I'm looking for some streamlined IDE configuaration workflows, for multiple platforms, to make the developers life a bit easier.

Good morning, I'm a little unsure, if the Android manifest permissions are used somewhere by the system, aside the examples <uses-permission android:name="android.permission.READ_PHONE_STATE" /> I assume that the whole purpose is to ease the examples, same as it seems in other development systems too. Shall I keep this as-is, if my app doesn't use it? I have found this article and also this, as recommendation to keep the manifest permissions clean. What is unclear to me, if maybe an unused (dangerous) permission may have any consequences for the app or the PlayStore. Are there any known policy links, that clarifies what may happen when those manifest permissions were not cleaned up?

Thanks, that helps to clarify my decisions. I was already moving towards a clean Uses permissions table in the IDE and to add them manually by editing the AndroidManifest.template.xml file. This procedure seems more reliable to me, and it makes no sense to keep any permission left, in the original dialog. My file looks similar to this and gives me much more flexibility, readability, GIT management and the ability to add helpful notes and conditions: <%uses-permission%> <!-- Permission(s) CAMERA: Remove them from Project options permissions --> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> <uses-permission android:name="android.permission.CAMERA" /> <!-- Features(s) CAMERA: --> <uses-feature android:name="android.hardware.camera.any" android:required="false" /> <uses-feature android:name="android.hardware.camera" android:required="false" /> <uses-feature android:name="android.hardware.camera.autofocus" android:required="false" /> <uses-feature android:name="android.hardware.camera.flash" android:required="false" /> <!-- Permission(s) LOCATION: Remove them from Project options permissions --> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <!-- Feature(s) LOCATION: --> <!-- Permission(s) BLE: LOCATION needed: For < Android 12 ( <= API30 ) --> ...

This is what I assume, but are there specific rules for specific permissions? For example, the READ_PHONE_STATE permission is dangerous, but doesn't seem to directly got a strike in Play Store, if it is unused. While other permissions might get directly attention in the review, and they will ask for a proof and explanation how it is used. This leads to the question, if there were different sub-policies for various dangerous permissions levels ( Are some dangerous permissions more dangerous than others )? Maybe this is only, because the review process works a bit randomly and by human resources, even if such permissions can be automatically retrieved.

Good evening, I just realized, that the F1 key doesn't work any more, in D12. I have TestInsight 1.2.0.6, Codex 2.1.0, Project Magician 1.0.42 installed. When I use the menu bar, pressing the help items, I can still see the help as usual. So the help file seems to be installed and running, only the F1-key, when pressed over a variable, does not show up anything. Is this a known bug? I couldn't find any. Or is there any option switch, that might get this working again?

Very strange: Now I used another project, which was build from D12 initially, as a new project. Now it works again: Pressing F1 shows the animator and after some time the help page appears. This animator was missing before, same as the help page itself. Ok, I will see where this goes. Maybe It's related to migrated projects somehow.

Good day, I found the implementation in the Math unit like this: function InRange(const AValue, AMin, AMax: Integer): Boolean; var A, B: Boolean; begin A := (AValue >= AMin); B := (AValue <= AMax); Result := B and A; end; Why is that, shouldn't it be more performant as one-liner? function InRange(const AValue, AMin, AMax: Integer): Boolean; begin Result := (AValue >= AMin) and (AValue <= AMax); end; Maybe there is a catch, I don't see here. The only reason to use two separate boolean, I can imagine, is for improving the debugging experience.

Thanks, a lot of information to read. Yes, usually optimization should fix this, but since I know that Delphi is not perfect in that regard ... I'll keep it as-is, since there seems no "back magic" behind.

Sorry, not for me. Or at least a little "strange". For example: Pressing F1 on "Assert", pops-up the usual selection dialog, but only once, or quite rare: Selecting for example the first line and press OK, never brings up any help. When I open help via menu, this always works: And also includes the desired page: But of course that is not context-sensitive. Can this be any settings issue, or maybe any IDE Expert, causing this behavior?

Good day, I noticed that under D11.3, at Data.Bind.Components.pas, that the GUID is the same. Usually I would consider that as an error, but with the inherited interfaces I'm unsure, if there is probably a deeper purpose or hack behind: IBindCompFactoryContext = interface ['{E0FB570F-2EF0-44C7-BD19-F4F8ACAE2294}'] function GetDesigner: IInterface; function GetControlComponent: TComponent; function GetOwner: TComponent; function GetBindingsList: TCustomBindingsList; property BindingsList: TCustomBindingsList read GetBindingsList; property Owner: TComponent read GetOwner; property ControlComponent: TComponent read GetControlComponent; property Designer: IInterface read GetDesigner; end; IBindCompFactoryExecuteContext = interface(IBindCompFactoryContext) ['{E0FB570F-2EF0-44C7-BD19-F4F8ACAE2294}'] function UniqueName(const ABaseName: string): string; procedure BindCompCreated(AComponent: TComponent); end; Please give me some more insights, if there were any.

I'm pretty sure they will show problems, when both interfaces need's to be accessed via Rtti both. Perhaps it is just a lucky coincidence that both interfaces have not yet been used via Rtti. In any case, this is not an acceptable condition to me, and it's clear that it's not a clever hack. Thanks for your help to clarify this topic anyway.

Thank you, then I'm reassured that my world of interface GUIDs is still intact.