Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ArgumentNullException when removing items from ObservableCollection bound to ItemsControl with CardExpander items #1140

Open
bujma opened this issue Jun 20, 2024 · 10 comments
Labels
bug Something isn't working

Comments

@bujma
Copy link

bujma commented Jun 20, 2024

Describe the bug

System.ArgumentNullException: 'Value cannot be null. Parameter name: defaultDestinationValue' when removing items of ObserableCollection<Model> bound from ViewModel class to ItemsControl in Window with ItemTemplate templated with CardExpander after expanding any CardExpander.

To Reproduce

Situation:

  • MainWindow (pure Windowdescendant, no FluentWindow) with Resources <ui:ThemesDictionary Theme="Light" /> and <ui:ControlsDictionary />.
  • MainWindow with simple ViewModel class as DataContext.
  • ViewModel class with ObservableCollection<Model> Items property bound to ItemsControl having ItemTemplate as CardExpander.

Steps:

  1. In runtime, fill the Items with some Model items (button [Reload Items] calling Items = new ObservableCollection<Model>(list)).
  2. Expand any CardExpander.
  3. Remove any item/all items/assign new instance of ObservableCollection to Items property (buttons [Delete], [Remove All Items] or [Reload Items] calling Items.Remove(item), Items.Clear() or code from step 1).
    => exception will be thrown

Description:

  • If you use default WPF style (no WPF-UI resources in MainWindow.xaml), everything will work.
  • If you use WPF-UI resources in MainWindow.xaml, exception is thrown.
  • If you do not expand a card (skip step 2), all will work with or without WPF-UI resources.

ErrorProof.zip

Expected behavior

No exception thrown. Removing items from ObservableCollection or assigning new instance should have no such impact.

Screenshots

No response

OS version

Windows 10 Pro 22H2 19045.4529

.NET version

4.7.2

WPF-UI NuGet version

3.0.4

Additional context

No response

@bujma bujma added the bug Something isn't working label Jun 20, 2024
@textGamex
Copy link
Contributor

Thank you for providing the complete sample code; I think this will be helpful in fixing this bug.

@textGamex
Copy link
Contributor

I observed that you were utilizing the ResourceDictionary within the MainWindow; however, when I configure the ResourceDictionary in the App.xaml, this exception does not occur.

@bujma
Copy link
Author

bujma commented Jun 21, 2024

Is it unsupported in WPF to put style resources into Window? Or is putting the resources into App.xaml the only way to have it working?

The situation is: all our WPF windows/user controls are in libraries. The libraries are used from win32 (non .NET) code => there is no Application object created. I know, I can create own one in the library and merge the WPF-UI resources into it - I already do it with our current WPF styles that we want to replace with WPF-UI. But if I do it this way, all windows are affected by these styles at once and we want to restyle them one by one and to not wait with the release until all of them are restyled - it's OK for us to have some with our old style and some with WPF-UI's (our one is close to WPF-UI, so not a big "disharmony").
I already have bad experience with this "general styles" approach: when an application loads our library with its styles automatically merged into Application's resources, all styles of the application itself and of other libraries are affected. Therefore I decided to put WPF-UI resources directly to windows/user controls that are being restyled.

Is there any better solution I am not aware of?

Thanks much for your help.

@textGamex
Copy link
Contributor

Is it unsupported in WPF to put style resources into Window? Or is putting the resources into App.xaml the only way to have it working?

The situation is: all our WPF windows/user controls are in libraries. The libraries are used from win32 (non .NET) code => there is no Application object created. I know, I can create own one in the library and merge the WPF-UI resources into it - I already do it with our current WPF styles that we want to replace with WPF-UI. But if I do it this way, all windows are affected by these styles at once and we want to restyle them one by one and to not wait with the release until all of them are restyled - it's OK for us to have some with our old style and some with WPF-UI's (our one is close to WPF-UI, so not a big "disharmony"). I already have bad experience with this "general styles" approach: when an application loads our library with its styles automatically merged into Application's resources, all styles of the application itself and of other libraries are affected. Therefore I decided to put WPF-UI resources directly to windows/user controls that are being restyled.

Is there any better solution I am not aware of?

Thanks much for your help.

Sorry, I'm not quite knowledgeable about this aspect either.

@bujma
Copy link
Author

bujma commented Jun 26, 2024

Thanks for your response. I was trying the same with some other styles placed directly in Window's resources - as is perfectly common in WPF - and everything worked. How can this unexpected behaviour of WPF-UI resources be fixed?
Thanks for the time of you all.

@bujma
Copy link
Author

bujma commented Sep 9, 2024

Hello. Any news about this issue? Thanks much.

@Nice3point
Copy link
Contributor

The problem occurs due to animating the Tag property, which has a default value of null in DependencyProperty. The problem is solved by using another property that has a default value, e.g. MinHeight works without problems, keeping the same animation without exception.

@bujma
Copy link
Author

bujma commented Nov 7, 2024

Thanks for the response. Is the solution part of some planned future version?

@Nice3point
Copy link
Contributor

@bujma I can make a PR if @pomianowski agrees to that approach with MinHeight

@bujma
Copy link
Author

bujma commented Nov 7, 2024

I cannot say if it is the correct solution, but it will be fine to have it fixed in the near future, thanks much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants