I have an io field where I want to accept a number from 0 - 99,999. So I use the Ultra Numeric Editor and set the Min Value to 0, the Max Value to 99999. What's irritating me is when the field is displayed on the screen it has a Zero in it (which is correct) and when I tab into the field, the cursor is set in front of the 0. Consequently, if I enter a 1, the number becomes 10... I don't want that, I want it to change the value from 0 to 1. What can I set to have the Value automatically selected when I enter the field so that whatever I type OVERWRITES the value that was in there?
Why does the UltraMaskedEdit select the value when you tab into the field but the UltraNumericEditor doesn't? I would use the UltraMaskedEdit control as my Numeric IO field if I could set it to right justify the value and enter the value from the right side like a Numeric editor would, but unfortunately, I can't seem to make it do that... More irritation...
My second complaint on the Numeric Editor is that if I delete the 0 then try to exit the field, I get a beep and the cursor won't leave the field until I put in a 0 or some other value. (I realize I DO have the Nullable property set to False, which is what I want) How can I set a Default (like 0) value for the field?
Finally, I STILL don't get emailed replies to my posts, even tho I ask it to.
I tested out the tool double click event on the toolbar manager and it only appears to fire for the label and progress bar tool types. I'm going to take a leap here trying to think like the developers who design the controls and say that they probably just didn't hook up the double click events to these other menu tool controls because they thought the event wasn't relevant. But…. even with that said it wouldn’t have hurt to process the double click event regardless and leave it up to the customer developer to handle the event in whatever manner they wanted.
I don't know for sure since I haven't looked, but I doubt there is documentation that says oh by the way you can't use the tool double click event for X,Y and Z tool controls. I have to agree that since the event is fired on the toolbar manager which is global to all the tool objects that they all should handle the event. Just my two cents.
Mike said: My guess is that ToolDoubleClick only fires for certain types of tools like TextBoxTool or ComboBoxTool, and that it does not fire for button tools.
My guess is that ToolDoubleClick only fires for certain types of tools like TextBoxTool or ComboBoxTool, and that it does not fire for button tools.
Sorry Mike, but that doesn't make any sense. Those other tools also have the ToolClick event so, obviously, they would have to handle both events. If they can handle both events, so could the ButtonTool.
More fundamentally though, I seriously doubt the ToolDoubleClick would be a VALID event for a ButtonTool if it wasn't SUPPOSED to work. What are the odds that it IS supposed to work, and is just broken at the moment?
Mike said: I think a lot of time, Nullable is false because the developer wants to force the user to enter a value explicitly - not just assume that if they didn't enter anything it should default to 0.
I think a lot of time, Nullable is false because the developer wants to force the user to enter a value explicitly - not just assume that if they didn't enter anything it should default to 0.
I would disagree with that. If I don't allow Null as a valid input, I'm most likely not allowing it as a valid value in the corresponding database field either. Consequently, the MINIMUM value to be stored would be 0, which WOULD be the default. If I was wanting to force the user to enter something, I would just test that the input value was greater than zero.
There seems to be a really big disconnect between "systems" level programmers (people like yourself) and real world business application programmers (people like me). In an accounting system, there is no such thing as null. Null simply means Nothing, which is EXACTLY what the numeric value of zero is. Zero tomatoes means there aren't any, Notta, Zilch, Zero, Nothing. We don't need ANOTHER value to represent the exact same thing.
Personally, I absolutely despise Null. It's just a pain in the butt. Except in extremely rare cases, (and NONE in accounting or any other business application I've ever written) it serves no purpose other than creating a whole lotta program errors and stupid test statements to insure that a value isn't null.
All that said, If Infragistics just can't bring themselves to agree that an emptly NON NULLABLE Numeric field should automatically default to 0, then AT LEAST give us the ability to set a Default Value, (which would be zero 99% of the time).
Wolven said:I'm TRYING to utilize both the ToolClick and the ToolDoubleClick events using an UltraToolBarsManager Toolbar, but the ToolDoubleClick event never happens. Why? Obviously the ToolClick event is intercepting it before the ToolDoubleClick can be fired... but that SHOULDN'T be the case.
I'm not sure, Toolbars isn't really my area of expertise. But my guess is that ToolDoubleClick only fires for certain types of tools like TextBoxTool or ComboBoxTool, and that it does not fire for button tools.
Wolven said:Apparently you missed the part about the control being set to NOT NULLABLE. If it's a NOT NULLABLE Numeric control or Input Mask and no value is entered then... Wouldn't it make REALLY GOOD LOGICAL sense that the value SHOULD be set to 0 (zero) automatically??? :)
Hm, I did miss that part. But I'm still not sure that the control should assume that null is 0 when null is not allowed. I think a lot of time, Nullable is false because the developer wants to force the user to enter a value explicitly - not just assume that if they didn't enter anything it should default to 0.