1

I am re-asking a similar question that has been asked. The answers didn't seem to work in my particular case. I have included details.

I have a ComboBox and within the ComboBox each item has a ToggleButton. When I click on the ToggleButton there is a red outline that I want to get rid of. How can I remove the red outline around the button? In the ControlTemplate I am setting BorderThickness=”0”, BorderBrush=”Transparent”, Focusable=”false”. These were all things that other posts had mentioned.

<!--Xaml for ComboBox: -->
<TimestampComboBox 
  Style="{DynamicResource PlotComboBoxStyle}"
  IsSynchronizedWithCurrentItem="True"
  …
>
  <TimestampComboBox.ItemsSource >…
  </TimestampComboBox.ItemsSource>
  <TimestampComboBox.ItemTemplate>
    <DataTemplate>
      <StackPanel Orientation="Vertical">
        <DockPanel Width="174" LastChildFill="False">
          <ToggleButton DockPanel.Dock=
            Style="{DynamicResource SampleAddToggleButtonStyle}"
          >
            <ToggleButton.Content>
              <Rectangle Height="10" Width="10"/>
            </ToggleButton.Content>
          </ToggleButton>
        </DockPanel>
      </StackPanel>
    </DataTemplate>
  </TimestampComboBox.ItemTemplate>
</TimestampComboBox>

<!--SampleAddToggleButtonStyle: -->
<Style x:Key="SampleAddToggleButtonStyle" TargetType="{x:Type ToggleButton}">
  <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="{x:Type ToggleButton}">
        <Border Name="border" BorderThickness="0" BorderBrush="Transparent">
          <ContentPresenter Content="{TemplateBinding Content}" />
        </Border>
        <ControlTemplate.Triggers>
           …
        </ControlTemplate.Triggers>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>
  • 1
    Where/When/Why does that Red-Outline show up at all? Do you mean the default failed-validation indicator? How did you got it on a ToggleButton? – quetzalcoatl Apr 18 '14 at 18:25
  • When I click the button embedded in the ComboBox there is a red outline around the button. The unwanted red outline remains even after clicking several times. – user3549724 Apr 18 '14 at 19:21

1 Answers1

2

Sorry, but I think you don't understand what's happening. Let me start over.

What you see is most probably an effect of error checking that WPF performs in certain places. When a 'validation step' fails during binding operations (i.e. you have entered KAJSHDKAS in a textbox that is bound to double variable), WPF sets "validation error" flag on a control. By default it is visualized by simple thin red outline around that field.

It means that something has failed in your code. It's serious. You must check what exactly has happened and reove the error.

Often, it's a result of some exception being thrown from some converter or some binding. Check the Debugger's Output panel and look if there are any "First chance exceptions" reported. or maybe even some stacktraces. If you see ANY of them happening at the time when "red outline" shows up, you must simply fix the problem so that the exception is not raised, and red outline will go away.

If you don't fix it, and if you just hide the error-notification, then at some later point of time you may discover that some bindings ceased to work, or that some styles are not applied, or that some UI elements are not drawn correctly (i.e. they are replaced by big red X error mark).

If there are no exceptions visible in the output log, then look for any messages about failed bindings. When a Binding fails to convert some value to some property or vice-versa, it also may cause error-flag to be set. It often does not end with exception flying around, but a simple message will be written in the log, and it will precisely explain which binding on which control has failed. In this case you will need to trace what was the offending value that was not-convertible to the bound property, and you will need to fix your code to ensure that only convertible values are provided.

quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107
  • I have turned all exceptions on in the debugger and checked the logs. I do not get any exceptions and do not see anything in the logs. – user3549724 Apr 18 '14 at 23:52
  • Thanks for the help. There was an exception that was being thrown in a converter method. Weird thing , in VS 2013 there was no exception logged. In VS 2012 there was an exception. However in both cases the red error outline box was there. – user3549724 Apr 22 '14 at 21:46
  • its old sorry to bother you, but how to hanlde that validation error "flag" by changing the error text ? any possibilities ? i searched almost the entire internet , everyone talking about *IDataErrorInfo* but no one mention how to handle the 'invalid type' exceptions that show up only in WPF in UI but they dont show in C# in code behind even with using `IDataErrorInfo` – The Doctor Jul 03 '22 at 20:15
  • 1
    @RAMM-HDR I have NO idea what you have there, but in general, you cannot `handle that validation error "flag"` by `changing the error text`. The error text has nothing to handling errors. The error text is an EFFECT of the error handler, which tries to tell you that something out there was wrong. Something, somewhere, has failed. And probably threw an exception. That exception bubbled up to the WPF control, and its default error handler reacted, and presented you a red frame, and probably took 'message' from that exception, and probably displayed you that text as mouse-hover message. – quetzalcoatl Jul 04 '22 at 08:21
  • 1
    @RAMM-HDR The IDataErrorInfo is an interface that you could implement a view-model that could be a datasource for your WPF controls, and you could then use IDataErrorInfo's features to write your own validation and kinda your own error handler that could show/hide the red frame, and emit custom mouse-hover messages. That's a cool feature of WPF forms, and a bit tricky to use, especially because tehre's also twin INotifyDataErrorInfo, it can get quite confusing, so that's why you see it all over the place. – quetzalcoatl Jul 04 '22 at 08:26
  • 1
    @RAMM-HDR but if you see some "'invalid type' exceptions that show up only in WPF in UI" and you want to "hanlde that validation error", then you are trying at the wrong side. Usually, you do not patch up the UI to hide that error by customizing the error handlers and red validation frames on the controls. Usually, you want to diagnose WHY the exception is thrown, and (A) either not let it bubble up to the UI layer (find an in-between code and trycatch and silence/patchup it there), or (B) fix the problem why the exception is thrown at all (because in >85% cases, it means some bug somewhere). – quetzalcoatl Jul 04 '22 at 08:30
  • 1
    @RAMM-HDR run the app in Debug mode, click through to get to a point where it will show up the red-frame but wait before last step, go to VS, open "output" tab panel, "clear all" in it to get a clean view, then do the last step, let the red-frame show up, then check out the output tab panel in VS. If indeed any exceptions were thrown, you will see a log line like "First chance exception: InvalidCastException". Note the exception type. Open Debug->Windows->ExecptionSettings in the VS, go to "Common Language Rutime Exceptions", find your exception, select its checkbox, and re-run the case. – quetzalcoatl Jul 04 '22 at 08:34
  • 1
    @RAMM-HDR now when you get to the point when that exception would be thrown and the red-frame would show up, VS will automatically halt the program, at the very place the exception was thrown. It may be in your code (some viewmodel, service, data layer, etc). It may be in framework code (control's constructor, databindings, internal eventhandlers, etc). You will be able to inspect that exception, its stacktrace, the and with some luck the surrounding local state, and you'll have more food for thought to guess the reason for the exception and how to fix or get rid of it. – quetzalcoatl Jul 04 '22 at 08:37
  • 1
    ATM I can't help you more, sorry, and good luck. – quetzalcoatl Jul 04 '22 at 08:37
  • @quetzalcoatl , you took time to wrote all this i appreciate you, i understand what you mean , its kind of the "Exception" that is being thrown in c# but in wpf instead, and its usually related to a type of Decimal for example and user enter "ABCD" instead, i had an idea in my mind to change that Decimal to a string type so i can handle it with Regex and throw my own message, but that would lead me into a massive changing and converting in my entire app specially most of this Decimal,double are used in (Accounting) "prices" / "Quantity" and similar things, what you think would be good here? – The Doctor Jul 04 '22 at 12:20
  • 1
    @RAMM-HDR If I anticipate any business validation, I sometimes go the verbose/elaborate/harder way, have textboxes that allow writing anything, bind as strings, and then parse it in viewmodel and emit error messages - because that will cover any parsing/formatting issues, and also business validation in the same "channel", and at the same time gives full control over number/etc format, and all is DEAD SIMPLE so any novice can grab and continue. As opposed to IDEI or INDEI interfaces which have their protocol and quirks. However. It's tedious and overkill and waste of time for simple things. – quetzalcoatl Jul 04 '22 at 22:39
  • 1
    @RAMM-HDR in that case you said, binding to Decimal/Double and user writes a ABCD, the problem is that it's under-handled. Number parsing fails in the default binding/converter, NumberFormat/etc exception is thrown/etc, and WPF reacts. You either have to provide your own 'Converter' for that binding, that will care or i.e. converting to a safe value upon error (like ABCD -> null, 0.0, etc) (atm idk if it would be better to do that the 'convert' way in Binding, or 'coerce' way in DependencyProperty.. but something around there). – quetzalcoatl Jul 04 '22 at 22:43
  • 1
    @RAMM-HDR or you can dig into the validation framework and override the error presenter (red frame + hover text) and add message filtering there. Or you can lock-in the textbox to accept only valid characters, or even, only valid inputs. Like digits and at most 1 dot/comma and ignore any other dots/commas pressed. Etc. You can do it in a multitude of ways, from simple silencing events https://abundantcode.com/how-to-allow-only-numeric-input-in-a-textbox-in-wpf/ to [behaviors](https://stackoverflow.com/questions/16914224/wpf-textbox-to-enter-decimal-values) to 3rd party controls (lots of them) – quetzalcoatl Jul 04 '22 at 22:49
  • 1
    Try them both. It maybe totally fine for your case. Through, writing a really good 'filter' which limits the keypresses in a TextBox and that "feels good", may turn out not that simple. It depends on your app and your users. If they extensively use keyboard, and filter removes tabs, spaces, enter, arrows, shift-selection, ctrl/c/v, and so on, it may be awful, it's easy to overdo the filtering. I really don't like writing such filters, and I'd try finding a good-enough 3rd party control instead first. There are free libraries and samples. Or I go the string-way,since std TextBox is really good. – quetzalcoatl Jul 04 '22 at 22:56
  • 1
    At exotic things like i.e. screen reading for visually-impaired, or weird fonts or styles, or localization (think: half of your users use dot, other half use comma as decimal separator, or other weird numeric styles), or Right-To-Left languages (that. is. mind. bending. sometimes. especially if you want to make a custom control that handles text), and .... seriously, the choice heavily depends on your app funcs and target audience... – quetzalcoatl Jul 04 '22 at 23:01
  • 1
    In general, I;d say for vast majority of non-skilled users, char-limiting textbox may be the best, even if it's not perfect. They are used to that feature, and used to getting things wrong sometimes. For highly-skilled users like accountants or data-entry teams, I'd consider otherwise. Or make several versions and let them test and hear out which one they like. If you can afford spending that time ofc. It's them who should be happy with the final behavior. Now I think I got too chatty/babbling with no concrete things. Take it with grain of doubt. WPF evolves. I stopped coding in it years ago!! – quetzalcoatl Jul 04 '22 at 23:06