+semver:minor Added PrivacyDlg to allow control over analytics tracking#1493
+semver:minor Added PrivacyDlg to allow control over analytics tracking#1493
Conversation
…tics tracking is allowed Added elements to TestApp to exercise the new Privacy dialog
Palaso Tests 3 files - 1 3 suites - 1 6m 42s ⏱️ - 3m 29s Results for commit 4067f22. ± Comparison against base commit ce83cef. This pull request skips 1 test.♻️ This comment has been updated with latest results. |
| // | ||
| // _buttonOK | ||
| // | ||
| this._buttonOK.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); |
Check warning
Code scanning / CodeQL
Cast to same type Warning
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 13 days ago
To fix the problem in general, remove explicit casts where the compiler already infers the same type for the expression, as they add clutter without changing semantics. For enum flag combinations (like AnchorStyles), the result of a bitwise OR of enum values is already of that enum type, so an explicit cast to the same enum is redundant.
In this specific case in SIL.Windows.Forms/Privacy/PrivacyDlg.Designer.cs, line 138 assigns to _buttonOK.Anchor using:
this._buttonOK.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right)));Here, (System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right) is already of type System.Windows.Forms.AnchorStyles, so the outer cast ((System.Windows.Forms.AnchorStyles)( ... )) can be removed safely. The best fix is to replace the entire assignment with a direct use of the bitwise OR expression, preserving all other properties and layout code unchanged. No new methods, imports, or definitions are required; we only simplify this one assignment expression.
| @@ -135,7 +135,7 @@ | ||
| // | ||
| // _buttonOK | ||
| // | ||
| this._buttonOK.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); | ||
| this._buttonOK.Anchor = System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right; | ||
| this._buttonOK.AutoSize = true; | ||
| this.locExtender.SetLocalizableToolTip(this._buttonOK, null); | ||
| this.locExtender.SetLocalizationComment(this._buttonOK, null); |
There was a problem hiding this comment.
True, but this is generated Designer code.
| // | ||
| // _buttonCancel | ||
| // | ||
| this._buttonCancel.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); |
Check warning
Code scanning / CodeQL
Cast to same type Warning
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 13 days ago
In general, to fix a "cast to same type" issue, remove the explicit cast when the expression already has the target type and no overload resolution or nullability semantics depend on the cast. This reduces noise and potential confusion without changing behavior.
Here, both _buttonOK.Anchor (line 138) and _buttonCancel.Anchor (line 155) are assigned values wrapped in a redundant cast:
this._buttonCancel.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right)));The expression (System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right) already has type System.Windows.Forms.AnchorStyles. Assigning that directly to the Anchor property is sufficient. The best fix is to remove both outer and inner casts and assign the combined enum values directly, preserving the anchor behavior.
Concretely:
- On line 155, change the right-hand side to
System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right. - Make the same simplification on line 138 for
_buttonOK.Anchorto keep the code consistent.
No new methods, imports, or definitions are needed; we are only simplifying the enum expression.
| @@ -135,7 +135,7 @@ | ||
| // | ||
| // _buttonOK | ||
| // | ||
| this._buttonOK.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); | ||
| this._buttonOK.Anchor = System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right; | ||
| this._buttonOK.AutoSize = true; | ||
| this.locExtender.SetLocalizableToolTip(this._buttonOK, null); | ||
| this.locExtender.SetLocalizationComment(this._buttonOK, null); | ||
| @@ -152,7 +152,7 @@ | ||
| // | ||
| // _buttonCancel | ||
| // | ||
| this._buttonCancel.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); | ||
| this._buttonCancel.Anchor = System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right; | ||
| this._buttonCancel.AutoSize = true; | ||
| this._buttonCancel.DialogResult = System.Windows.Forms.DialogResult.Cancel; | ||
| this.locExtender.SetLocalizableToolTip(this._buttonCancel, null); |
There was a problem hiding this comment.
True, but this is generated Designer code.
tombogle
left a comment
There was a problem hiding this comment.
@tombogle made 2 comments and resolved 2 discussions.
Reviewable status: 0 of 11 files reviewed, all discussions resolved (waiting on andrew-polk, mark-sil, and megahirt).
| // | ||
| // _buttonOK | ||
| // | ||
| this._buttonOK.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); |
There was a problem hiding this comment.
True, but this is generated Designer code.
| // | ||
| // _buttonCancel | ||
| // | ||
| this._buttonCancel.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Bottom | System.Windows.Forms.AnchorStyles.Right))); |
There was a problem hiding this comment.
True, but this is generated Designer code.
Fixed incomplete comment.
tombogle
left a comment
There was a problem hiding this comment.
@tombogle made 1 comment.
Reviewable status: 0 of 12 files reviewed, 3 unresolved discussions (waiting on andrew-polk, mark-sil, and megahirt).
# Conflicts: # CHANGELOG.md
…omponents. Includes a Privacy dialog to enable users to opt out of analytics reporting. Added PathUtilities.ParentDirectories extension method. Added FileLocationUtilities.DistFilesFolderPath extension method. Added installer for SIL.Windows.Forms.TestApp - not intended for deployment, just a testbed for the wxs files in SIL.Installer
b81717a to
a579667
Compare
# Conflicts: # CHANGELOG.md
…rPath set by app. This addresses a concern raised by Devin (which in practice is probably not really a problem).
4cc5955 to
38929ff
Compare
38929ff to
df546f8
Compare
| <Description>SIL.Windows.Forms.TestApp test app</Description> | ||
| <OutputPath>../../output/$(Configuration)</OutputPath> | ||
| <Description>SIL.Windows.Forms test app</Description> | ||
| <OutputPath>output/$(Configuration)</OutputPath> |
There was a problem hiding this comment.
🚩 TestApp output path changed — may affect CI or other build integrations
The OutputPath for SIL.Windows.Forms.TestApp was changed from ../../output/$(Configuration) (the shared repo output directory) to output/$(Configuration) (a project-local directory). This was likely done to support the new WiX installer test project which references .\..\SIL.Windows.Forms.TestApp\output\$(Configuration)\net48\. Any existing scripts or CI steps that depend on finding the TestApp binaries in the shared output/ directory at the repo root would need updating.
Was this helpful? React with 👍 or 👎 to provide feedback.
… reinstall Fixed problem of shared fixed GUID being used across all products
| <Component Id="GlobalAnalyticsSetting" Guid="{5D729D52-F0E1-443F-AA40-664AA754F1C1}"> | ||
| <Condition><![CDATA[SIL_ANALYTICS_APPLY_GLOBALLY = "1"]]></Condition> | ||
| <RegistryKey Root="HKCU" Key="$(var.GlobalAnalyticsRegistryKey)"> | ||
| <RegistryValue | ||
| Name="Enabled" | ||
| Type="integer" | ||
| Value="[SIL_ANALYTICS_ENABLED_GLOBALLY]" | ||
| KeyPath="yes" /> | ||
| </RegistryKey> | ||
| </Component> |
There was a problem hiding this comment.
🚩 WiX GlobalAnalyticsSetting component uses fixed GUID shared across all SIL products
The GlobalAnalyticsSetting component at line 81 uses a hardcoded GUID {5D729D52-F0E1-443F-AA40-664AA754F1C1} so all SIL products share ownership of the global Software\SIL\Analytics registry key. MSI reference counting means the key is only removed when the last product referencing it is uninstalled. However, the component condition SIL_ANALYTICS_APPLY_GLOBALLY = "1" is evaluated per-product on each install/upgrade. If a product was previously installed with this condition true (global applied) and on reinstall the condition becomes false (e.g., user set a product-specific override via the C# dialog), MSI could deregister this product's reference to the shared component. If no other SIL product is installed, this would delete the global registry key. This edge case is mitigated by the fact that the C# AnalyticsProxy.Update method (not the installer) is the primary mechanism for changing settings at runtime.
Was this helpful? React with 👍 or 👎 to provide feedback.
…not set for the current user in the registry
| <Project> | ||
| <Import Project="..\Directory.Build.props" /> | ||
|
|
||
| <PropertyGroup> | ||
| <Product>$(AssemblyName)</Product> | ||
| </PropertyGroup> | ||
| </Project> No newline at end of file |
There was a problem hiding this comment.
🚩 New TestApps/Directory.Build.props changes Product metadata for all test apps
This new file overrides <Product> from libpalaso (root Directory.Build.props:7) to $(AssemblyName) for all projects under TestApps/. This affects Application.ProductName in WinForms apps. Currently only SIL.Windows.Forms.TestApp uses Application.ProductName (at Program.cs:72 for the AnalyticsProxy). Other test apps under TestApps/ (ArchivingTestApp, ClipboardTestApp, etc.) don't reference Application.ProductName, so they're not affected functionally. However, their assembly metadata will change, which could affect things like user settings file paths (Application.UserAppDataPath includes ProductName).
Was this helpful? React with 👍 or 👎 to provide feedback.


Added new
SIL.Installerpackage for common installer components. Includes a Privacy dialog to enable users to opt out of analytics reporting.Added two public members currently just used in Test App but potentially useful elsewhere:
Added elements to TestApp to exercise the new Privacy dialog
Added installer for SIL.Windows.Forms.TestApp - not intended for deployment, just a testbed for the wxs files in SIL.Installer
Added elements to TestApp to exercise the new Privacy dialog
This change is