I have what may seem like a somewhat odd question. I'm trying to think of all the properties that can be set on Components that restrict/validate input in a way that are not handled by Validators.
For example, the "restrict" property can be set on Components of type SkinnableTextBase. restrict is a property that restricts input but a Validator doesn't handle it.
Another example is the "minimum" property. The minimum property can be set on Components of type Range and again it kind of restricts input.
So I'm looking for any properties like these.
Right now I have:
maximum
minimum
restrict
maxChars
Thanks!
Related
I'm (trying to) use AutoIT to automate some test cases. Ideally I would:
Open up a windows form
Plug in some values
Click a button
Check to see if the correct results appear in a Label control
I can do 1-3 but I can't see a way to get the caption of a label control.
After some digging I have found https://www.autoitscript.com/autoit3/docs/functions/ControlCommand.htm which allows me to get some additional properties (such as IsEnabled or IsChecked). Are there any generic property fetches / ways to get the caption or other properties?
The function ControlGetText() will return the caption or text of the specified control.
The function ControlCommand() can be used to get a few other properties depending on the control type.
Custom controls may resist automation - you may not be able to get the values you are after.
I have some custom ViewCell elements and most of them show and hide some components according to some properties of the BindingContext. I need to check values of some properties and show and hide some elements in the ViewCell, and also adjust the cell height accordingly.
Instead of writing value converters for most of the properties, I convert the BindingContext to underlying type and check the values of the properties in the OnBindingContextChanged event and right after that I build the UI with the relevant controls.
Do you think this is a bad way? Or is it ok?
I think it sounds quite counter-intuitive with regards to the MVVM model. Would you not be best binding the IsVisible property of the controls to a property determined in the ModelView?
e.g.
var label = new Label();
label.setBinding<ViewModel>(Label.IsVisibleProperty, vm => vm.IsLabelVisible, BindingMode.TwoWay);
You can then control the value of the IsLabelVisible property within the ViewModel instance.
One gotcha to consider is draw cycles and I would advise wrapping elements with toggled visibility states in Layout class.
Take a look at DataTemplateSelector pattern (similar to WPF):
http://forums.xamarin.com/discussion/comment/66502/#Comment_66502
I'm puzzled about whether the visible property of DisplayObject is:
an indication from Flex of whether the display object is visible.
an instruction to Flex to display the display object.
I'm asking because I'm automating some Flex tests using Flex Pilot, and I need to know for certain when a display object becomes clickable. In the application I'm testing, clickable seems to mean rendered.
Given the nature of the application and my tests, I don't think it's feasible to watch for the updateCompleted event. I need a way to detect whether the display object is visible based on the values of its properties and its containers' properties at a given moment.
I understand that even if a display object's visible property is true, it will be visible only if all of its containers are also visible. This means that I'll have to extend Flex Pilot by writing an ActionScript method to determine whether the display object and its containers all have visible=true. But I'm concerned that even that method won't tell me for sure that the display object is really rendered, and therefore clickable.
My puzzle comes from reading two descriptions from Adobe.
The "About creating advanced components" document suggests that the visible property is set by Flex after the display object is rendered. In this description, it is Flex's job to set the value,
so that value is thus an indication from Flex of whether the display object is visible.
On the other hand,
Adobe's description of the visible property suggests that the property is writable. And the code sample suggests that if the application changes the value, Flex will respond by displaying or hiding the display object. In this description, the application sets the value as an instruction to Flex to display the object. I'm guessing that in this case Flex re-renders the display object (if visible changes from false to true) or its container (if visible changes from true to false).
So two main questions:
Is the visible property used in both of these ways, both as an indication from Flex about the display object's visibility and an instruction to Flex about whether to display the object?
If the application changes visible from false to true, when does the display object actually become visible? Is it visible by the time the setter returns? Or does setting the property merely schedule the object to become visible during some later event? If it's the latter, that means there may be a duration during which visible is true, but the display object has not yet been rendered. If that's the case, I'm at a loss for how to determine, from the state of the display objects at a given instant, whether a display object has been rendered.
There are some key constraints for a DisplayObject to be rendered. First of all, it has to be in the display list. visible has to be set to true, otherwise it would be ignored from the rendering. The last key aspect is the so called elastic race track which basically describes when event handling, code execution and rendering occur. So, implementing event handlers for FlexEvent.UPDATE_COMPLETE is not so wrong, because those are dispatched when ever a property changes, which change the rendered representation of the component on the screen.
Is the visible property used in both of these ways, both as an indication from Flex about the display object's visibility and an instruction to Flex about whether to display the object?
Yes, the visible property is initially set to true by the framework before FlexEvent.CREATION_COMPLETE is dispatched, so the Flash player won't draw the component in a state (i don't mean the Flex view states), which is some where between construction and having the complete initialized view.
If the application changes visible from false to true, when does the display object actually become visible? After the next render cycle happend.
Depending of some flag I want to use certain component in my mxml.
There is not a default value. So it's probably incorrect to put one in mxml and then with states remove it and add the other.
Both also share the same interface, and I call methods in Actionscript using id. That means that if I put them in different states in mxml, the compiler will complain about same id used 2 times.
Is there any conditional statement or state management like: if x use this component, else use other one (preferably with mxml not actionscript) ? And in a way they are mutually exclusive (can have same id)?
Make ie. both components properties visible and includeInLayout listen (bound) to the flag. You can also use states. Always react on events that the components should dispatch. In the listener you can use the currentTarget to get the sending component.
The other way arround if you like to set a behaviour from somwhere without having access to the component id, define bindable properties and let both components listen to changes through bindings like I said with ie. the visible attribute.
This normaly should work for all requirements. If you can give me some sample code I could write you a short sample and moreover we could add it to your question.
Is there a clean and centralized way to automatically designate a background color or other CSS property for ASP.Net controls (i.e. a TextBox) with an enabled RequiredFieldValidator?
Currently I have manually set the background color of required controls to yellow. I would like to replace that with a central method so if the client requests a different color or marker or if a field's status changes from required to not or vice versa, I won't miss any of the controls.
Thanks
Update
This site is pre-compiled. Can something append a Css Class or other standards-compliant flag to items in the ControlToValidtate property at compile time?
Why not add a css class of required. You can have multiple classes on a single control by space delimiting them so imagine an input field which takes a number:
Now I can have two classes one which right aligns the text and one which handles the required field requirements.
Edit
One option before the page is rendered to walk through each control in the page, and if it's a required field validator, then find it's corresponding control and set the css property; however, this is a lot of work for somethign which you can tackle at design time.