This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
If you load two windows each with a DataGrid, and each in their own dispatcher/thread, the grid throws the following exception. This is problem for me, because my application has one thread per window. |
|
|
|
|
Hello Nestor We have not been able to reproduce this at our end. It may be a particular data grid feature you are using that is causing this exception. Could you please send us a repro project for this? Possibly just an extension of the other repro project you made. Jason Fauchelle. |
|
|
|
|
Find attached project replicating the issue. Instructions: 1) Set 2) Now set Final note:
If you comment out the DataGrid in the XAML of one of the windows and run the project with |
|
|
|
|
Hello Nestor Thanks for the repro project, this made it simple to track down and resolve this issue. The fix will be available in the next nightly build. Jason Fauchelle |
|
|
|
|
This has been solved indeed. Thanks. Nestor |
|
|
|
|
Actually, I spoke a little too soon. I'm getting this exception (strangely enough, only when I run the program as an exe as opposed to in debugging mode from Visual Studio) |
|
|
|
|
Hello Nestor This will be a bit tricky to debug without being able to use Visual Studio debug mode. I was unable to reproduce this using the exe produced by your previous repro project. I did notice the stack trace mentions Syncfusion, so this may be a place to start looking into it. If this doesn't seem to be a problem, I'll be able to help you if you send another repro project. Ultimately it looks like an issue with dependency objects. Dependency objects can only be used within the dispatcher that created it. This may be a dependency object at your end because Mindscape isn't mentioned. One way to solve this kind of issue is to change the object implementation to be a normal object rather than a dependency object if possible. If this can't be done, make sure you're not sharing dependency objects across dispatchers. Jason Fauchelle |
|
|
|
|
It's true that Mindscape is not in the call stack. But if I comment out the DataGrid from the XAML I don't get this exception. It's weird.... I'll keep digging and will let you know what I find. Thanks for your help. Nestor |
|
|
|
|
This is very strange.... I was missleading you about this problem happening outside VS. The problem actually does not happen in one machine... but it happens in another machine. Note that the calling stack is the same as the first stack I submitted... where Mindscape is not shown in the stack... Nevertheless you were able to fix something to fix the dummy project. What did you change? |
|
|
|
|
Hello Nestor On the DataGrid, there is a property called BuiltInDisplayTemplates and BuiltInEditorStyles. These properties are collections of what you could consider to be simple tuple objects. These tuple objects have a reference to a resource key, and a reference to either a template or a style. These collections are essentially a lookup table for default cell templates and styles. These properties get set within each of our 6 themes, and because of this, all instances of the DataGrid that use the same theme will get the same instance of this collection. Now here is the problem, those tuple objects were implemented as DependencyObjects which was causing problems across multiple dispatchers. As I mentioned, dependency objects can only be used properly in the dispatcher that created them. But all grids share the same instance of the lookup tuples which causes the issue in your scenario. The solution was simple. Since the tuples don't actually need to be dependency objects (they don't need to support binding), I simply changed these to be normal C# objects with basic properties. Good spotting with the identical threads. In that case it probably is still an issue in our DataGrid - maybe some other dependency object issue. Strange that it works on one machine but not another. Make sure both machines are using the latest update of the WpfElements dll with the fix for this issue. I hope you are able to find more information or create a repro project to aid in debugging. Jason Fauchelle |
|
|
|
|
These issues are difficult to pin down. Some things I can point out:
I hope this helps. I'm happy to keep brainstorming with you if that helps. |
|
|
|
|
I meant "Alloy" theme... not "Allow" |
|
|
|
|
Im sure you know all this, but you need to make sure that the resource is deleted in the same thread that created it. This might be your problem... since the call stack shows an attempt to dispose. See if this helps. |
|
|
|
|
|
|
|
|
|
and this |
|
|
|
|
Update: I installed VS 2012 in my test machine, and now my project runs without crashing... I don't get it. Let me know if you find/think of anything. I'd like to pin down this issue. Thanks for all your help. Nestor |
|
|
|
|
Hello Nestor I've looked into this for a while, but haven't found anything that could be causing this issue. We don't have anywhere in the DataGrid code where objects are being disposed. The links you pointed out most likely have the solution to the problem, but without being able to reproduce this issue at our end, we will not be able to resolve this. I do not have VS2012 installed on my machine, and I've tried your previous repro demo with and without the Alloy style, and everything still works fine. Are you still seeing this issue on any of your machines? Jason Fauchelle |
|
|
|
|
I appreciate your efforts very much. I havent seen this problem happen again.... and I'm not sure what solved it :-) But will certainly let you know if I see it again. Thanks, Nestor |
|
|
|
|
I'm able to replicate the error in one of my machines. If I move from my App.xaml to each of my two windows (each running in a separate dispatcher) then the error seems to go away. Sorry I don't have a replicating project for you yet, but I thought I'd give you an update. |
|
|
|
|
Thanks for the update Nestor Does your previous repro project cause the error on that machine? What VS and .NET versions do you have installed on that machine? Does it cause the error in debug or release mode, or only when running the exe? Jason Fauchelle |
|
|
|
