OnKeyPress = "=somefunction()" how function can receive the key pressed?
The event procedure for OnKeyPress starts:
Private Sub xxx_KeyPress(KeyAscii As Integer).
However when I change it to a function call:
OnKeyPress = "=somefunction()"
there does not seem to be a way to send the KeyAscii value to the function. Is there some way for the function to get the key pressed?
Why do I want this? To avoid having to write lots of keypress event subroutines. I have code that scans a form when it opens for certain comboboxes, and sets them up in certain ways. The only place I'm stuck is handling keypress.
Private Sub xxx_KeyPress(KeyAscii As Integer).
However when I change it to a function call:
OnKeyPress = "=somefunction()"
there does not seem to be a way to send the KeyAscii value to the function. Is there some way for the function to get the key pressed?
Why do I want this? To avoid having to write lots of keypress event subroutines. I have code that scans a form when it opens for certain comboboxes, and sets them up in certain ways. The only place I'm stuck is handling keypress.
Is this what umean?
in form text box?
Private Sub FIELDNAME_KeyPress(KeyAsci
testfunction (KeyAscii)
End Sub
in modules
Public Function testfunction(key As Integer)
MsgBox key
End Function
don
in form text box?
Private Sub FIELDNAME_KeyPress(KeyAsci
testfunction (KeyAscii)
End Sub
in modules
Public Function testfunction(key As Integer)
MsgBox key
End Function
don
ASKER
donaldmaloney: no. I want to avoid writing event procedures, and use a function instead.
LukeChung-FMS: I want my combo box to respond to ctrl-e. There is currently no action triggered by ctrl-e in combo boxes so I think I am safe.
Of course if I could intercept right click then I'd have no problem (I'd use that instead). But the only way to do that (again) is with a mouse event procedure, which I choose to avoid.
LukeChung-FMS: I want my combo box to respond to ctrl-e. There is currently no action triggered by ctrl-e in combo boxes so I think I am safe.
Of course if I could intercept right click then I'd have no problem (I'd use that instead). But the only way to do that (again) is with a mouse event procedure, which I choose to avoid.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yep. That's the approach I took. Nice to have it confirmed. Let me expound.
I wrote a Sub OpenForm which amongst other things calls docmd.openform, and a class (FormHelper) which contains code similar to what you posted.
User requests for forms are sent to OpenForm.
OpenForm checks to see if the form has an instance of the FormHelper class, and if not, writes "Dim Helper as New FormHelper" to the declarations of the form's module. It also ensures that the form's OnKeyUp = "[event procedure]" and keypreview = True.
It loops thru the form's controls looking for those of type combobox that have a tag. The tag contains directives used to set the combo box properties.
FormHelper watches for KeyUp events, examines the ActiveControl.tag, and acts as needed.
FWIW OpenForm also checks to see if the form has a Sub reinit(), and if not, writes the code for it to the form's module.
Subsequently it calls this method, passing up to 6 arguments (which are at the end of the argument list for OpenForm).
This totally overcomes the limitations of openargs.
The place I ran into trouble was that subforms did not benefit from this passage thru openform, as they are opened automatically. So I lacked a way to apply the above technology to the subforms. So I was looking to function call instead of eventy procedure to help.
I now work around that by having openform visit the subforms and update them as well.
I sure do miss the ease I had in FoxPro of just subclassing combobox. Sigh.
I wrote a Sub OpenForm which amongst other things calls docmd.openform, and a class (FormHelper) which contains code similar to what you posted.
User requests for forms are sent to OpenForm.
OpenForm checks to see if the form has an instance of the FormHelper class, and if not, writes "Dim Helper as New FormHelper" to the declarations of the form's module. It also ensures that the form's OnKeyUp = "[event procedure]" and keypreview = True.
It loops thru the form's controls looking for those of type combobox that have a tag. The tag contains directives used to set the combo box properties.
FormHelper watches for KeyUp events, examines the ActiveControl.tag, and acts as needed.
FWIW OpenForm also checks to see if the form has a Sub reinit(), and if not, writes the code for it to the form's module.
Subsequently it calls this method, passing up to 6 arguments (which are at the end of the argument list for OpenForm).
This totally overcomes the limitations of openargs.
The place I ran into trouble was that subforms did not benefit from this passage thru openform, as they are opened automatically. So I lacked a way to apply the above technology to the subforms. So I was looking to function call instead of eventy procedure to help.
I now work around that by having openform visit the subforms and update them as well.
I sure do miss the ease I had in FoxPro of just subclassing combobox. Sigh.
So you're using Keyup events in your class - and hence are free to have an "[Event Procedure]" there?
So no need for a form object?
Or do you do so to keep it simple (i.e. watching for the keyup on that form - rather than any of the controls.)
Another option would be to have a couple of classes (parent and child) where the child holds a combo object and watches for the events of your very particular controls - and the parent maintains a collection of those classes.
If you were adding controls then I suppose whether a form was a main or subform - then if it added the controls to the class itself it wouldn't matter.
But it's just semantics now - you're up and running :-)
Not that I've ever used Foxpro (or are ever likely to now) - but how does it subclass combos in a widespread way?
i.e. All combos? You could subclass the entire combo type class? (Rather than an individual control at a time?)
So no need for a form object?
Or do you do so to keep it simple (i.e. watching for the keyup on that form - rather than any of the controls.)
Another option would be to have a couple of classes (parent and child) where the child holds a combo object and watches for the events of your very particular controls - and the parent maintains a collection of those classes.
If you were adding controls then I suppose whether a form was a main or subform - then if it added the controls to the class itself it wouldn't matter.
But it's just semantics now - you're up and running :-)
Not that I've ever used Foxpro (or are ever likely to now) - but how does it subclass combos in a widespread way?
i.e. All combos? You could subclass the entire combo type class? (Rather than an individual control at a time?)
ASKER
In FoxPro one may:
DEFINE CLASS xxx AS combobox
borderstyle = 1
backcolor = 999
PROCEDURE KeyPress(nKeyCode, nShiftAltCtrl)
* code to act on KeyPress
ENDPROC
ENDDEFINE
Then add any number of controls to forms based on this class.
One may then define other classes based on combobox, or on xxx (subclassing).
DEFINE CLASS yyy AS xxx
caption = "Foo"
backcolor = 9989
PROCEDURE LostFocus()
* code to act on LostFocus
ENDPROC
ENDDEFINE
yyy "inherits" backstyle and KeyPress from xxx, creates some new things, and "overrides backcolor.
These definitions can also be made using a Visual Class Designer. Just like laying out a form! One may then drag-drop the visual class onto a form to create an instance of the class (control or whatever).
DEFINE CLASS xxx AS combobox
borderstyle = 1
backcolor = 999
PROCEDURE KeyPress(nKeyCode, nShiftAltCtrl)
* code to act on KeyPress
ENDPROC
ENDDEFINE
Then add any number of controls to forms based on this class.
One may then define other classes based on combobox, or on xxx (subclassing).
DEFINE CLASS yyy AS xxx
caption = "Foo"
backcolor = 9989
PROCEDURE LostFocus()
* code to act on LostFocus
ENDPROC
ENDDEFINE
yyy "inherits" backstyle and KeyPress from xxx, creates some new things, and "overrides backcolor.
These definitions can also be made using a Visual Class Designer. Just like laying out a form! One may then drag-drop the visual class onto a form to create an instance of the class (control or whatever).
Unfortunately, if you want to handle the keystrokes, you're going to need to use the Event Procedure, and pass that to your function. Good luck.
Luke