Hey Mike,

I found the same issue as you describe with the Ultra Masked Edit control.  i.e. It selects all the data the first time you enter the field but if you type something and move away, when you re-enter the field it doesn't select the data.  My question is, Why not?  Every other Windows input field control I've used does (as far as I know).  I think it SHOULD select all the data each time you enter the field whether the data has been changed or not. 

I did notice that the Ultra Numeric and Masked Edit controls have a property called; SelectAllBehavior.  I tried setting it to the two different settings but didn't really notice any difference.  I did find that two Masked Edit controls that APPEAR to have all the properties set identically; mainly Edit As "String" and Input Mask "C" and SelectAllBehavior "SelectEnteredCharacters", behave differently.   On one of them, it behaves just the the numeric fields we're discussing.  The other one selects the data even after you change it, move away and then tab back in.  I haven't been able to find what's making the difference.

Regarding the Default Value...  If it's a Numeric Editor, and it's set to Not Nullable, and there isn't any data in the field, Wouldn't it make sense that the value SHOULD be set to 0 (zero) automatically??? 

And if it's a Masked Edit control with a Numeric Input Mask and it's set to Not Nullable, and there isn't any data in the field, Wouldn't it make sense that the value SHOULD be set to 0 (zero) automatically???  

It certainly seems to me like it should.   :)

As for my emails...  I get the "noreply" emails from the support people when they email me regarding open cases.  But I don't get emails when people reply to my posts for some odd reason. 

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.

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.

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.

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:

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"]

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.

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.

