TextField not handling events properly

[AjBreidenbach]

Assigning handlers to a TextField via onAction does not work because sendAction is called on the TextField without passing an Event. I have not looked into it further, but it seems that in some cases no action is sent at all. Is this being worked on or is there a different way of assigning handlers? Otherwise, I would be willing to work on a fix

[yglukhov]

@AjBreidenbach, onAction is the intended way to handle text field change event. However, most likely the Event will be etUnknown in most cases, because action may be sent as a result of e.g. focus lost. Also note that without continuous flag the action event will be sent only in some cases (e.g. user hits Enter key, or text field loses focus). With continuous flag the action event will be triggered on every change of the input. Just played with the sample and could not see any issues. If you think there are, please feel free to file a PR along with the steps to reproduce. Thank you.

[AjBreidenbach]

@yglukhov I wasn't aware of continuous before, but I think this should reproduce the issue. I would expect the text contained in the tf to be echoed whenever it is changed.

import nimx.window, nimx.text_field, nimx.system_logger, nimx.event

proc startApp() =
  var window = newWindow(newRect(40, 40, 800, 600))

  var tf = newTextField(newRect(350, 275, 100, 50))

  tf.continuous = true
  tf.editable = true

  tf.onAction(proc (e: Event) =
    case e.kind
    of etTextInput, etTextEditing: echo tf.text
    else: echo e.kind
  )

  window.addSubview(tf)

runApplication:
  startApp()

I think this would work properly if insertText passed an Event when calling sendAction

Would that be the best way to do it?

[yglukhov]

@AjBreidenbach, I don't think you need to handle the e arg in your handler. In fact, i've been thinking about deprecating the signature that takes the event altogether. For controls you only need to know that their action is triggered, while Events should be processed at a lower level (e.g. when implementing a custom control/view). Basically your case could be rewritten as:

import nimx.window, nimx.text_field, nimx.system_logger, nimx.event

proc startApp() =
  var window = newWindow(newRect(40, 40, 800, 600))

  var tf = newTextField(newRect(350, 275, 100, 50))

  tf.continuous = true
  tf.editable = true

  tf.onAction do():
    echo "Text changed: ", tf.text

  window.addSubview(tf)

runApplication:
  startApp()

To summarize. I don't see a reason to handle e. Provide your use case if you think otherwise.

[AjBreidenbach]

@yglukhov If e is deprecated and events are handled based on the properties of the Control instance, I don't see a use for it either. I only thought it was an error because I started with Button which passes a proper Event object.

Will nimx replace event passing with essentially the observer pattern?

[yglukhov]

Will nimx replace event passing with essentially the observer pattern?

Not sure about that. If you mean "subscribing to changes of particular properties" then unlikely, because there are not much properties to be interested in (e.g. for TextField (if editable) there's only text, if not editable, there's none. For Button there is if it's a checkbox/radiobox, otherwise there's none).

But maybe I misunderstood your question, so you could elaborate on that with a sample source code you would like to work eventually? =)

[AjBreidenbach]

Sorry, I probably phrased that question poorly, but it seems like the items' properties will determine which events they are subscribed to receive. It's not really an event listener then and it doesn't delegate anything, right? If my TextField is marked editable, it receives notifications when the text is edited.

Maybe I don't understand the difference well enough to explain :)

[yglukhov]

@AjBreidenbach, sorry, but I'm totally confused now. =) Like I said, I might better understand a code sample that demonstrates the suggested feature.

[gogolxdong]

text field displays a mixed string of what was typed. typed a,b,c