Problem

Readonly DoubleEditBox issues

Posted 5 months ago by Avatar Jim Foye

I have some controls defined like this:

<editors:DoubleEditBox HorizontalAlignment="Left"
                       CenterSlotHorizontalAlignment="Right"
                       IsReadOnly="True"
                       IsTabStop="False" />

So, these are read-only, and I don't want the user to be able to tab to them. But setting IsTabStop to false seems to have no effect. Also, if I set the background to something like light gray, when I set the focus in the control, the background reverts to white. Although I don't want the user to tab to the controls, I don't mind if he sets the focus with the mouse (maybe to copy the value), in that case I don't want to lose my "read-only" color.

So I guess that's two questions  :)


Comments (7)

Posted 5 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Jim,

The following information is related to the Editors v2016.1 that you are using, before the Editors product was refactored.

For the IsTabStop issue, the issue there is that the DoublePartGroup (which is nested inside the edit box) has IsTabStop on.  You could add this XAML to turn that off:

<editors:DoubleEditBox.Resources>
	<Style TargetType="editors:DoublePartGroup">
		<Setter Property="IsTabStop" Value="False" />
	</Style>
</editors:DoubleEditBox.Resources>

For the background colors, text controls will use various background states on mouse hover, focus, etc.  You can disable those state changes by setting this attached property on the edit box:

themes:ThemeProperties.UseBackgroundStates="False"


Actipro Software Support
Posted 5 months ago by Jim Foye

Setting the attached property for the color issue works. The namespace declaration (in case anyone else needs this) is:

xmlns:themes="http://schemas.actiprosoftware.com/winfx/xaml/themes"
Posted 5 months ago by Jim Foye

The style is not working for me. When I inspect the visual tree in Snoop, I can see that further down there is a MaskedTextBox with IsTabStop = True. If I uncheck this in Snoop at runtime, then I get the expected behavior. So I added a style for this, but apparently this gets overridden somewhere else. (The other style, targeting DoublePartGroup, works, insofar as IsTabStop for that element is now False).

So now my XAML looks like this:

<editors:DoubleEditBox themes:ThemeProperties.UseBackgroundStates="False"
                       HorizontalAlignment="Left"
                       Background="WhiteSmoke"
                       CenterSlotHorizontalAlignment="Right"
                       IsReadOnly="True"
                       IsTabStop="False">
    <editors:DoubleEditBox.Resources>
        <Style TargetType="editors:DoublePartGroup">
            <Setter Property="IsTabStop" Value="False" />
        </Style>
        <Style TargetType="editors:MaskedTextBox">
            <Setter Property="IsTabStop" Value="False" />
        </Style>
    </editors:DoubleEditBox.Resources>
</editors:DoubleEditBox>

The first style works, the second doesn't, and I can tab to the control (background color now working as expected).

By the way, what would be different about the latest version, after the major control refactoring?

Posted 5 months ago by Jim Foye

BTW in 16.1.636.0 the documentation for UseBackgroundStates Attached Property has:

[Missing <summary> documentation for "P:ActiproSoftware.Windows.Themes.ThemeProperties.UseBackgroundStates"]

Maybe this has been fixed in the latest version?

Posted 5 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Jim,

After the controls were rewritten, the templates were made simpler with fewer nested controls.  However there still is a native WPF TextBox in the edit box's template.  It looks like we have a setup there where the TextBox has the tab stop and the edit box doesn't.  However if the edit box's IsEditable property is set to false, we make set the IsTabStop property true, since no nested TextBox is there to be the tab stop in that case.  So setting IsTabStop on the edit box won't do anything at the moment, but an implicit style like above (but for TextBox) would work for an editable edit box.

As for the documentation, the inability to document attached properties is unfortunately a bug in the third-party Sandcastle documentation builder we use.


Actipro Software Support
Posted 5 months ago by Jim Foye

OK, thanks. I'm not quite clear if you are saying effectively this is fixed now, or would still be a problem in the latest version.

I've decided to just IsEnabled="False", this keeps things much simpler, I just lose the ability for the user to set focus with the mouse and select, but that really was not very important in this case. I also don't have to set the attached property to fix the color. So life is just simpler.

Posted 5 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Jim,

Sorry for the delay in reply.  It would still be a problem in the newer control.  It's a tricky situation because for editable edit boxes, we don't want the edit box itself to get focus on Tab, we want its nested TextBox to get focused.  Thus the edit box isn't a tab stop in that scenario and the nested TextBox is.

We could focus the nested TextBox when the outer edit box gets focus, and that would work when doing a Tab into it.  The problem is that when doing Ctrl+Tab to get focus out of the TextBox, it would focus the edit box, which would then focus back into the TextBox.  It would basically prevent Ctrl+Tab from working with edit boxes.  That's the main reason it's set up like it is.

Using IsEnabled instead, as you did, is an easier way to handle your scenario.


Actipro Software Support
Information The latest build of this product (2018.1 build 0674) was released 5 days ago, which was after the last post in this thread.

Add a Comment

Please log in to a validated account to post comments.