In Windows Forms controls, there are two properties: ReadOnly and Enabled.
What is the difference between these two properties? I feel like they behave the same way.
As it says in the following forum post:
In the context of a TextBox, readonly
allows the user to set focus to and
select and copy the text but not
modify it. A disabled TextBox does not
allow any interaction whatsoever.
Use ReadOnly when you have data that
you want the user to see and copy, but
not modify. Use a disabled textbox,
when the data you are displaying is
not applicable in for the current
state of a dialog or window.
Taken from: MSDN Forums
ReadOnly I generally associate with a TextBox or other control that contains text; it dictates whether or not the user can modify the text displayed by the control. The user can still select the text, though (e.g., to copy and paste it into another program).
Enabled basically controls whether or not any user interaction with the control is possible. For instance a Button with Enabled == false cannot be clicked; a CheckBox with Enabled == false cannot be toggled, etc. Note that a TextBox with Enabled == false also cannot have its text selected (that would be user interaction).
Furthermore, controls with Enabled == false do not raise events related to user interaction such as Click.
Enabled specifies whether user interaction is allowed. If a control is disabled then it will not generate any UI events.
ReadOnly determines whether the user can edit the contents of the control. For example, a ReadOnly TextBox cannot be edited, but you can still click on it, select the text contained within it, etc.
If you take a text box with a scrollbar as an example, ReadOnly does not allow the user to edit text, but the scrollbar is still active (think about licence boxes in installation programs). Enabled = false will cause the entire control to disable, not just the text editing area.
Some controls, e.g., buttons, can only be enabled or disabled. A disabled control will give a visual indication that it cannot be interacted with right now (typically by graying/fading out). Others can also be read-only, in that they can be interacted with in some way but not edited. For example, an up-down control is often like that, which means you can press the buttons to change the value but not edit it by normal typing. (It's also possible to have controls that you can never interact with but which are still usefully disable-able; a label can still be grayed out as part of indicating that a whole area of the GUI is not usable right now, which is a more pleasing visual effect than just changing the controls that are interactive.)
It's virtually always the case that being disabled implies that a control is also read-only. I've seen a few cases where that wasn't true, and it always felt more like a bug than anything else to me. It's best to regard the states as representing a tri-state value where one of the states is not used for some controls.
In addition, I read here that if a textbox is marked Enabled="false", its value isn't preserved in the Viewstate across postbacks.
Don't forget, a screen reader for the visually impaired cannot read the text in a disabled text box, since it cannot receive focus. For ADA compliance, use ReadOnly.
Related
I have a Windows 10 mobile uwp app and I am having two issues.
First, I set focus to controls in the app. I do this by using the common call successfully
Control.Focus(FocusState.Programmatic);
However, there are some cases where this does not work. Most times it does but for example, when my page loads, I am trying to set an initial focus in one of the fields and it does not work. I have tried this call in two places. First, in the constructor for the page, after InitializeComponenets and also in the override onNavigatedTo method. Where is the best place to call this and what are some reasons why it may not appear to work, particularly when a new page is instantiated?
Second, related to setting focus. I have a text box on my UI that I set control to with the same Programmatic focus call I listed above. However, the soft (on screen)keyboard shows when this happens. I dont want it to show up when I set focus Programmatically but then have it show if the user selects the field. The scenario is I have a barcode scanner. When the page loads, I set focus in code to the text box and it is therefore ready for me to set the text in the text box from code, based on the barcode scanner result. There is hardly ever a need for the user to type into this field. Therefore, I dont need or want to have the keyboard showing and taking up real estate. There is a rare case when I do allow them to still type the text in manually, for example, in the case the barcode does not read. They would then select the control (even though it may already have focus programmatically) which should set focus again but instead as cursor, touch or something and then I want to show the soft keyboard.
What is the best way to do this?
Thanks!
as far as focusing anything else than the TextBox did not work for me anyway, I found a good solution:
I called:
using Windows.UI.ViewManagement;
InputPane.GetForCurrentView().TryHide();
and the Keyboard gets hidden.
I think the best place to call Focus() is in Loaded event handler of the same control which you trying to focus. When this control is fully loaded, it means it's ready for interaction, including focusing.
As for preventing on-screen keyboard to appear, the TextBox class has PreventKeyboardDisplayOnProgrammaticFocus property. Try to set it to true, this should solve your issue.
I'm using the 2013 Q3 Telerik Tab control in a C# WinForms project. If I test the .Visible property of a control placed on a Page in the Tab then it will always return false unless I Select the page. Is there another property besides .Visible that can be used to test the Visibility of a control on a Page without having to select it?
Here's my dilatation:
You should not change the native meaning of the control's properties. Period. I asked in a comment what were you trying to achieve, because I suspected that you're basing some UI logic on some control's visibility, which in my opinion isn't too good approach. The visibility should be bound to the background logic, not the oposite. You're hiding controls for some reason, because at some point something happened - so keep track of that "something" instead of inspecting its results. IMO the Visibility property should be set, but never checked.
Alternatively if it's not possible to change the concept for some reason, as a workaround I'd attach a handler to the VisibleChanged event and set Enabled property if the sender is not a tab control - then by checking against Enabled property you'd know whether the control is in use or not. I find it difficult to imagine a situation in which I'd need to check whether a control is visible.
I think the title for this question is probably wrong, but I'm not sure quite how to phrase it. I have a C# 4.0 (VS2010) WPF application.
This application consists of a single window with a header including the basics (logos, captions, etc) and a set of navigation buttons (back, retry, next, etc). The rest of the window is comprised of a listbox that is populated with one or more usercontrols based on what mode the app is currently in.
The way the code is currently written when the mode changes the listbox is cleared, all new user controls are added, and the buttons are set to their required state. This is fine for the initial state of each window mode but I'm having trouble deciding a good approach to update the navigation buttons as the contents of the controls change.
For example one screen is a configuration screen and there are three user controls contained within the listbox. These controls are custom classes that inherit from UserControl. Additionally they implement an interface that defines a method 'bool Validate' which determines if the control has been completely filled out.
This same scenario could apply to lots of other situations but this is a generic use case that is pretty straightforward to understand. When the screen initially loads the 'Next' button, whose visibility is controled by the parent window, is visible but disabled as the child controls can't possibly yet be valid. At some point as the user fills out arbitrary data within one or more controls each one would return true if its Validate method was called.
At the point where all controls are valid, the next button would then become enabled. Fairly straightforward design.
The problem is each control doesn't know what screen it is on, and this is by design. I don't want the controls having to be aware of each other and updating a button status in the parent window. I also don't want the parent window to run a polling thread to call Validate every second because in some cases the validation could be complex.
I'm thinking that the change event of each control within the UserControl (text boxes, radio buttons, etc) would all call a trigger a private validate event and this would set some public property on the interface or class.
f I can do that is there a way for the parent window to respond in an event-driven manner to the change of that property? I'm not looking to do this in WPF, doing this in C# code is preferable as I don't want to get into the complexity of WPF quite yet. I'm just not sure, other than constant polling, how to tell when every control's 'IsValid' property will have synchronized all to 'true', if that is even a good approach.
EDIT:
Okay, here is another way to ask the question. I have a List of something (in this case a list of an interface) and want to be able to respond to a public property change on each item in the list so I can take an action when all items are (bool in this case) true. The above explains the use case, but this is a more generic version of the question.
EDIT:
#Vincent "you might do it in an even simpler way with a custom "ValidatedChanged()" event that you can hook in the same way."
It turns out that this is really what I was looking for. The property notification approach seems to be more for ease of use with data-bound controls. I read a lot of posts on this site about how to implement that but it really wasn't what I wanted. I just wanted my objects to notify that an event occured, which happened to be a property change, but that is beside the point. I found documentation on implementing an event in an interface and I have it working now. Thanks for pointing me in the right direction and helping me realize what is really is that I needed.
So you have a ListBox which contains all your controls, and when all controls are validated, the Next button should be enabled ?
If so, when one of your control validates, you might search all sons of the ListBox to check them for validation, using VisualTreeHelper.GetChildren to get them all.
If you don't want / can't have a handle on the ListView, you might find it by searching up the visual tree starting from the control that just validated.
Each 'Validated' event of each control would be handled by a 'CheckIfAllValidated' event handler, and when all are validated, you could raise a 'AllValidated' events that would be handled by the button (and maybe some other controls as well) to enable it.
Edit : I understood that you did not want each component to know about their children, but notice that even the quite common PropertyChanged event has a 'sender' fields that tells who did raise the event. So any listener of a PropertyChanged on, say, the 'validated' property, can go up the visual tree, stop when it encounters a ListView, then search downstairs if all control that have a validated property do have this property set to true...
Edit 2 :
To be more clear about how to do it, either in your window new or on the window loaded event
or maybe on the ContentRendered Event, depending on how your controls are loaded, you
might use once that code to hook a handler to all your controls :
For Each ThisControl In MainListView.
Dim ThisControlType = ThisControl.GetType
Dim ThisControlPropertyChangedEvent = ThisControlType.GetEvent("PropertyChanged")
' you might wanna check here if event is not null / nothing
ThisControlPropertyChangedEvent.AddEventHandler(ThisControl, New PropertyChangedEventHandler(AddressOf APropChanged))
Next
and you write the APropChanged somehow like that :
Public Sub APropChanged(ByVal sender As Object, ByVal e As PropertyChangedEventArgs)
If e.PropertyName = "Validated" Then
Dim ValidatedForAll = True
For Each ThisControl In MainListView.Items
Dim ThisControlType = ThisControl.GetType
Dim ThisControlValidatedProperty = ThisControlType.GetProperty("Validated")
'you might wanna check for non null here
If Not ThisControlValidatedProperty.GetValue(ThisControl, Nothing) Then
ValidatedForAll = False
Exit For
End If
Next
If ValidatedForAll Then
MessageBox.Show("Yeeppee") ' you might send an event instead.
End If
End If
End Sub
Edit 3 : you might do it in an even simpler way with a custom "ValidatedChanged()" event that you can hook in the same way.
This seems very simple, but I can find nothing on a web concerning the behaviour I want to add to my custom control.
My custom control is a textBox with a list of choices. When the text entered by the user is not part of the list, a popup will appear with the list allowing the user to select a correct choice.
Sometimes, there may be a default button on the container in wich the custom control has been added. If so, when the enter key has been pressed, if the text is wrong, The popup must been displayed. If there is no default button, on enter, nothing must happen even if the text is wrong.
To be able to create this behaviour, I must be able to detect the presence of a defaultbutton in the container, and it must be done inside the c# code of the cutom control.
I hope the description is clear enough.
Thanks in advance
Have you thought about implementing an MVVM approach and the Command pattern? So long as your view model knows what the choices are, you can bind the default button to a command. So long as the commands CanExecute handler returns false, i.e., an appropriate choice has not been entered/selected, the button will be disabled and won't respond to the user pressing enter.
Since I was unable to know what other controls I had from the custom control I chose to go like this:
I made a recursive function to find the first parent using FrameworkElement.Parent
Having the parent, I could take a look at every controls it contains.
As soon as I saw a button, I had to verify if IsDefault.
For this one, I used the VisualTreeHelper GetChildrenCount(DependencyObject obj_Parent) and GetChild(DependencyObject obj_Parent, int childIndex). Recursivity once again...
It works very well even though it means more code to execute.
I have a list box with Checkboxes in it. I want to prevent the Checkbox from changing its status if the user clicks on the text next to it. I only want it to change if the small box is clicked directly.
Is there any way to do this in windows forms?
Greetings and thanks in advance.
Place the text next to it in a Label, instead of the Text property of the Checkbox. Or you could create your own control which has a Checkbox and a Label. The Text property of the control would then fill the Text in the Label, and you could expose all of the Checkboxes regular properties in your control.
That's fairly non-standard behavior. Users are going to expect to be able to change the checkbox when clicking on its label, and are going to be frustrated, confused, and surprised when it doesn't work. I'd recommend not doing this. I'm not the only one.
(Yes, it's about web design, but many of the concepts are applicable in desktop application design as well.)
You could always not fill in the Text property of the Checkbox and make a completely separate Label control.
Otherwise, you will probably have to do explicit hit testing within the control to see if they hit the box or text. And then you will have to worry about checking the margins, which side the box is on, and other things that can change the position of the box.
I personally was only able to freeze things.
I freeze the check boxes by handling the Click and ItemChecked events,
and change the check state back, when it gets modified.
I use a menu to check/uncheck items and let user decide to use the menu or classic behave.
Cheers, good luck.