WPF - How to get rid of false design time errors

In design time I have a couple of false errors that seems to be caused by WPF not being able to estimate the value of things without actually running them. This of course works flawlessly in run time. The question is how do I get rid of these errors?

Here is one example:

I have in a class the following two:

public static bool IsHubb {get; set;} 
public static bool IsEC { get { return !IsHubb; } }

The following convertor works perfectly well:

   public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        if (HubbCostOfferPage.IsHubb && HubbCostOfferPage.CarObj.TestApprovedDate == null)
            return Visibility.Visible;
        else
            return Visibility.Collapsed;
    }

The following however (although very similar) gives an "Object reference not set to an in开发者_如何学编程stance of an object." error, which means the only thing I can see on design time without commenting out the StaticResource definition is a big error:

public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
    if (HubbCostOfferPage.IsEC == true && HubbCostOfferPage.CarObj.TestApprovedDate == null)
        return Visibility.Visible;
    else
        return Visibility.Collapsed;
}

If I replace HubbCostOfferPage.IsEC with HubbCostOfferPage.IsHubb, all works fine so I know that there is where the problem is.

If I replace HubbCostOfferPage.IsEC with !HubbCostOfferPage.IsHubb in the convertor, I get the same problem. The designer seems to complain because it can't evaluate "!" during design time.

Any ideas how to make this work in design time as well?

Based on Pauls Answer I would suggest not to check is CarObj is null, because during runtime the exception shall be thrown.

I suggest to change your converter as follows:

public object Convert(object value, Type targetType, object parameter,  
  System.Globalization.CultureInfo culture)  
{  
  if (ApplicationIsInDesignMode) { return Visibility.**WHATEVER YOU LIKE ***; }
  if (HubbCostOfferPage.IsEC == true && HubbCostOfferPage.CarObj.TestApprovedDate == null)
    return Visibility.Visible;
else
    return Visibility.Collapsed;
}

private static bool ApplicationIsInDesignMode
    {
        get { return (bool)(DesignerProperties.IsInDesignModeProperty.GetMetadata(typeof(DependencyObject)).DefaultValue); }
    }

Turn the designer off - it's more trouble than it's worth. Associate .xaml files with the code editor (right-click, open with, then set as default) and you'll get a faster experience and still have Intellisense. You can use Blend as and when you need it.

public object Convert(/*snipped*/)
{
#if DEBUG
    if (System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv")
        return Visibility.Visible;
#endif
    if (HubbCostOfferPage.IsEC == true && HubbCostOfferPage.CarObj.TestApprovedDate == null)
        return Visibility.Visible;
    else
        return Visibility.Collapsed;
}

Edit: At second glance, the designer is likely complaining because HubbCostOfferPage.CarObj is null. You could probably also fix this by changing the code to:

public object Convert(/*snipped*/)
{
    if (HubbCostOfferPage.IsEC && 
        HubbCostOfferPage.CarObj != null &&
        HubbCostOfferPage.CarObj.TestApprovedDate == null)
        return Visibility.Visible;
    else
        return Visibility.Collapsed;
}

Which would have a side effect of being better production code too.

2nd Edit in response to your comment, since this will require code:

As I wrote, replacing the IsEC with the IsHubb solves the problem and putting an ! before IsEC causes it, so it is absolutely not the CarObj that is the problem.

On startup, IsHubb is initialized to false. C# short-circuits boolean logic, so in the following:

if (HubbCostOfferPage.IsHubb && ...

Everything after the logical And is NOT being evaluated. When you changed the code to:

if (HubbCostOfferPage.IsEC == true && ...

Everything after && is now being evaluated. Integral types such as bool are not going to be targets of "Object reference not set to an instance of an object", and obviously HubbCostOfferPage is not null, so the likely culprit is CarObj. Without seeing your code, this was merely a suggested idea.

As to the second part of your question, the DEBUG directives just compile out the code that does the designer check when you compile in release mode. You can remove them if you are doing any design time editing in release mode. The part you need is everything in-between.