Adding event to ContainerControl

General
1

I have a Container Control with a textfield and some buttons. I want to pass the KeyDown event of the TextField to a Container Control event so it can be used in instances of the control.

  1. I create a new event definition ‘KeyStroke’
  2. I create a Method ‘Keystroke’ which passes an Integer
  3. In the KeyDown event of the Textfield I call the Keystroke method and pass the key parameter as Asc(Key)

This doesn’t work. I’m mixing things up. But what??

2

Skip the Keystroke Method. In the KeyDown event use:

RaiseEvent KeyStroke(key as Integer)
3

[quote=50550:@Greg O’Lone]Skip the Keystroke Method. In the KeyDown event use:

RaiseEvent KeyStroke(key as Integer)

This is the event definition

Event KeyStroke(key as Integer) As integer

and this is the KeyDown (of the Textfield)

KeyStroke(Asc(Key))

Compiler responds with:

You must use the value returned by this function:  RaiseEvent KeyStroke(Asc(Key))
4 
Call RaiseEvent KeyStroke(Asc(Key))

or simply

Call KeyStroke(Asc(Key))
5

or…

Dim i as integer = KeyStroke(key)
6

Ok… Call Keystroke did the trick. Thanks!

7

I am trying to do this same thing…Have the containers keydown event fire when the keydown event of an enclosed textedit fires.

I have to create a “new” event name? Rather have the KEYDOWN of container be the event to not break naming conventions

myContainer.KeyDown(key) as opposed to myContainer.KeyStroke(key) with myContainer.Keydown being a dud

8

No
Define an event on the container “KeyDown” and have the keydown even implementation of the text field/area raise that event

9

I tried that…

myContainer contains myTextField

  1. added KeyDown event to both
  2. in myTextField.Keydown … I tried Call RaiseEvent self.keydown(key)…

which obviously is not the correct syntax

10

Ah crap I forgot that containers already have a keydown event
You won’t be able to call it that as there would be a conflict
Sorry

11

Other said how to get around it, but… more importantly you should ask yourself why. Xojo is failing to compile here because KeyStroke returns a value? Otherwise it shouldn’t have to have the Call.

So, does your event need a return value? If so, then you should probably pay attention to what the event handler returns. In general when you find that you are using Call, you are doing something wrong. This is because the function you are calling returns a value and you are expected to use that value. If you don’t need the value, why are you calling the function? For example:

[code]Dim a As FolderItem = GetFolderItem(‘hello.txt’)

// vs

GetFolderItem(‘hello.txt’)
[/code]

Why would one ever do the later? There are some special circumstances when Call is acceptable, but they are by far the exception, not the norm. Thus, one should always question their code if they find a Call statement and ask why.

12

Ok… still missing somthing… I got around the KeyDown by creating a new event “keystroke” just like above…
and the keydown of my textedit says “KeyStroke Key”

but now I want to add a TextChange event to the Container… an event the container does NOT already have

I added a textchange event to the Event Definitions section of the container

and in the TextChange event of the TextEdit I put “self.textchange” (item does not exist)

there has to be a way for a container to inherit the child control events…

Isn’t the purpose of a container control to present a single “entity” to interact with?

13

It doesn’t seem to like you creating an event with an existing name… even though a ContainerControl does not have a TEXTCHANGE event…

If I rename the container level event to TEXTCHANGED (with a “d’”) it works…

meaning my custom control will have events that do the same as “similar” named events in standard controls, but not the same name… not optimal :frowning:

14

RaiseEvent TextChange

That works fine here

  1. new container control
  2. add event def “TextChange” to the CC
  3. add textfield to the CC
  4. implement TextChange in the control with “RaiseEvent TextChange”
    run
15

ok… I was trying to force a scope… but I guess that is not necessary…

I was of the mindset that “RaiseEvent TextChange” in a TextChange event would result in infinite recursion… but I guess it is “smart” enough to move to the “parent”

16

usually the discussion involves “magic happens here”, and a fair bit of handwaving, when you get down to how its all implemented and hooked up but in slightly loose terms it gets sent to its container

and because of how containers & windows work well it gets a little complex

suffice to say it just works :stuck_out_tongue:

17

Thanks… was not questioning it working… just my mindset originally didn’t allow my brain to go that way…

and yeah… it works perfectly… thanks

18

The code you put in the textfield’s event handler is owned by, and runs in the context of, the container, not the textfield. That’s why you have to use “me” to refer to the textfield. Everything else is resolved to the container.

That’s probably an oversimplification, but it helps me to think of it that way.

19

Ok… this is an old topic… but I find myself chasing this issue yet again.

I have a container control with an embedded textfield.

I need to have the KEYDOWN (and KEYUP) events of the Textfield, exposed to the Window that contains an instance of the Container Control. I could create a totally new set of events with new names, but that then deviates from the currently accepted format…

The problem (as Norman stated years ago) is that the Container Control has its own key events.

I had thought that if I did nothing in the TextField events that they would then move up and execute the parent (ie. container) events… but that doesn’t seem to be the case.

I need the container keyDown/Up events to fire when the keyEvents of the Textfield do.

20

Implement the key up and key down events on the container and then right-click on each of them and create event definitions. In the KeyUp and KeyDown events of the TextField, raise the corresponding events on the parent container and don’t raise from the Container.