Using infragistics UltraNumericEditor, if I set the .MaxValue to 50, the control will allow me to enter decimals larger than the limit (for example, 50.99)
I see the same behavior if I set the .MaxValue property to 50.01 (can set values larger)
I can obviously resolve this in code but resetting the value, but it seems like the control should do this on its own.
Is there something I'm missing in how to use these properties correctly?
I suppose you are using the UltraNumericEditor with the property Style set to Decimal (or Double).
In this case the control allows you to insert digits that render the input invalid with respect to the property MaxValue. However, by default, you are not able to exit the control until the value is correct.
If you want, you can use the event ValidationError that gives your the ValidationErrorEventArgs parameter. This parameter contains the LastValidValue property to reset the wrong value, the RetainFocus to let your user exit from the editor (or, if you prefer, display an error message)
private void ultraNumericEditor1_ValidationError(object sender, ValidationErrorEventArgs e)
{
// Reset the content to the last valid value and allow the exit from the editor
ultraNumericEditor1.Value = e.LastValidValue;
e.RetainFocus = false;
// In alternative display a message, but leave the wrong value to be reedited
// DisplayValidationMessage("The max value allowed is 50.00");
}
The problem was a result of the IEditorDataFilter for percentage values.
Infragistics recommends, and I had implemented, an IEditorDataFilter which converts decimal percentages (.5 = 50%) into percentages for display.
This filter is applied before the validation for the control takes place. Therefore, setting the MaxValue to "50" allowed me to enter "50.99" but not "51"... normally this would have caused a validation error as per Steve's answer. However, because of the IEditorDataFilter applied to this control, the value was automatically converted to .5099 and this new value does not violate the constraint.
The solution I implemented was to check the value in the Validated event to see if it was larger than the MaxValue / 100, and if so to set it equal to the same.
Related
As far as I am aware this actually works, so it might be a red herring. But ...
I have this definition:
static UINT BASED_CODE indicators[] =
{
ID_INDICATOR_DATE,
ID_INDICATOR_ZOOM,
ID_INDICATOR_CALENDARS,
ID_INDICATOR_MEETING_TYPE
};
Note that the value of ID_INDICATOR_DATE is 33604.
At the appropriate moment during my dialog's create I set the indicators for my status bar:
m_StatusBar.SetIndicators(&indicators[0], to_underlying(StatusBarPane::Count)); //Set the number of panes
I noticed in debug mode:
12d:\a01_work\20\s\src\vctools\VC7Libs\Ship\ATLMFC\Src\MFC\barstat.cpp(128) : AppMsg - Warning: failed to load indicator string 0x8344.
I determined that 0x8344 is hexadecimal for 33604.
I realised that SetIndicators returns a BOOL so I tested the result and it was 0. Since the official documentation does not say how to proceed from here - what to do? My panes appear to be operational.
The indicators array is defined at the top of the CPP file. And the statusbar is created in OnInitDialog.
I am using BoboBrowse together with Lucene.Net. There are some predefined facethandlers for different scenarios. My question: Does anyone know how to implement a handler for a bool type/property of a lucene document? I mean, from a facets search point of view theres just a field/facet with 2 different values "true" and "false", so the result contains that values of course. But the result set seems then a bit strange: 300 objects with true, 400 with false. With a bool value of false, the result set should contain all objects, with set to true only that 300.
Thanks.
With Bobo-Browse.Net, there are 2 different aspects of setting up a facet.
Facets are defined at application startup and generally map to a specific field (or sometimes more than one field).
Selections are defined at runtime and determine which values are included in the search. Generally speaking, selections act like boolean switches over each unique value in a field.
So, in the case of a "boolean" field (which is actually just plain text), you just have 2 possible values. But keep in mind, there are actually 3 selection states for this "boolean" field:
Selecting "true"
Selecting "false"
Not selecting anything
It sounds like you just want to have your runtime code add/remove a single selection for "true", which will make it include all "true" values, or (if the selection is removed) include all values.
BrowseSelection sel = new BrowseSelection("booleanField");
if (value == true)
{
// Add the selection to filter the result
sel.AddValue("true");
}
else
{
// Don't add a selection, and the result will not be filtered.
}
browseRequest.AddSelection(sel);
Have a look at my Faceted Search Prototype for an example how this can be set up on the UI (although this wasn't really meant to be a demo and has lots of commented garbage code in it, it does demonstrate the concept). If you want to omit the search part of it, you just need to use a MatchAllDocsQuery instead of parsing the query using QueryParser.
Why does this code snippet not write the values back to Excel unless I un-comment the range.values=range.values line?
$('#run').click(function() {
invokeRun()
.catch(OfficeHelpers.logError);
});
function invokeRun() {
return Excel.run(function(context) {
var range = context.workbook.worksheets.getItem("Sheet1").getRange("A1:B3");
range.load('values');
return context.sync()
.then(function() {
range.values[1][1]=99;
console.log(JSON.stringify(range.values));
//range.values=range.values
return context.sync();
});
});
}
Array properties are special. I have added a page on my website to describe the topic: Reading and writing array properties.
Summarizing from there, the way that the proxy-object model works, whenever you set a property on an object, the Office.js runtime has a hook into the setter and getter, which is used to intercept the call and add the command to the queue.
Let's take an example of a regular property first. Per the above, whenever you set something like range.format.fill.color = "red", the setter for the color property intercepts the request and internally adds a command into the queue to set the range fill color to red (to be dispatched with the next context.sync)
On the other hand, if all you had was var color = range.format.fill.color
(after a load and a sync, of course), the getter would fire instead of the setter, and the color variable would get the range's current fill color.
Now, that was regular properties. Whenever you set an element of the array, you are effectively accessing the array value as a getter. From a runtime perspective, this line is no different from a slightly more verbose version:
var array = range.values;
array[r][c] = '-';
Because the getter for range.values returns a perfectly plain JS array object, accessing it and then setting its value does nothing to propagate it back to the original Range object.
If you want the values to get reflected back, the best thing is to get a reference to the array right after the sync (i.e., var array = range.values, just as above), then set the values on the array as needed, and then finally set it back to the object: range.values = array.
It means you could also modify the values array in place, and then assign the values property back to itself at the completion of the loop (range.values = range.values). However, this looks awkward, as if it’s a no-op, whereas in reality it is not. So personally, I prefer to retrieve the array at the beginning and assign it to its own variable, then do any necessary modifications, and finally set the full array back.
UPDATE to clarify the above:
To be very clear, the arrays returned by accessing the .values, .formulas, etc., ARE pure vanilla JS arrays. That's actually the crux of the problem: that in order for Office.js to return pure objects, it means that those pure objects can't be "spiked" with the ability to reflect changes.
For what it's worth, we actually have an upcoming feature that should be rolling out in a month or two, where we will be introducing an object.set syntax, as in:
range.set({
values: [[1, 2], [3, 4]],
format: {
fill: {
color: "purple"
}
}
}
This will make it more convenient to set multiple properties on the same object, but it might also make the array properties easier to deal with.
Is that correct:
When I query a value before validation (or if validation failed) I have to use getSubmittedValue();. Once the value is validated, even if I query it in another validation later in the page/control I have to use .getValue(); since getSubmittedValue(); returns null after successful validation?
This xsnippet makes it easier to handle this. It allows you to just call getComponentValue("inputText1") to get either value or submittedValue.
Here's the function for reference:
function getComponentValue(id){
var field = getComponent(id);
var value = field.getSubmittedValue();
if( null == value ){
// else not yet submitted
value = field.getValue();
}
return value
}
There's a slightly easier way: if you're just expecting a simple single-value String, just call:
var compare = firstField.getValueAsString();
Otherwise, call:
var compare = com.ibm.xsp.util.FacesUtil.convertValue(facesContext, firstField);
The former calls the latter anyway, but is obviously a terser syntax. This does what you're looking for and more:
If the value hasn't yet been validated, returns the submitted value
If validation has already passed, returns the value after it's already been processed by any converters and / or content filters, so particularly in cases where you're trying to compare two field values, this should ensure that both values have been properly trimmed, etc., and is therefore less likely to return a false positive than just comparing the raw submitted values.
Found the answer here. So when you want to ensure that 2 text fields have the same value (use case: please repeat your email) and the first box already has a validation that might fail, you need to use submittedValue unless it is null, then you use the value. Code in the validation expression for the second field looks like this:
var firstField = getComponent("inputText1");
var compare = firstField.getSubmittedValue() || firstField.getValue();
compare == value;
You have to love it.
public HtmlComboBox NetworkSelectBox
{
get
{
HtmlComboBox networkSelectBox = new HtmlComboBox(ConfigVMPage);
networkSelectBox.SearchProperties[HtmlComboBox.PropertyNames.Id] = "vnic";
networkSelectBox.SearchProperties[HtmlComboBox.PropertyNames.Name] = "vnic";
networkSelectBox.FilterProperties[HtmlComboBox.PropertyNames.ControlDefinition] = "style=\"WIDTH: auto\" id=vnic name=vnic r";
return networkSelectBox;
}
}
Above is the code I define an UI element and I want to set the property
NetworkSelectBox.SelectedItem = "LabNetworkSwitch";
I've used this way on other elements and all success, but in this one i got the error message
Microsoft.VisualStudio.TestTools.UITest.Extension.ActionNotSupportedOnDisabledControlException: Cannot perform 'SetProperty of SelectedItem with value "LabNetwokrSwitch"' on the disabled or read-only control.
How can I change the control type?
I don't think you want to change the control type. I would suggest trying either waitforready() or find(). What is likely happening is when the control is initially found it is disabled, and find() will sync the actual control with the current networkSelectBox. WaitForReady() is probably the preferable method here though it will implicitly refresh the values of the combo box until it is available for input or the time out has expired.
I doubt you will run into this issue with HtmlComboBoxes but with a couple of WinComboBoxes I have had issues where they could not be set using SelectedItem or SelectedIndex. I ended up doing KeyBoardSendkeys(Combobox,"firstLetterOfItem") until the selected value was correct.