Fix Welcome Backspace Issue & Fix Hotkey Control Settings Null Exception #3310
Conversation
This comment has been minimized.
This comment has been minimized.
|
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
📝 WalkthroughWalkthroughThis pull request restructures the hotkey configuration logic across the application. It removes the previous Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip ⚡🧪 Multi-step agentic review comment chat (experimental)
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
Flow.Launcher/HotkeyControlDialog.xaml.cs (1)
41-41: Constructor refactoring
Removing theIHotkeySettingsparameter simplifies the constructor. Consider using instance-based injection for maintainability and easier testing instead of a static approach.Flow.Launcher/HotkeyControl.xaml.cs (5)
96-112: Introducing HotkeyType enum
Enumerating hotkey types centralizes possible distinctions. If reused widely, consider placing it in a dedicated file for clarity.
114-117: Static retrieval of Settings
Using a static field for DI-managed services can reduce testability. Consider constructor injection or property injection to facilitate unit testing and mock setups.
120-139: Large switch in Hotkey getter
The switch enumerates allHotkeyTypevalues. Consider using a dictionary or mapping approach to improve maintainability and reduce repetition.
141-193: Large switch in Hotkey setter
Repeating logic for eachHotkeyTypecan be cumbersome. A dictionary or map-based approach can simplify the code and minimize potential errors when adding new types.
205-208: Potential redundancy
SetKeysToDisplay(new HotkeyModel(Hotkey));andCurrentHotkey = new HotkeyModel(Hotkey);both instantiate the same model. Use a single instance to avoid duplication.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
Flow.Launcher/CustomQueryHotkeySetting.xaml(0 hunks)Flow.Launcher/HotkeyControl.xaml.cs(4 hunks)Flow.Launcher/HotkeyControlDialog.xaml.cs(3 hunks)Flow.Launcher/MainWindow.xaml.cs(1 hunks)Flow.Launcher/Resources/Pages/WelcomePage1.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage2.xaml(1 hunks)Flow.Launcher/Resources/Pages/WelcomePage2.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage3.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage4.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage5.xaml.cs(2 hunks)Flow.Launcher/SettingPages/ViewModels/SettingsPaneAboutViewModel.cs(1 hunks)Flow.Launcher/SettingPages/Views/SettingsPaneHotkey.xaml(14 hunks)Flow.Launcher/WelcomeWindow.xaml.cs(4 hunks)
💤 Files with no reviewable changes (1)
- Flow.Launcher/CustomQueryHotkeySetting.xaml
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
🔇 Additional comments (39)
Flow.Launcher/WelcomeWindow.xaml.cs (4)
12-12: Simplified constructor
Removing theSettingsparameter clarifies the class responsibility. Make sure all references to the old constructor are updated throughout the codebase.
56-56: Check page parameter removal
Passingnullas the second parameter can cause runtime issues if the navigated page expects non-null arguments. Verify that each destination page inPageTypeSelectoris capable of handlingnull.
65-65: Check page parameter removal
Same concern as line 56—ensurePageTypeSelector(pageNum)does not rely on a non-null argument.
108-108: No concerns
The code consistently initializes the first page upon load, and this looks fine.Flow.Launcher/HotkeyControlDialog.xaml.cs (3)
7-7: Import statement
No concerns regarding addingCommunityToolkit.Mvvm.DependencyInjection.
11-11: Import statement
No concerns regarding addingFlow.Launcher.Infrastructure.UserSettings.
21-21: Verify type compatibility
_hotkeySettingsis declared asIHotkeySettingsbut is assigned fromIoc.Default.GetRequiredService<Settings>(). Double-check thatSettingsimplementsIHotkeySettings; otherwise, this can break at runtime.Flow.Launcher/HotkeyControl.xaml.cs (9)
7-7: Import statement
No issues with addingCommunityToolkit.Mvvm.DependencyInjection.
11-11: Import statement
No issues with addingFlow.Launcher.Infrastructure.UserSettings.
65-65: Keep UI in sync
CallingRefreshHotkeyInterfaceupon property change ensures the UI stays updated.
83-87: Add Type dependency property
Introducing theTypedependency property organizes hotkeys by category, which improves maintainability.
90-94: New property for HotkeyType
ExposingTypein this control is a clean approach for specifying which hotkey is governed.
201-201: Item source binding
AssigningKeysToDisplaytoHotkeyList.ItemsSourceis direct and clear.
202-202: Duplicate code comment
We’ve already covered theRefreshHotkeyInterfacecall above; it ensures the UI remains accurate.
203-203: Unchanged closing brace
No new concerns to address here.
233-233: Simplified dialog instantiation
Removing theIHotkeySettingsparameter makes usage more straightforward.Flow.Launcher/SettingPages/ViewModels/SettingsPaneAboutViewModel.cs (1)
57-57: Good refactoring to use dependency injection.The removal of the
_settingsparameter from theWelcomeWindowconstructor aligns with the broader application changes to use dependency injection rather than passing settings directly.Flow.Launcher/MainWindow.xaml.cs (1)
448-448: Good refactoring to use dependency injection.The removal of the
_settingsparameter from theWelcomeWindowconstructor aligns with the broader application changes to use dependency injection rather than passing settings directly.Flow.Launcher/Resources/Pages/WelcomePage2.xaml (1)
113-119: Good refactoring of hotkey control configuration.The replacement of direct
HotkeyandHotkeySettingsbindings with a simplerType="Hotkey"property reflects the shift to a more standardized approach for hotkey management. This change likely helps address the null exception mentioned in the PR title by simplifying the dependency chain.Flow.Launcher/Resources/Pages/WelcomePage2.xaml.cs (2)
8-8: Good addition for dependency injection support.Adding the
CommunityToolkit.Mvvm.DependencyInjectionnamespace is necessary for accessing the IoC container services.
18-18: Good refactoring to use dependency injection for settings.Changing from parameter-based settings handling to direct IoC resolution is a more robust approach. This eliminates potential null references and simplifies the code by removing conditional checks and exception handling.
This change directly addresses the "Fix Hotkey Control Settings Null Exception" mentioned in the PR title by ensuring that Settings is always available through the dependency injection container.
Flow.Launcher/Resources/Pages/WelcomePage5.xaml.cs (3)
1-1: No functional impact observed on this line.
6-6: Good addition of the dependency injection namespace.
18-18:❓ Verification inconclusive
Ensure the DI container is correctly configured to provide Settings.
If the DI container is not initialized or "Settings" is not registered, a runtime exception will occur.Below is a script to confirm the registration of "Settings" in the DI container:
🏁 Script executed:
#!/bin/bash # This script searches for any lines registering "Settings" in the DI container. rg 'AddSingleton<\s*Settings>|AddTransient<\s*Settings>|AddScoped<\s*Settings>'Length of output: 81
DI Registration Verification Reminder
It appears that the initial search for registrations of
Settingsusing typical DI patterns (likeAddSingleton,AddTransient, orAddScoped) did not return any results. This could mean one of two things:
- The registration for
Settingsmay be using a different pattern than those searched.- The DI container might not be configured to provide
Settings, which risks a runtime exception when callingGetRequiredService<Settings>().Next Steps:
- Manually verify: Please double-check that
Settingsis correctly registered in your DI container setup.- If a different registration method is in use (e.g., a custom registration or a different DI pattern), confirm that it reliably configures the
Settingsservice before use.Flow.Launcher/Resources/Pages/WelcomePage4.xaml.cs (2)
1-2: Addition of dependency injection and user settings namespaces looks correct.
11-11:❓ Verification inconclusive
Confirm that "Settings" is registered in the container to avoid runtime exceptions.
Below is a script to ensure the container is properly registering "Settings":
🏁 Script executed:
#!/bin/bash # Checking for "Settings" registration in the DI configuration. rg 'AddSingleton<\s*Settings>|AddTransient<\s*Settings>|AddScoped<\s*Settings>'Length of output: 81
Action Required: Confirm DI Registration for "Settings"
Please ensure that the dependency injection container is properly configured to register the "Settings" service. Our initial regex search for registration patterns such as
AddSingleton<Settings>,AddTransient<Settings>, orAddScoped<Settings>did not return any results. This might mean one of the following:
- "Settings" is being registered by some unconventional or auto-registration mechanism.
- "Settings" is not registered at all, which could lead to runtime exceptions when calling
Ioc.Default.GetRequiredService<Settings>().Next Steps:
- Verify the DI Configuration: Manually review the DI setup (e.g., in your startup or configuration files) to confirm that "Settings" is registered—either explicitly (using one of the typical registration methods) or implicitly via auto-registration.
- Add Registration if Missing: If you find that no registration exists for "Settings", please add the appropriate registration code to ensure that the service is available when requested.
File under review:
Flow.Launcher/Resources/Pages/WelcomePage4.xaml.cs(Line 11)Flow.Launcher/Resources/Pages/WelcomePage3.xaml.cs (2)
1-2: Namespace updates for DI usage appear consistent.
11-11:❓ Verification inconclusive
Directly retrieving Settings from DI.
If the service is not registered, a runtime exception will be thrown. Ensure correct DI configuration.
🏁 Script executed:
#!/bin/bash # Checking for "Settings" registration in the DI configuration. rg 'AddSingleton<\s*Settings>|AddTransient<\s*Settings>|AddScoped<\s*Settings>'Length of output: 81
Action Required: Verify DI Registration for Settings
The code directly retrieves the
Settingsservice from the DI container using:Settings = Ioc.Default.GetRequiredService<Settings>();This approach will throw a runtime exception if
Settingshas not been registered. Our initial static search using patterns likeAddSingleton<Settings>,AddTransient<Settings>, orAddScoped<Settings>did not return any registration evidence. It is not clear whetherSettingsis registered using an alternative registration pattern (e.g.,Ioc.Default.Register<Settings>) or if the registration is defined elsewhere.Next steps:
- Confirm DI Registration: Please verify manually that
Settingsis registered in your DI configuration. If registration is done via an alternative method or in a separate configuration file, it would be helpful to update the documentation or add a comment in the code to clarify this.- Fallback Safety: Consider adding a safer retrieval mechanism or an explicit check for registration to avoid potential runtime exceptions.
Flow.Launcher/Resources/Pages/WelcomePage1.xaml.cs (2)
1-1: Good update to imports.Removing the unused System import and adding the MVVM DI import shows good code maintenance.
Also applies to: 5-5
12-13: Well-implemented dependency injection pattern.The change from using navigation parameters to dependency injection is a significant improvement. This decouples the component from the navigation system and makes the code more maintainable.
- // Previous code likely checked e.ExtraData or parameters + Settings = Ioc.Default.GetRequiredService<Settings>();Flow.Launcher/SettingPages/Views/SettingsPaneHotkey.xaml (9)
34-39: Good refactoring of hotkey binding mechanism.Changed from explicit settings binding to a type-based approach, which is a cleaner design pattern that reduces coupling and makes the component more reusable.
46-50: Well-implemented hotkey type for preview hotkey.Properly applies the new type-based design pattern. The removal of direct hotkey settings binding reduces duplication and makes the code more maintainable.
104-107: Consistent implementation of Type parameter for context menu hotkey.The change maintains consistency with the new pattern, which will help when processing hotkeys in the code-behind.
125-128: Correctly implemented Settings Window hotkey type.The Type property is properly set to "SettingWindowHotkey" which matches the expected naming pattern.
146-149: History navigation hotkeys properly typed.Both CycleHistoryUpHotkey and CycleHistoryDownHotkey are consistently implemented with the new typing system.
Also applies to: 155-158
171-174: Properly updated page navigation hotkeys.SelectPrevPageHotkey and SelectNextPageHotkey are correctly configured with empty default values, allowing for optional configuration.
Also applies to: 180-183
214-217: Well-structured AutoComplete hotkey implementation with primary and secondary options.The implementation allows for a primary hotkey (AutoCompleteHotkey) and a secondary one (AutoCompleteHotkey2), providing flexible user configuration options.
Also applies to: 223-226
235-238: Consistent implementation of item selection hotkeys with primary and secondary options.The navigation hotkeys (previous/next item) follow the same pattern as the autocomplete hotkeys, providing a primary and secondary configuration option for each action. This consistency is excellent for maintainability.
Also applies to: 244-247, 256-259, 265-268
110-114:❓ Verification inconclusive
Verify if duplicate context menu hotkey definition is intentional.
There appears to be two context menu hotkey entries - one with a HotkeyControl (line 104) and another with just a HotkeyDisplay (line 113). Make sure this duplication is intentional, as it might cause confusion.
🏁 Script executed:
#!/bin/bash # Check if there is a functional difference between these two hotkey definitions # or if they're supposed to serve different purposes # First, let's check if the HotkeyControl and HotkeyDisplay components handle hotkeys differently rg -A 5 -B 5 "class HotkeyControl" --type cs rg -A 5 -B 5 "class HotkeyDisplay" --type cs # Check if there's any code that references these specific hotkey types rg "OpenContextMenuHotkey" --type csLength of output: 3802
Duplicate Context Menu Hotkey Definition – Confirm Intentionality
There are two separate UI components related to the context menu hotkey: one using a
HotkeyControl(around line 104) and another using aHotkeyDisplay(lines 110–114). The current implementation shows that the hotkey is referenced consistently (e.g., viaOpenContextMenuHotkeyin the codebase), and both components appear to serve distinct roles. However, the default key assignments (e.g., "Shift+Enter" for the display versus "Ctrl+O" in parts of the settings) might lead to confusion if not clearly differentiated.
- Action Item: Please confirm that:
- The
HotkeyControlis intended for interactive hotkey configuration.- The
HotkeyDisplayis meant solely for displaying the active context menu hotkey.- The differing default key assignments are deliberate and well-documented.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
Flow.Launcher/HotkeyControl.xaml.cs (5)
65-65: UI refresh on hotkey change is good, but consider null/empty checks.
InvokingRefreshHotkeyInterfaceensures the control stays in sync. For robustness, consider how it behaves ifHotkeyhappens to be empty or null.
83-88: DependencyProperty forTypeis correct, but consider additional documentation.
The default value is set toHotkeyType.Hotkey. It might help future maintainers if a doc comment clarifies how the control behaves when theTypeis not explicitly set.
96-112:HotkeyTypeenum is well-defined but consider doc comments.
Providing inline comments for each enum member would aid clarity, helping new contributors understand each hotkey’s purpose.
120-139: Consider a more scalable approach for thegetlogic.
A large switch statement is acceptable but can be cumbersome if new hotkeys are added often. A mapping dictionary or reflection-based approach could reduce future maintenance.
141-193: Reduce repetition in thesetblock.
Multiple cases set a field on_settings. A dictionary-based approach or reflection lookup might reduce duplication and simplify the logic.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Flow.Launcher/HotkeyControl.xaml.cs(4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
🔇 Additional comments (7)
Flow.Launcher/HotkeyControl.xaml.cs (7)
7-7: New DI import looks consistent with the approach.
No issues here. CommunityToolkit's DI usage is a reasonable choice for resolving Settings.
11-11: Usage of Flow.Launcher.Infrastructure.UserSettings is appropriate.
This import aligns well with the refactored hotkey settings code.
90-94: StraightforwardTypeproperty implementation.
Everything looks fine. The two-way binding allows the UI and code-behind to stay in sync.
114-117: Static DI resolution is fine; verify IoC readiness.
AccessingIoc.Default.GetRequiredService<Settings>()at class load time assumes the IoC container is fully initialized. Ensure this file isn’t accessed before the app’s composition root runs.
201-203: Ensuring UI sync in constructor is a solid practice.
CallingRefreshHotkeyInterface(Hotkey)guards against any mismatches between persisted settings and the display.
205-207:RefreshHotkeyInterfacemethod structure is clear.
It updates both the display list andCurrentHotkey, simplifying UI state management. Nicely done.
233-233: InstantiatingHotkeyControlDialogwith simpler parameters.
Replacing the oldHotkeySettingsparameter helps mitigate null references. This aligns with the PR aim of removing unused or risky dependencies.
This comment has been minimized.
This comment has been minimized.
|
🥷 Code experts: onesounds, Yusyuriv Jack251970, jjw24 have most 👩💻 activity in the files. See details
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame: To learn more about /:\ gitStream - Visit our Docs |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
Flow.Launcher/App.xaml.cs (1)
67-67: Consider whether a singleton lifetime is appropriate for the WelcomeViewModel.
InjectingWelcomeViewModelas a singleton may cause its state to persist across multiple launches of the welcome window. If that is intentional, this is fine. Otherwise, consider a scoped or transient lifetime so that the view model can be re-initialized each time it’s needed.Flow.Launcher/ViewModel/WelcomeViewModel.cs (2)
9-9: Use constant for display formatting.
Instead of hardcoding"/5", referenceMaxPageNumin your string interpolation for consistency if the maximum page count changes in the future.- public string PageDisplay => $"{PageNum}/5"; + public string PageDisplay => $"{PageNum}/{MaxPageNum}";
11-24: Add boundary checks for PageNum changes.
Currently, nothing prevents settingPageNumoutside the range [1..MaxPageNum]. Consider clamping or validating its value to avoid unexpected states.public int PageNum { get => _pageNum; set { - if (_pageNum != value) + var clampedValue = Math.Max(1, Math.Min(value, MaxPageNum)); + if (_pageNum != clampedValue) { - _pageNum = value; + _pageNum = clampedValue; OnPropertyChanged(); UpdateView(); } } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
Flow.Launcher/App.xaml.cs(1 hunks)Flow.Launcher/Resources/Pages/WelcomePage1.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage2.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage3.xaml.cs(1 hunks)Flow.Launcher/Resources/Pages/WelcomePage4.xaml.cs(2 hunks)Flow.Launcher/Resources/Pages/WelcomePage5.xaml.cs(2 hunks)Flow.Launcher/ViewModel/WelcomeViewModel.cs(1 hunks)Flow.Launcher/WelcomeWindow.xaml(7 hunks)Flow.Launcher/WelcomeWindow.xaml.cs(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- Flow.Launcher/Resources/Pages/WelcomePage5.xaml.cs
- Flow.Launcher/Resources/Pages/WelcomePage2.xaml.cs
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
🔇 Additional comments (17)
Flow.Launcher/Resources/Pages/WelcomePage4.xaml.cs (2)
1-3: No issues with the new using directives.
These new references ensure we can retrieve dependencies viaIoc.Defaultand accessSettingseasily.
12-15: Verify forced page number reset.
HardcodingPageNum = 4on navigation might be correct for a dedicated “page 4” scenario, but confirm that re-navigating to this page in other contexts won’t conflict with any existing state or break navigation flows.Flow.Launcher/ViewModel/WelcomeViewModel.cs (2)
1-8: Base structure for WelcomeViewModel looks good.
This partial class architecture withBaseModelinheritance is consistent and should integrate well with MVVM patterns.
48-66: Implementation of UpdateView is coherent.
The logic cleanly updates the navigation state. No further changes required.Flow.Launcher/Resources/Pages/WelcomePage3.xaml.cs (2)
1-5: Good use of dependency injection.The addition of the Mvvm DependencyInjection import and the ViewModel namespace supports the architectural shift from parameter passing to dependency injection, which is a good practice.
12-15: Improved navigation handling for backspace issue.This approach fixes the Welcome Backspace Issue by retrieving Settings via dependency injection rather than relying on navigation parameters. The added comments and page number reset properly handle cases where navigation isn't triggered by button clicks (e.g., browser back/forward).
This solution effectively addresses the issue mentioned in the PR objectives, where using backspace resulted in NavigationEventArgs having no parameters.
Flow.Launcher/WelcomeWindow.xaml (4)
9-9: Good MVVM implementation with proper design-time support.Adding the ViewModel namespace and proper design-time context improves development experience and follows MVVM best practices.
Also applies to: 18-18
21-21: Good addition of Window_Closed event handler.The event handler ensures settings are saved when the window is closed, preventing data loss.
119-120: Simplified binding improves maintainability.Replacing the complex binding with a simpler ViewModel property binding improves code readability and maintainability.
147-147: Enhanced UI state management with button enabling/disabling.Binding the IsEnabled property to ViewModel properties provides better user experience by properly enabling/disabling navigation buttons based on the current page.
Also applies to: 157-157
Flow.Launcher/Resources/Pages/WelcomePage1.xaml.cs (2)
5-6: Good addition of dependency injection imports.The addition of these namespaces supports the architectural change to dependency injection.
14-17: Consistent implementation of dependency injection pattern.This implementation is consistent with the changes in WelcomePage3, ensuring a uniform approach to retrieving Settings and resetting page numbers across all welcome pages.
Flow.Launcher/WelcomeWindow.xaml.cs (5)
7-9: Good addition of required namespaces.The addition of these namespaces supports the dependency injection and ViewModel pattern implementation.
15-15: Good field addition for ViewModel.Adding a dedicated field for the ViewModel improves code organization and follows MVVM principles.
26-31: Simplified constructor with proper dependency injection.Removing the Settings parameter and using dependency injection simplifies the constructor and improves the overall architecture. The DataContext assignment ensures proper binding to the UI.
33-44: Improved navigation with ViewModel state management.The updated ForwardButton_Click method now properly updates the ViewModel's PageNum property and uses it for navigation control, ensuring UI state is consistently maintained.
97-101: Good addition of Window_Closed handler.This method ensures that settings are saved when the window is closed, preventing potential data loss.
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. Using Forbidden patterns 🙅 (1)In order to address this, you could change the content to not match the forbidden patterns (comments before forbidden patterns may help explain why they're forbidden), add patterns for acceptable instances, or adjust the forbidden patterns themselves. These forbidden patterns matched content: s.b. workaround(s)If the flagged items are 🤯 false positivesIf items relate to a ...
|
2 participants
Fix Welcome Backspace Issue
If we use backspace key to switch between many pages, the
NavigationEventArgs ewill contain no parameter so we need to use dependency injection to pass the parameter.Additionally, I use
WelcomeViewModelto make surePageNumis correct when using keys instead of buttons for navigation.Fix Hotkey Control Settings Null Exception
As described in #3280, we should not pass settings to them. Instead we should use dependency injection to pass the parameter.
Here I replace
HotkeySettingsandHotkeydependency properties withTypeto fix this null exception.Test
WelcomeViewModel.