I need to update a cocoa control which has a GetView event. Is there a way to programmatically force this event to fire?
In you GETVIEW event handler put something like
getview_execution_code()then create a method containing all the code you want the “event” to execute
SUB getview_execution_code()
<do stuff>
END SUBAny where you want to “force” the event, just call the METHOD you created
Thanks Dave,
I probably should have been a little more concise
I have code in the GetView event to dynamically build an NSPathView and use a folderitem variable to designate the path. So that part is already done. I just need to repeatedly call this to change the path to match the selected file.
The GetView event is expecting an NSView to be returned to it. I need to force the GetView event to fire or find some other way to replace the view with a new one.
Your solution would require me to find that other method. If I knew that I would no longer have a problem Time for the books I guess
[quote=134286:@Bill Martini]Thanks Dave,
I probably should have been a little more concise
I have code in the GetView event to dynamically build an NSPathView and use a folderitem variable to designate the path. So that part is already done. I just need to repeatedly call this to change the path to match the selected file.
The GetView event is expecting an NSView to be returned to it. I need to force the GetView event to fire or find some other way to replace the view with a new one.
Your solution would require me to find that other method. If I knew that I would no longer have a problem Time for the books I guess [/quote]
Create a method for the control with the same name as the event: GetView. Now in that method use the same parameters that the event uses. The code of the method simply raises the event.
Sub GetView(some_parameter)
RaiseEvent GetView(some_parameter)
End SubNow you can programmatically force that event to raise whenever you want. And the framework will raise it when it needs to as well. So it all works fine.
Thanks Jon,
I tried your suggestion but I get an Error at RaiseEvent GetView() stating GetView doesn’t exist. I substituted Call for RaiseEvent and was able to run without a compile error but got a stack overflow when GetView was called.
I’m starting to lean toward the idea that GetView is used for initializing the control while giving it an NSView. There must be a different way to replace the view. Maybe killing the current view will force GetView to respond. Clearly, I’ve been poking around in the dark and haven’t read the docs yet. Last resort you know…
[quote=134307:@Bill Martini]Thanks Jon,
I tried your suggestion but I get an Error at RaiseEvent GetView() stating GetView doesn’t exist. I substituted Call for RaiseEvent and was able to run without a compile error but got a stack overflow when GetView was called.
I’m starting to lean toward the idea that GetView is used for initializing the control while giving it an NSView. There must be a different way to replace the view. Maybe killing the current view will force GetView to respond. Clearly, I’ve been poking around in the dark and haven’t read the docs yet. Last resort you know…[/quote]
I’m not sure. What control is this? Is this event a Xojo event or is it one specified by Apple? If it’s specified by Apple, I’m not sure if my method will work.
Since you have to use Call in front of it to get it to work, it’s obviously a function then. So you need to process a returned value.
If you are getting a stack overflow, it sounds like you get into an endless loop where the event is calling itself over and over. Make sure that calling the event doesn’t lead to it calling itself again.
But I use this way of having a method in a subclass raise an event all the time as a way of forcing events to raise when I want them to.
[quote=134307:@Bill Martini]I tried your suggestion but I get an Error at RaiseEvent GetView() stating GetView doesn’t exist. I substituted Call for RaiseEvent and was able to run without a compile error but got a stack overflow when GetView was called.
I’m starting to lean toward the idea that GetView is used for initializing the control while giving it an NSView. There must be a different way to replace the view. Maybe killing the current view will force GetView to respond. Clearly, I’ve been poking around in the dark and haven’t read the docs yet. Last resort you know…[/quote]
Triggering a built in event is simply not possible in Xojo. You cannot for instance trigger a keydown event. The approach suggested to you is to replace the original event by a handler method. But that may simply be impossible as well, if the event is fired upon circumstances specific to the internals of the control.
If you said exactly which control it is, it may help understand what is involved. For instance, Getview is used in some MBS classes…
What is it you are trying to achieve ? What does the GetView event does that you need to initiate ?
Ok, this is embarrassing
First, I’d like to thank everybody for trying to assist.
I’ve been trying to figure this whole thing out without reading the docs. I now know I’ve been asking for help to do something that can not be done and I was taking the wrong approach all along. I asked the wrong question…
To explain. I’m using an NSControl and an NSPathControl. The NSPathControl is the little widget used on Finder windows showing the path from the users home folder to a particular file or folder. Icons and folder names are displayed in a band.
The NSControl needs to have a view to display or it would be invisible in the app. It is pretty much like the RS Rect.Control class in that it provides a dimensional object that can send and receive events. The NSPathControl is an NSView which is placed into the NSControl as say, a button controls relation to the Rect.Control. The NSPathControl has it’s own properties and events.
In effect I was asking you for help to force an event in a Rect.Control to change a buttons caption. Which of course is nonsense! And it gets worse My whole problem was I was not retaining a reference to the NSPathControl that was put in the NSControl. I sat here earlier trying to rephrase the question when, I realized my mistake. With the reference I now can set the path as I need. Coding 101 mistake!
I’m going to go to the back of the class and sit with the rest of the dummies for a while…
My math teacher used to say that asking the question in the clearest ways is half the resolution 
This is simply not correct if the event is accessible in Xojo. You absolutely CAN trigger they key down event in your app.
Using a subclass you absolutely can trigger a built in event. So you subclass the class who’s event you want to trigger. Add the event into the subclass. Add a new event definition in the subclass to all the event to be handled in the control instance.
From any method then within that subclass, you can raise that event you have defined in the event definition.
[quote=134660:@Jon Ogden]This is simply not correct if the event is accessible in Xojo. You absolutely CAN trigger they key down event in your app.
Using a subclass you absolutely can trigger a built in event. So you subclass the class who’s event you want to trigger. Add the event into the subclass. Add a new event definition in the subclass to all the event to be handled in the control instance.
From any method then within that subclass, you can raise that event you have defined in the event definition.[/quote]
Wait. Creating an event and raising it is one thing.
Triggering a hardware event such as Keydown, is quite another thing. Could be handy to simulate keypunches, though.
When I say “built in”, I mean the event available in a control. To understand better what you describe, I dragged a TextField in the project, added a KeyDown() event definition, and dragged an instance over a window. When I compile, I get as expected
This property has the same name as an event. You must resolve this conflict
Event Keydown()
Of course, if I change to myKeydown the error goes away, but it does not trigger Keydown.
What I mean by “triggering a built in event” is for instance trigger the original TextField1.Keydown. I believe it is not possible, but would love to be wrong.
Maybe I did not quite understand, forgive me for being thick. Would you have any sample project to teach me ?
[quote=134678:@Michel Bujardet]Wait. Creating an event and raising it is one thing.
Triggering a hardware event such as Keydown, is quite another thing. Could be handy to simulate keypunches, though.
[/quote]
Yes, you can’t trigger an actual hardware event or an event in the underlying OS framework. But you can absolutely trigger an event in a Xojo control.
So in order to do this you must do these steps:
1.) Subclass the control.
2.) In the subclass, implement the event handler you wish to raise. So if it’s keydown, then implement the keydown event in the subclass. IN that event add the following code:
Return RaiseEvent KeyDown(Key)Now, add a new event defintion: KeyDown. Make it just like the event handler you just implemented.
Now, you can add a function to your subclass called KeyDown (A method/function can have the same name as the event). Then in that method, you use the code:
Return RaiseEvent KeyDown(Key)Now, you can call that method from any instance of the subclass and you can force the keydown event of the object to fire. You won’t get the actual keystroke entered in the text field. But you can simulate that well enough because if you raise that event outside a normal keystroke then you are only trying to simulate the event and you can easily fill in the key value via code anyhow.
[quote]
Of course, if I change to myKeydown the error goes away, but it does not trigger Keydown.
What I mean by “triggering a built in event” is for instance trigger the original TextField1.Keydown. I believe it is not possible, but would love to be wrong.
Maybe I did not quite understand, forgive me for being thick. Would you have any sample project to teach me ?[/quote]
I think your problem was that you did not first implement the KeyDown event handler in the subclass. That’s the first thing you must do.
Here’s a simple example project. Where I use a push button to raise the KeyDown event on a TextField control:
[quote=135302:@Jon Ogden]Yes, you can’t trigger an actual hardware event or an event in the underlying OS framework. But you can absolutely trigger an event in a Xojo control.
So in order to do this you must do these steps:
1.) Subclass the control.
2.) In the subclass, implement the event handler you wish to raise. So if it’s keydown, then implement the keydown event in the subclass. IN that event add the following code:
Return RaiseEvent KeyDown(Key)Now, add a new event defintion: KeyDown. Make it just like the event handler you just implemented.
Now, you can add a function to your subclass called KeyDown (A method/function can have the same name as the event). Then in that method, you use the code:
Return RaiseEvent KeyDown(Key)Now, you can call that method from any instance of the subclass and you can force the keydown event of the object to fire. You won’t get the actual keystroke entered in the text field. But you can simulate that well enough because if you raise that event outside a normal keystroke then you are only trying to simulate the event and you can easily fill in the key value via code anyhow.
I think your problem was that you did not first implement the KeyDown event handler in the subclass. That’s the first thing you must do.
Here’s a simple example project. Where I use a push button to raise the KeyDown event on a TextField control:
https://www.dropbox.com/s/solp7qx3wtek13d/RaiseEventExample.xojo_binary_project?dl=0[/quote]
Jon, I appreciate very much you shared this with a detailed example. Now I will know how to do something I thought was not possible.
Thank you so much 