If I have a container that has several text fields, do I need to add a method to each and every text field to capture the enter key in order to prevent it from beeping? Right now the return/enter key (on Windows) beeps when pressed in a text field, but ALSO presses the default button (“OK”, for example).
Is there a more central way to handle this behavior for the entire container?
I agree with the poster that sees the present behavior as a bug: If the text field is going to beep because return/enter is not allowed, then the keystroke has been captured and handled, and should NOT be passed on to press the default button.
Yeap IT IS A BUG but… Dont hold your breath to be fixed.
Create a subclass of the TextField and return True in the KeyDown event to avoid the beep. As a next step, I define a custom Event called “EnterPressed”, and use that to call the “default” behavior.
If Key = chr(3) Or Key = chr(13) Then
RaiseEvent EnterPressed
Return True
Else
Return False
End If
@Ivan_Tellez – this sounds like a workable solution, but let me see if I understand:
I create the subclass of DesktopTextField, then change any and all TextFields so their super is the new subclass;
Implement KeyDown even in the subclass, and look for return/Enter. Return True if I handle it, false otherwise. (I do NOT need to call my super’s KeyDown from there, right?)
I’ve never created a custom event before (unsure how to do that), but in the general event documentation, I read that although I MUST raise the event from within my subclass, could I receive the event in my Base Class I use for all Containers? That way a derived Container could press the Default Button.
I’m not clear where the Event Definition goes. I’ve place it here:
However, I was trying to add an Event Handler in my subclass of DesktopContainer (“BaseContainer”), or even to a derived container that has the derived MyTextField, but the HandlePressingEnter doesn’t show up in the list of events.
if you call RaiseEvent HandlePressingEnter the “event” appear in the parent control where you had placed it.
for this constellation
mybasecontainer<-mycontainer1-<mycustomtextfield1
window1<-mycontainer1
the “enter” event from textfield appear in mycontainer1
you call a method in your base container Super.MyEnter
mybasecontainer have a protected method MyEnter
mybasecontainer have a event definition MyEnter
in this MyEnter method call RaiseEvent MyEnter
this MyEnter event appear in your window at your mycontainer1.
mycontainer1 have super to mybasecontainer
mybasecontainer have super to DesktopContainer
mycustomtextfield have super to DesktopTextField
@MarkusR & @Ivan_Tellez – I very much appreciate your responses, but I still do not understand why I cannot add the actual Event Handler (“HandlePressingEnter”) ANYWHERE. Could it be that this Event Definition needs either a parameter, or a return type:
So YES, I WOULD like to add the Event Handler “HandlePressingEnter” to the derived container, but cannot, because it doesn’t appear in the list of available Event Handlers.
You can only implement your event handler from the event definition in a subclass or a control on the ide. The other option is in code trough AddHandler.
Lookup some examples you can implement events in all subclasses, also from your textfield you can RaiseEvent InYourContainer if it’s a subclassed type.
@DerkJ – OK, I see that you are correct – I CAN add the event handler to the actual field that derives from MyTextField.
But as a strategy to handle filtering out the Enter key from a text field, and pressing the default button “OK” in the container – is that really any different than calling a derived method? I’m unclear what, in this case, using a Custom Event gains?
As best I can tell, it SEEMS as if a good solution (for me) is to derive a MyTextField with DesktopTextField.KeyDown implemented (as below) to call my BaseContainer’s “NextAction()” method, which every one of my containers implements:
If Key = chr(3) Or Key = chr(13) Then
Var myContainer as BaseContainer = BaseContainer(self.Parent)
myContainer.NextAction()
Return True
Else
Return False
End If
This appears to work as expected. As others have noted in other threads, this is a lot of work for a fairly common use case – it would be better if DesktopTextField had a property to simply ignore Return/Enter.
@DerkJ – What would be the advantages of using actionNotificationReceiver? Wouldn’t it be directly equivalent to implementing a method in a base class?
Interfaces decouple the classes, giving them a know type with known methods. ActionNotificationReceiver is something you could use but it may also be a custom one.
In this code, make sure you check if Self.Parent IsA BaseContainer before casting or you will get an IllegalCastException at runtime if you place your custom control onto a different container or window.