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.
I create a new event definition ‘KeyStroke’
I create a Method ‘Keystroke’ which passes an Integer
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??
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.
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?
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”
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
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.
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.
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 dont raise from the Container.