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.
Wolven said:are you sure they fire both events on a DoubleClick?
Absolutely. Try it with a Button control.
Wolven said:If so, then how does the control know that there was a DoubleClick instead of two Clicks?
A double click includes two clicks. The control can't know when you click once that you intend to click again. A double-click fires when two click events occur within a certain span of time (as determined by the operating system). But whether you get a double click event or not, you still get two click events.
Wolven said:C'mon Mike... you're not thinking very hard on that one... :) How many Windows (mainly grid or item list type) controls utilize Click for select and do "something", and DoubleClick for open, or some other process? Quite a few.
Yes, I was not clear here. I mean simple controls like buttons. Obviously, I already mentioned the example of a Tree control above where clicking selects an item but double-clicking expands it.
Wolven said:How could it POSSIBLY be a "breaking change"??? You mean like, many people might have written subroutines to handle the NON FUNCTIONING Button Tool DoubleClick event? And if we suddenly made it actually work, then those routines would actually run and mess up their software? loloLoLoLOL ROTFLMAO ... Sorry dude, but that just doesn't add up. :)
Actually, it does. Suppose you have a very simple application with a few buttons and a TextBoxTool. You could handle the ToolDoubleClick and just respond to it under the assumption that only the TextBoxTool could possibly have triggered it. Now the DoubleClick event starts firing for button tools and your application is broken.
I admit this seems unlikely, but we have to be very careful about making assumptions like this. If it breaks even one customer's application and doesn't add any value to the control, then it's really not worth it.
Wolven said:And as for a reason why, How 'bout this one... Because it WOULDN'T cause any problems, it WOULD make your controls logically consistent, and MOST IMPORTANTLY, because a customer asked for it.
If there was some useful purpose to it, I would agree with you. But so far, I haven't heard any compelling case where this would be at all useful. So it can potential break existing applications, and it adds nothing. It won't even work for the specific case you were trying to use it for. Quite frankly, we have a long list of feature requests to add that are all useful and beneficial and there's no reason to add features that no one can or will use, just to make the control logically consistent. Not that there is anything wrong with being logically consistent... but it has be tempered with a practical consideration of what's useful and important. :)
Mike Saltzman"] Even if a button tool did fire the ToolDoubleClick event, the ToolClick event would still fire first and open the Explorer Bar. Click and double-click are not mutually exclusive, they both occur in order.
Even if a button tool did fire the ToolDoubleClick event, the ToolClick event would still fire first and open the Explorer Bar. Click and double-click are not mutually exclusive, they both occur in order.
I'm not arguing here, because I don't really know how the controls work... but are you sure they fire both events on a DoubleClick? If so, then how does the control know that there was a DoubleClick instead of two Clicks? And does it do the the Click processing twice on a DoubleClick in ADDITION to the DoubleClick? I'm guessing a control uses timing to check for the DoubleClick? And IF it checks the timing of a Click to see if it is within the "time window" to be a DoubleClick, then why wouldn't it wait to process the Click by that same amount of time just so that it COULD avoid firing both events on a DoubleClick?
Mike Saltzman"] There are some controls where having both click and double-click might be useful. But I honestly can't think of a good use case for this.
There are some controls where having both click and double-click might be useful. But I honestly can't think of a good use case for this.
C'mon Mike... you're not thinking very hard on that one... :) How many Windows (mainly grid or item list type) controls utilize Click for select and do "something", and DoubleClick for open, or some other process? Quite a few.
Mike Saltzman"] In any case, changing this behavior and suddenly starting to fire the event would be a breaking change, and I can't see any reason why this should be changed.
In any case, changing this behavior and suddenly starting to fire the event would be a breaking change, and I can't see any reason why this should be changed.
How could it POSSIBLY be a "breaking change"??? You mean like, many people might have written subroutines to handle the NON FUNCTIONING Button Tool DoubleClick event? And if we suddenly made it actually work, then those routines would actually run and mess up their software? loloLoLoLOL ROTFLMAO ... Sorry dude, but that just doesn't add up. :)
And as for a reason why, How 'bout this one... Because it WOULDN'T cause any problems, it WOULD make your controls logically consistent, and MOST IMPORTANTLY, because a customer asked for it.
Wolven said:The entire point was to AVOID having to opent the Explorer bar to launch the first option.
Well, that would not work, anyway. Even if a button tool did fire the ToolDoubleClick event, the ToolClick event would still fire first and open the Explorer Bar. Click and double-click are not mutually exclusive, they both occur in order. In fact, you would probably get two ToolClick events.
Wolven said:And you ignored the example of a grid (and other controls) that DO have both a Click and DoubleClick event.
Most controls have both because these are events of Control. So any control inherited from Control will have both events. A button has both. But I think it's pretty rare that anyone uses the DoubleClick event of a button. A user does not expect to have to double click on a button to get it to work. And if they click once and it does something, you typically want it to do the same thing again when you click again, not do something totally different.
Wolven said:I'm still of the opinion that BOTH events SHOULD work on the Toolbar buttons. It can't really be that difficult for Ingragistics to make it work, can it? Especially since the logic for handling Click AND DoubleClick is in plenty of other controls.
This was a design decision that was made many years ago with the original release of UltraToolbarsManager. It was probably implemented this way as a convenience to make handling the ToolDoubleClick event easier. Because now you don't have to bother checking for button tools.
You are, of course, free to Submit a feature request to Infragistics if you like.
Mike Saltzman"] It sounds to me like you would just use the Click event here. If the Explorer bar is not open and the click event fires, you open it. If it is already open, you perform the first option.
It sounds to me like you would just use the Click event here. If the Explorer bar is not open and the click event fires, you open it. If it is already open, you perform the first option.
The entire point was to AVOID having to opent the Explorer bar to launch the first option.
And you ignored the example of a grid (and other controls) that DO have both a Click and DoubleClick event.
I'm still of the opinion that BOTH events SHOULD work on the Toolbar buttons. It can't really be that difficult for Ingragistics to make it work, can it? Especially since the logic for handling Click AND DoubleClick is in plenty of other controls.
Wolven said: In Windows Explorer I can slowly click twice on a file name to rename it, or I can doubleclick it to open it.
Yes, but this is not a double-click, this is two separate clicks.
Clicking once selects a file. Double-Clicking launches that file or expands the directory. This is intuitive and makes perfect sense because the click does not interfere, and in fact assists, with the double click. That makes sense for an item in a tree or even a grid row, but it does not make sense for a button. Clicking a button doesn't select the button, it performs some action and that action will presumably interfere with anything that a separate and distinct double-click action might do.
Wolven said:More specifically, in my particular case, I have a button that opens an explorer bar with various options that can be performed on a particular file (SQL Table). I want to have the SAME button just automatically start up option 1 (the main editing program for that particular file in this case) on the DoubleClick event. Again, whether that seems "intuitive" or not doesn't really matter. The users will quickly learn how it works and they will appreciate that they don't have to click once to open the menu bar, and then click again to edit the file.
It sounds to me like you would just use the Click event here. If the Explorer bar is not open and the click event fires, you open it. If it is already open, you perform the first option. This is not a double-click, it's two separate and distinct click operation that behave slightly different based on the current state of the application.