More central method/event to capture TextField Return/Enter to prevent beeping?

I have a similar question to the one described in this closed topic:

https://forum.xojo.com/t/enter-key-in-text-field-beep-windows/43438

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:

image

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.

Yes, that is the place.

The event handler goes in the MyTextFields is used. You cant define a new event and handle it in the same level subclass

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:

image

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.

You can use an class interface like actionNotificationReceiver to do what you want.

@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 examples → patterns → observe

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.

Thanks – you are absolutely correct to warn about that.