xsharp.eu

In >20 years working with VO, VO has given me a handful of "strange" issues only. Visual Studio, on the other hand, has these kind of issues all the time, taking hours to try to solve and sometimes (like now) it's better to give up.

What I wanted to do is create a WPF page to enable the user selecting directories from a treeview. A compact sample to begin with is on https://docs.microsoft.com/en-us/answer ... nding.html. It works, according to the person who asked for the solution.

However, even when I paste the exact same code in a project, I get
Error XDG0008 The name "ViewModel" does not exist in the namespace "clr-namespace:Backup".
XLS0414 The type 'local:ViewModel' was not found
(and a few more).
But it it's certainly there:
.....
xmlns:local="clr-namespace:Backup"
<Window.DataContext>
<local:ViewModel/>
</Window.DataContext>


namespace Backup
{
public partial class SelectFiles : Window
{
public SelectFiles()
{
InitializeComponent();
}

public class ViewModel
{
public ViewModel()
(// etc)
}

The issue is mentioned for VS2010-2019. Like most serious issue, there is no chance that any is solved in the numerous updates that are released.

There are many pages concerning this error. Most, but not all, finally got rid of this error by "solutions" like deleting a .vs directory, changing from Debug to Release, and back; changing from AnyCPU to x86 and back, or doing a voodoo ritual around their Pc.

And that's the tool we are supposed to do our professional work with (yes I know there Xide but I need WPF).

Dick

Hi Dick,
I need WPF too, but I prefer to work with XIDE, using code based windows (they are much more flexible),
Maybe we will be able to build a code based WPF window editor earlier or later....
Wolfgang

Sigh.....

Nothing wrong with Visual Studio Dick, the problem is the example is a heap of crap.

Attached is a corrected project (it's still a heap of crap but it works).



Nick

Hello Nick,

NickFriend wrote:Sigh.....
Nothing wrong with Visual Studio Dick, the problem is the example is a heap of crap.
Attached is a corrected project (it's still a heap of crap but it works).

Thank you for taking the time to attach an indeed working solution.

However, of course I wanted to know what exactly was wrong with the code from that website. I compared the xaml and the .cs with CodeCompare. Apart from the namespace WpfApp48 where you use namespace WpfApp1 and the Window class WpfApp48 where you use MainWindow , the only difference is that your code behind includes:

public MainWindow()
{
InitializeComponent();
}

First I replaced (Select all-Delete-Copy) both the XAML and the code behind from the website's sample into your code (fully replacing it) and selected Rebuild. Same error as I had.

Then I started to re-engineer your code back to the original sample and guess what? After a few changes I changed your example to exactly the same code as in the website's sample - and it works. I have copied-pasted the text to double check with compare but the only differences are white spaces. You can check it from my upload if you like.

So I know you don't share my opinion about how crappy VS is but really this is what happens and which I also saw in dozens of StackOverflow and answers.Microsoft posts. All posts show that there was nothing wrong with the code, but they needed to apply tricks to finally get VS to compile.

And here I see the exact same problem. It didn't make sense that the example didn't compile. It didn't make sense that, pasting the code in your solution it still didn't compile. And it doesn't make sense that finally it did compile, ending up with the exact same code as where I started.

I have not had such situations with VO. Nevertheless thanks to your sample I know that the code itself is working!



Dick

Without InitializeComponent() there's no way it will work.

If you like, post your original solution that did not work (not the one from the example website, your own copy), and I'll try and see what the error was.

Nick

Hello Nick,

NickFriend wrote:Without InitializeComponent() there's no way it will work.

I would be inclined to confirm that too, but it does work. You can try it with the attached solution. It's the same code as the code which failed earlier. But it works, without InitializeComponent.

NickFriend wrote:If you like, post your original solution that did not work (not the one from the example website, your own copy), and I'll try and see what the error was.

Currently I have working version. I'll look for a backup later to see if I can get it wrong again.

But I am convinced that VS was the problem. There was an (even for VS) unusual amount of pages with the XDG0008 and the other errors I got, where most people ended up with a working solution without really changing something in the code.

Dick

I can add another anomaly to this story.
I added a class ...

In my XAML I have (where 'Backup' is the namespace the above converter is located).
Now I have a textblock witin a TreeView which should be colored by the converter:

However, this directly gives The resource 'colorConverter' could not be resolved.

From an existing example I added this within the Grid where the Treeview resides:
and changed the Background line to:
Originally by typing local: Intellisense (WPF) is only showing 3 classes within my namespace. I really have no idea why it stops showing other classes after the first class of 1 of the programs. The other classes look exactly the same. I even made sure that they all look the same (public partial class) but no change.

Now I rename that first class temporary. Bingo! When I type local: now, everything appears. And guess what, I changed back the name, and still the whole list of all 8 available classes appears when typing local:. With the same code as before.

Before that I have cleaned, rebuilt, closed, reopened the solution. Everything.

VS is like a sewer drainage. It can stop working without a reason and with poking around a bit you can be as lucky that you fix an issue without the need to call a plumber.

Apart from the fact that I don't understand at all why I should add <local:ColorConverter x:Key="XcolorConverter" /> and Converter={StaticResource XcolorConverter}}" instead of directly typing Converter={StaticResource colorConverter}}" . Does anybody have an idea?

Dick

Unfortunately Dick you can't deal with a technology as complex as WPF by guesswork.

You're going to have to invest some serious time in studying how it works so that you're not copying and pasting examples in the hope that something works without understanding it. It took me 2 or 3 years to really get to grips with the whole scheme of WPF, XAML, MVVM, etc.

There are no shortcuts.

Nick

Nick, I am not using "shortcuts". And I've been using WPF for years as well. I am sure you have more insight and expertise in WPF than most programmers, and hence than me, but I know by now reasonably how WPF is supposed to work Surely not everything (hence my last question) , and yes, I admit some solutions I got via search-copy-paste. Like most programmers. The problem here is not that the code is wrong or incorrectly implemented but that the very same code compiles or does not, after more or less random actions. That's the main problem I describe here.

VS reacts here totally erratic and I've seen it today again. This time together with my employee. Either my code is wrong and it never compiles or it's right and it always compiles. But make a couple of changes, change it back to exactly what it was and we're back again with the described errors. That's not how a compiler should react.

With a bit of copy & paste, Clean and Rebuild, it then works again. And I am far from alone, search on XDG008 and it's actually hardly ever diagnosed as a real error, but all programmers reacting solved it with the same tricks as I did. In a few cases, first solving another error also got rid of the XDG0008, but there are no other compiler errors in the code.

It's really as unreliable as the repo of oldest Cavo versions. But Robert made VO close to problem free years ago but the VS team is never able to solve anything.

Dick

Hi Dick,
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,
Wolfgang