Thanks for your reply..
> Not sure why you'd need to sink such an event in a class module
I made a class module which is using a set of controls (ListBox,
cmdButtons, etc..) to form a "generic-show-sort-and-pic" controls set.
This set of controls may appear on different forms. In other words,
the controls-set is generic, but not the form it is on.
Behind these controls are procedures needing sometimes to interact with
the form they are on. An obvious example is the "Close" button which
closes the form after some internal housekeeping. Another example is
the listbox "dblClick" event which needs to hide the form at some
point.
Since the forms properties and methods aren't all availiable in a class
module, this makes it hard to do without duplicating code.
On the other side, clicking on the form's "X" should execute the same
code as the cmdClose_click event. If the QueryClose event can only be
sinked in the form module while the cmdClose_Click is processed in the
class module, you need to either duplicate the code or find a
"creative" way to use the same code for both.
Hope this clarify why I want to put all related code in the class
module.
Sorry if this seems basic, but I'm used to Access where you can pass a
form object to a class module and all its properties, methods and
events are availiable to the class module as any other object..
I have a hard time understanding why it is not the same in Excel..
MS
Jon Peltier - 20 Feb 2007 03:29 GMT
To handle the close button, I put this code into all of my userform code
modules:
''================================================
Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
If CloseMode = vbFormControlMenu Then
Cancel = True
btnCancel_Click
End If
End Sub
''================================================
I don't worry too much about repeating this code in each module.
- Jon
-------
Jon Peltier, Microsoft Excel MVP
Tutorials and Custom Solutions
http://PeltierTech.com
_______
> Thanks for your reply..
>
[quoted text clipped - 29 lines]
>
> MS
Peter T - 20 Feb 2007 09:04 GMT
Seems you will have to adapt your Access form methods for Excel in view of
not all events are exposed outside the form module.
For your arrangement perhaps a slight modification to Jon's QueryClose
method
Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
If CloseMode = vbFormControlMenu Then
Cancel = True
theClass.btnCancel_Click
End If
End Sub
Where theClass is reference to the particular instance of the withevents
cancel button in say a collection or an array, and you have changed the
default
Private btnCancel_Click()
to
Public btnCancel_Click()
However the above does similar to the suggestion in my previous post, albeit
in a different way.
If you have complex code to manipulate form controls this might be done in a
code in a normal module. This code can reference the form in a number of
ways,
- a global reference to the form
- simply the form's name as the object reference
- a ref to the form passed as an argument
The normal code might also refer to a collection or array of withevents
class's to loop controls in those classes. The collection or array could be
stored as public in the form as a clean way of destroying the class's when
the form is closed or a ref to the form is destroyed.
FWIW I have code to manipulate the form and its controls in the form,
multiple withevents class's and in normal modules.
Regards,
Peter T
> Thanks for your reply..
>
[quoted text clipped - 31 lines]
>
> MS