And there is a property IsSelected in the class that selecting an item changes correctly.
I also have a "Select All" button and an "Unselect All" button which seem to work. After pressing the button and counting the selected objects I get the expected counts.
Now my listbox has more items than fit in the view area, so the scroll bars appear.
The problem comes when I press the select all button and then scroll the list box. Even though my count said they were all selected, after I scroll, the items that were not in the window at the time the button was pressed revert to their prior state. The IsSelected property is re-called by the scrolling.
I don't know if I can make it any clearer. How do I keep the scroll bar from resetting the IsSelected property? Or How can I get the listbox to keep the items outside the visual area selected or unselected?
I have been fighting with the OpenFileDialog to try to read the bytes of any type of file into a stream or byte to store in a database table but can't seem to get it right. Is using the OpenFileDialog class the correct way to go?
With the OpenFileDialog, the only property you're going to want to really use is the Filename. Once you have this, you would fall back to standard File operations to read the bytes (ReadAllBytes would be the one I would choose).
My problem is very difficult to describe but this is what I am trying to do. See all code below. What I have is a parent WPF Window that has a child View, created as a UserControl, added to the parent Window in it's markup. Now the problem is this. When a row, on the child UserControl View's GridView is clicked I want to close the child view's parent (Window) then navigate to an entirely new Window and open it. When I click the row I get the error 'Invalid cast exception". See below:
I'm new to WPF/MVVM and have been trying to come up with a solution for communicating between ViewModels. The best i've been able to come up with is below, it works, but it feels dirty and shameful. Any suggestions would be greatly appreciated.
I am struggling with the decision how to design my application. Let me describe my problem:
The application has a navigation on the left and the region to display the according view to the right.
It shall load projects and those projects can be of type A, B or C. The navigation is the same for all types, but some of the views differ.
My plan was for all type depending items in the navigation to have a general view which offers a region and the modules A, B and C which all provide a view for that region. During the loading of the project depending on its type the module / library A, B or C is loaded while the other library is unloaded. But I found out it is not supported to unload modules (only complete AppDomains).
I am developing in C# using VS 2010 and Prism 4.0.
Anyone has an idea how to best solve this issue? Is creating and unloading a temporary AppDomain really the best solution?
Glad that's working for you; sometimes the simplest solution is the best one.
If a better solution comes to mind later (as it often does), you have the option to go back and re-factor if it makes a difference. That's typical of software; when that gnawing feeling stops, you know you are "optimal".
I have a logon DLL that has a form which needs to be displayed in the main applications main windows navigation Frame. There is no mucking about with app domains but it is a PITA to put it together. App.xaml - get the arguments passed into the start up exe and pass them to the main window VM.
MainVM has a reference to the main view (I know breaks the MVVM model) and the logon DLL. It gets the URL for the logon view from the DLL code>@"pack://application:,,,/LogonDLLName;component/Views/Logon.xaml and puts it into the frame in the main window.
It subscribes to the LoadCompleted method of the view to get the datacontext of the Logon view. And the PropertyChanged event in the Logon DLL VM.
PropertyChanged gets the content from the logon event and proceeds with the application.
As I said this is a PITA but it does work and we can relatively easily use the same logon DLL for all the applications. I hesitate to put this out there as I'm bloody certain there is a better way to do it.
Never underestimate the power of human stupidity
What occurs to me is that you can solve this using a combination of this article[^] with some clever work with the AppResources to register your views with "on-demand", replacing view references as necessary.