A:   It WOULD work if your controls were "smart" enough to not fire a Click event twice along with the DoubleClick event.  (yeah, yeah, yeah, I know... that's how the infinitely wise MS does it)

B:  The unlikely "breaking" scenario you gave would be due to some awfully sloppy programming on somebodies part.  I'd suggest that that type of programming deserves to get broken.

C:  I can't tell you how nice it is to have my tool suppliers KNOW what's best for me and my applications.  I wonder if that's how it works in every other industry...  Do the tool makers tell Ford that there's no compelling case to build a vehicle the way Ford wants to do it?  Do the subcomponent suppliers tell Boeing that there's no good reason they can see to build the part according to Boeings specs? 

D:  While I can appreciate and understand that this particular "feature request" may not rank up at the top of your importance list ...  I don't appreciate being told that just because you don't see a need for it, there's no reason to do it.  Just because that's not the way it's always been done, isn't a good reason for not trying something new.  Innovation usually involves doing things a bit differently.

E:  Finally, I've thought about this "we can't change the broken behaviour because it might break someones application" problem I keep running into.  It seems perfectly reasonable that when you come out with a new version (Like the upcoming Netadvantage 2009 vol 2), you could implement "breaking" style FIXES and changes as long as they were well documented in a "Breaking Changes" document.  This would eliminate the never ending reason for not fixing broken code. 

If a particular business doesn't want to deal with updating their software to handle the new PROPERLY functioning and enhanced controls, then they simply don't have to upgrage to the new version.  They can stay on their current version for as long as they like.  If I'm not mistaken, prior versions DO still get fix updates for some period of time after a new version comes out. 

While backwards compatibility definitely has some benefits, when it starts impeding progress it's time to let it go.

Wolven said:

A:   It WOULD work if your controls were "smart" enough to not fire a Click event twice along with the DoubleClick event.  (yeah, yeah, yeah, I know... that's how the infinitely wise MS does it)

This is not something that Infragistics invented. It's not even specific to DotNet - it's simply the way Windows works. When you click on something, the machine does not have any way of knowing that you intend to click a second time. It cannot see the future. So each click sends a click message.

I suppose Windows could simply buffer every click and not process it until the double-click time expired before deciding if a click is meant to be a single click or a double-click. But it seems to me this would make for a sluggish and annoying user experience.

Wolven said:

B:  The unlikely "breaking" scenario you gave would be due to some awfully sloppy programming on somebodies part.  I'd suggest that that type of programming deserves to get broken.

I don't think it's unreasonble for a developer to assume that since an event only fires for certain tools that it will continue to do so in the future.

Wolven said:

C:  I can't tell you how nice it is to have my tool suppliers KNOW what's best for me and my applications.  I wonder if that's how it works in every other industry...  Do the tool makers tell Ford that there's no compelling case to build a vehicle the way Ford wants to do it?  Do the subcomponent suppliers tell Boeing that there's no good reason they can see to build the part according to Boeings specs? 

I think we here at Infragistics are very open to customer requests and new ideas. But there are certain limits and standards that the operating system and the environment enforce upon us as well as our customers and there are good reasons for that.It provides consistency across applications and development tools.

Wolven said:

D:  While I can appreciate and understand that this particular "feature request" may not rank up at the top of your importance list ...  I don't appreciate being told that just because you don't see a need for it, there's no reason to do it.  Just because that's not the way it's always been done, isn't a good reason for not trying something new.  Innovation usually involves doing things a bit differently.

The fact that "that's not the way it's always been done" is irrelevant and I don't believe I made that suggestion.

My point here is that even if we did what you asked for and started firing the DoubleClick event for button tools, it won't help you acheive what you want here. So what would be the point?

Are you saying that we should add this feature simply because it was requested by a single customer - even though there is no practical use for it and it will take time away from the development of other, more useful, features?

Or are you suggesting that in spite of the fact that Windows fires 2 click events along with a DoubleClick that the toolbars manager should not do so? In order for that to happen, the toolbar would either have to somehow know that a second click is coming, or else delay the processing of the click event until the DoubleClick time (which is a system setting and can be changed) expired. Which means clicking on buttons would be slow an unresponsive.

Wolven said:

E:  Finally, I've thought about this "we can't change the broken behaviour because it might break someones application" problem I keep running into.  It seems perfectly reasonable that when you come out with a new version (Like the upcoming Netadvantage 2009 vol 2), you could implement "breaking" style FIXES and changes as long as they were well documented in a "Breaking Changes" document.  This would eliminate the never ending reason for not fixing broken code. 

I agree. And we occassionally do this when it's neccessary.

Yehaw,  we agree on one outta five...  :) 

On the one we agree on, can we add a case to fix the broken behavior of the dropdown control I documented a while back?  SInce it could theoretically be a "breaking" change (even you agreed it wasn't very likely to cause a problem), you weren't willing to add it back when we were discussing it.  But if we could add it as a Breaking Change Fix for 2009 vol 2, that would be nice.

Private Sub Application_Startup(ByVal sender As Object, ByVal e As System.Windows.StartupEventArgs) Handles Me.Startup

        Debug.Print(Thread.CurrentThread.CurrentCulture.ToString)

        'Thread.CurrentThread.CurrentUICulture = New CultureInfo("en-GB")

        '// Access any class from the Lipstick style pack assembly to

        '    // ensure that the assembly has been loaded. The assembly

        '    // automatically registers any themes that it contains

        '    // when it is loaded. Once this is done you can set the 'Theme'

        '    // property of the XamDataGrid, XamDataCarousel or XamDataPresenter

        '    // to one of its registered themes, in this case "Lipstick".

        '    //

        '    // Note: this would normally be done once in the App.xaml.cs file.

        Dim rd As ResourceDictionary = Infragistics.Windows.Themes.Lipstick.DataPresenter.Instance

        'Make textboxes auto select text on focus application-wide.

        EventManager.RegisterClassHandler(GetType(TextBox), _

                                          TextBox.GotFocusEvent, _

                                          New RoutedEventHandler(AddressOf TextBox_GotFocus))

        'and other controls as required.

        EventManager.RegisterClassHandler(GetType(Infragistics.Windows.Editors.XamMaskedEditor), _

                                         Infragistics.Windows.Editors.XamMaskedEditor.GotFocusEvent, _

                                            New RoutedEventHandler(AddressOf XamMaskedEditor_EditModeStartingEvent))

        EventManager.RegisterClassHandler(GetType(Infragistics.Windows.Editors.XamNumericEditor), _

                                         Infragistics.Windows.Editors.XamNumericEditor.EditModeStartingEvent, _

                                            New RoutedEventHandler(AddressOf XamNumericEditor_EditModeStartingEvent))

        EventManager.RegisterClassHandler(GetType(Infragistics.Windows.Editors.XamDateTimeEditor), _

                                        Infragistics.Windows.Editors.XamDateTimeEditor.EditModeStartingEvent, _

                                           New RoutedEventHandler(AddressOf XamDateTimeEditor_EditModeStartingEvent))

        Try

            'make sure user settings folder exists

            System.IO.Directory.CreateDirectory(MyGlobals.UserDataPath)

        Catch ex As Exception

        End Try

    End Sub

    ''' <summary>

    ''' When any textbox gets focus in app, select all text automatically.

    ''' </summary>

    ''' <param name="sender"></param>

    ''' <param name="e"></param>

    ''' <remarks></remarks>

    Private Sub TextBox_GotFocus(ByVal sender As Object, ByVal e As RoutedEventArgs)

        Dim tb As TextBox = CType(sender, TextBox)

        tb.Focus()

        tb.SelectAll()

    End Sub

    Private Sub XamMaskedEditor_EditModeStartingEvent(ByVal sender As Object, ByVal e As RoutedEventArgs)

        Dim tb As Infragistics.Windows.Editors.XamMaskedEditor = CType(sender, Infragistics.Windows.Editors.XamMaskedEditor)

        Try

            tb.SelectAll()

        Catch ex As Exception

        End Try

    End Sub

    Private Sub XamNumericEditor_EditModeStartingEvent(ByVal sender As Object, ByVal e As RoutedEventArgs)

        Dim tb As Infragistics.Windows.Editors.XamNumericEditor = CType(sender, Infragistics.Windows.Editors.XamNumericEditor)

        Try

            tb.SelectAll()

        Catch ex As Exception

        End Try

    End Sub

    Private Sub XamDateTimeEditor_EditModeStartingEvent(ByVal sender As Object, ByVal e As RoutedEventArgs)

        Dim tb As Infragistics.Windows.Editors.XamDateTimeEditor = CType(sender, Infragistics.Windows.Editors.XamDateTimeEditor)

        Try

            tb.SelectAll()

        Catch ex As Exception

        End Try

    End Sub

MIKEY!!!  Where are ya?

Wolven said:

Hey Mike, I got this popup message when I tried to post my last reply on this thread. 

Hey Mike, I got this popup message when I tried to post my last reply on this thread. 

"You have posted to a forum that requires a moderator to approve posts before they are publicly available.

If the administrator has configured this forum to support email notifications you will receive an email when your post is either approved or denied (if you have emails enabled in your profile). "

My first question is why the sudden change to moderator approved posts?  Also, I'm wondering if the second part of the message might pertain to why I never get email notifications of responses to my posts.  Specifically the "If the administrator has configured this forum to support email notifications" part.  HAS the administrator configured this forum to support email notifications??