ExceptionValidationRule bug?-VBForums
Results 1 to 3 of 3

Thread: ExceptionValidationRule bug?

  1. #1

    Thread Starter
    Only Slightly Obsessive jemidiah's Avatar
    Join Date
    Apr 2002
    Posts
    2,371

    ExceptionValidationRule bug?

    I'm trying to do some simple TextBox validation and found the ExceptionValidationRule class. My XAML is (basically)

    Code:
    <TextBox>
        <TextBox.Text>
            <Binding Path="MyText" UpdateSourceTrigger="PropertyChanged">
                <Binding.ValidationRules>
                    <ExceptionValidationRule />
                </Binding.ValidationRules>
            </Binding>
        </TextBox.Text>
    </TextBox>
    and the MyText property is (basically)

    Code:
    public string MyText {
        get { return this.myText; }
        set {
            this.myText = value;
            if (!MyTextIsValid(value))
                throw new ApplicationException("Not valid.");
            else
                OnPropertyChanged("MyText"); } }
    When run in debug mode, if I edit the text so that it becomes invalid, instead of just outlining the TextBox in red like I want, a debug window comes up saying the "Not valid." application exception was unhandled. When run outside of debug mode, it works properly.

    I ran someone else's example code, though it wasn't written for VS2010. After running the upgrade wizard and the application, the same error appears. I also found a forum post which seems to describe my issue precisely, though it had no replies.

    Since I've never used data validation before, I wanted to make sure I wasn't doing anything wrong and that this is indeed a bug. So, anybody have confirmation it's a bug or advice on what I'm doing wrong?


    P.S. I'm aware there should be workarounds with the more complex validation techniques. I don't want to use them on principle, particularly since the non-debug version works fine.
    The time you enjoy wasting is not wasted time.
    Bertrand Russell

    <- Remember to rate posts you find helpful.

  2. #2
    Frenzied Member Lightning's Avatar
    Join Date
    Oct 2002
    Location
    Eygelshoven
    Posts
    1,575

    Re: ExceptionValidationRule bug?

    Turn of the "break on errors" option (Debug-->exceptions)
    VB6 & C# (WCF LINQ) mostly


    If you need help with a WPF/WCF question post in the NEW WPF & WCF forum and we will try help the best we can

    My site

    My blog, couding troubles and solutions

    Free online tools

  3. #3

    Thread Starter
    Only Slightly Obsessive jemidiah's Avatar
    Join Date
    Apr 2002
    Posts
    2,371

    Re: ExceptionValidationRule bug?

    Thank you, that does prevent the error from getting raised. To be more specific, unchecking "User-unhandled" after finding "System.ApplicationException" prevents the error from being raised. I imagine I should define a custom exception class, add it to the list of exceptions in Debug->Exceptions, and uncheck user-unhandled for that exception, just to have zero impact.

    For anybody reading this in the future, it seems there are several types of exceptions--(1) those handled by your code, (2) those handled by someone else's code (as in my case), and (3) those handled by nobody's code. With the default settings, most exceptions your code throws that fall into (2) will cause the debugger to break, even when an exception handler somewhere else is waiting to handle the exception. The Debug->Exceptions window controls what to do for cases (2) and (1), I believe.

    There's another setting, Tools->Options->Debugging->General->Enable Just My Code (Managed only), which also prevents the debugger from raising the error. From the documentation, "When this feature is enabled, the debugger displays and steps into user code ("My Code") only, ignoring system code and other code that is optimized or that does not have debugging symbols. For more information, see How to: Step Into Just My Code." It doesn't really say how this setting changes exception handling, but it removes the "User-unhandled" checkboxes from Debug->Exceptions. My guess is that unchecking this option conflates cases (1) and (2) above.


    So, it doesn't seem like a bug per-se, though it really should be mentioned prominently in the ExceptionValidationRule documentation. I assume there's a good reason VS treats user-code- and non-user-code-generated exceptions differently by default, which is the source of this mess in the first place....
    The time you enjoy wasting is not wasted time.
    Bertrand Russell

    <- Remember to rate posts you find helpful.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.