HaSo4

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.