This is why hate Visual Studio - XDG0008

[ic2]

Hello Wolfgang,

when it comes to WPF, even X# is case sensitive.
You need to the declare the class in exactly the same upper/lower/camel case as you use in XAML,

I know that, but that isn't the issue. In both cases, the working code is exactly the same (apart from a few 'white spaces') as the none working code, but after a considerable time loss trying to rebuild, re-enter and a lot more to finally get it working.

So as I wrote to Nick, in this case it's definitely not code with a fault in it or a lack of knowledge or understanding of that specific code. It's VS which is unreliable and hundreds of other users report similar issues and 'solutions' ranging from switching modes to reinstalling VS.

Dick

[FFF]

Dick,
in your code i saw "ColorConverter" and "colorConverter"...

[ic2]

Hello Karl,

in your code i saw "ColorConverter" and "colorConverter"...

I understand the confusion. But still this is not the problem:

Code: Select all

public partial class ColorConverter : IValueConverter

Code: Select all

<TextBlock Background="{Binding Path=., Converter={StaticResource ColorConverter}}" Text="{Binding Name}"/>							

(same casing) gives The resource can not be found.
So the current coding is:

Code: Select all

<local:ColorConverter x:Key="XcolorConverter" />
...
<TextBlock Background="{Binding Path=., Converter={StaticResource XcolorConverter}}" Text="{Binding Name}"/>							

where the case of local:ColorConverter matches the one in the XcolorConverter .

Then it works, most of the times. Fine with me but still I don't understand why I should create that <local:ColorConverter x:Key="XcolorConverter" /> first. I'd it should work with Converter={StaticResource ColorConverter}} too.

Also during verifying what I reply here, reverting it back to the working code Again shows, even after a Clean/Rebuild "The resource can not be found.". What "solves" it is first renaming XcolorConverter to X2colorConverter on both positions, then Clean/Rebuild, and then change it back to the original XcolorConverter and the error is gone.

So that's the real problem. Somehow I would expect VS to work without these kind of workarounds.

Dick

[NickFriend]

Then it works, most of the times. Fine with me but still I don't understand why I should create that <local:ColorConverter x:Key="XcolorConverter" /> first. I'd it should work with Converter={StaticResource ColorConverter}} too.

Sorry Dick, I have no wish to offend, but this is what I was referring too in my earlier post.

To use a converter in xaml you need to declare it as a resource. It doesn't matter whether it's in the local control resources, the window, or in app.xaml, as long as it's available to the xaml that wants to use it. Once it's declared as a resource, then you can use it, that's how it works.

Simply using Converter={StaticResource ColorConverter} will not work, because ColorConverter is not a StaticResource, it's a C# class.

I don't know the full mechanics of this, but as I understand it when you declare the resource you're effectively instantianting an instance of your class, so that it can be then used in the following xaml. x:Key is simply the name you use to refer to it in your xaml (similar to declaring a variable of a given type and giving it a name).

So you could have
<....Resources>
<local:ColorConverter x:Key="MyLocalNameForMyConverter" />
</....Resources
...
<TextBlock Background="{Binding Path=., Converter={StaticResource MyLocalNameForMyConverter}}" Text="{Binding Name}"/>

HTH

Nick

[ic2]

Hello Nick,

Sorry Dick, I have no wish to offend, but this is what I was referring too in my earlier post.

Don't worry, because first I am not so easily offended and second you are often right with your remarks. Further I appreciate your style of countering my grumpy VS observations.

To use a converter in xaml you need to declare it as a resource. It doesn't matter whether it's in the local control resources, the window, or in app.xaml, as long as it's available to the xaml that wants to use it. Once it's declared as a resource, then you can use it, that's how it works.
Simply using Converter={StaticResource ColorConverter} will not work, because ColorConverter is not a StaticResource, it's a C# class.

Ah, that makes sense!

I thought I was actually declaring the resource because the line

Code: Select all

<TextBlock Background="{Binding Path=., Converter={StaticResource ColorConverter}}" Text="{Binding Name}"/>

is within a <TreeView.Resources> </TreeView.Resources> tag.

As I use XConverter now, this is defined within a <StackPanel.Resources> </StackPanel.Resources> tag as

Code: Select all

<local:ColorConverter x:Key="XcolorConverter" />

and yes, that looks more like a declaration. That explains it, thanks!

Despite my preference to pick a working solution from Stackoverflow or other coding sites I do like to actually understand what the code is doing

Dick

[ic2]

I add one more VS rarity I had today: When I opened the project I got:

Error in ViewModel: Dispatcher processing has been suspended, but messages are still being processed.

Result: VS totally frozen, no more access to code, had to use Task Manager to terminate VS, and on restarting the same problem.
I suspect that the ViewModel accessing R/O directories was the cause (because of the MvvM design the code behind start effectively working when you just open the XAML window). I had temporary solved it by a Try Catch which worked (With 1 deliberate error message during build up) but suddenly, no real reason I was effectively unable to work on my code! Again, I find this not the best way to handle whatever would be wrong in the code.

I solved it by temporary removing

Code: Select all

	<Window.DataContext>
		<local:ViewModel/>
	</Window.DataContext>

from the XAML using Textpad. VS now opened normal, I could paste that same code back and this time VS did not give the error or freeze.

But it's really diminishing my confidence in VS even more.

DIck

[NickFriend]

Don't worry, because first I am not so easily offended and second you are often right with your remarks. Further I appreciate your style of countering my grumpy VS observations./quote]

Someone has to kick back against the rubbish you write about VS!!

Anyway, glad the confusion around resources has been cleared up.

Nick

[NickFriend]

I solved it by temporary removing

Code: Select all

	<Window.DataContext>
		<local:ViewModel/>
	</Window.DataContext>

from the XAML using Textpad. VS now opened normal, I could paste that same code back and this time VS did not give the error or freeze.

The xaml designer crashing is very common (though from what you describe it sounds as though this was more serious). The reason is that when you assign the ViewModel like that, it will get instantiated every time you go to the xaml designer. But of course it's getting instantiated in isolation from the rest of your application, so there are probably many things that the VM is expecting (from the normal app start up and operation), that are simply not available.

So you need to do loads of things like null-checking in the VM, or you could use a trick that I use. I have a very simple static class with just one boolean property "Runtime". I set it true in app.xaml.cs or somewhere like that at the start of the application. So then I know whether the app is actually running or not and can branch execution in the VMs to take it into account. So with your reading of directories you can simply have a bit of logic to skip it when designing
if (MyStaticClass.Runtime)
// read from folders

Nick

[ic2]

Hello Nick,

Someone has to kick back against the rubbish you write about VS!!

I really wish it was rubbish instead of the harsh reality :dry:

Dick

[ic2]

Hello Nick,

[I have a very simple static class with just one boolean property "Runtime". I set it true in app.xaml.cs or somewhere like that at the start of the application.

Sounds like a good workaround. WPF is really powerful bit it's a fact that it is also a bit half baked. A while ago a followed a webinar and the guy who presented it was a MS employee too. He told that MS promoted WPF and when lots of developers kept using Winforms their focus changed, as is often the case with MS. It shouldn't be necessary to have to program tricks like these to prevent a potentially freezing VS.

A VS developer using WPF and MvvM for half a day, as a matter of testing, should have noticed this can happen and should have prevented it from within the editor, I would say.

Dick