Common Sub to test use of Ctrl key with Screen.ActiveControl

[GraeagleBill]

I didn't notice initially that Micron had prefixed his test code with an "m", so my MouseDown event wasn't recognized.

[accesstos]

Found the problem. Didn't notice the "m" on the "Target".
Attachment 46500

Very nice progression!

In the meanwhile, I made a picture that presents the Class module mechanism.


As you can see, you have to code only one module for an unknown count of objects (Labels in this case). That technic reduce the code of VBA project dramatically, gives the ability for advanced programming and makes the maintenance a very easy work.
Definitely, be worth the effort to understand it and I'd heartily recommend it.

I hope it helps.

Cheers,
John

[GraeagleBill]

Thanks John, I wish I'd had your diagram back when I first tackled the common routine for labels. I will definitely recode a section of that form to make use of the class module, as well as the current OP dealing with MouseDown events that Micron labored over on my behalf.

BTW, what's the skinny on "mTarget" versus "Target"?

Thanks again,
Bill
(PS) And thanks also to Micron, what an exercise!

[Micron]

BTW, what's the skinny on "mTarget" versus "Target"?

When I couldn't get it to work and it seemed that it should (recall, I had OnMouseDown for the event to be called as well as the name of the event property in the class) I downloaded the db that accesstos had posted after the code solution that was posted. I figured that must be the issue but as we know, it was not. When I finally recalled that the event name is MouseDown it worked. So it seems you ended up mashing the two syntaxes together. In fact, the posted code had one syntax, the posted db the other. If there is any more significance to the difference, accesstos will probably let us know but I suspect there is none. Likely all that matters is consistency. In other words, you can't give a class a property or method and expect the same method or property to work if you use different names when invoking it.

[GraeagleBill]

I surmised as much, given the thoughts that wondered through this old brain of mine when I discovered why OnClick was working and OnMouseDown wasn't.

Is it getting a little bit chilly up your way yet?

[Micron]

Yesterday was quite nice (relative to Alaska I suppose). Today not so much. Wondering if we've already had our Indian Summer (is it OK to use that term anymore or has that been cancelled too?).

[GraeagleBill]

I'm not too worried about any of the Woke nonsense, so you can call it anything you'd like

I thought I'd cleared the last hurdle on the OP. Here's my revised Class code:

Option Compare Database
Option Explicit
Dim bolIgnore As Boolean


Public WithEvents Target As Access.Label




Private Sub Target_MouseDown(Button As Integer, Shift As Integer, x As Single, y As Single)
    If Shift = acCtrlMask Then
        Call lblCtrlClick(Me.Target.Name)
    Else
        Call lblClick(Me.Target.Name)
    End If
End Sub

Both lblClick and lblCtrlClick are Public in my form, but I get the function not found message. I either need to get back into the form module to process the event.

[Micron]

You clipped your problem details? I know the comment is within the code (might want to edit that) but it seems truncated.
Why would you have a mousedown trying to call a click sub on a form?

You do get into some rather complicated scenarios, yes? I expect that you think Me is the name of the form. Did you pause code and ask what Me.Target.Name is? That should tell you why it won't work. If you must, you will have to invoke the syntax for calling form code from a standard module (specifically a class in this case, I guess). That is

Form_FormNameHere.ControlNameHerel_EventNameHere

or

Form_Form3.Last_Name_Label_Click

I fear that having to provide the form name is going to be a problem.

EDIT -Forgot to suggest a hack - referring to a public function in a standard module might be an option. This actually worked

Function Last_Name_Label_Click()
MsgBox "dog"
End Function

Don't forget to reload your form when you are editing the class. I believe you must instantiate it again for the changes to take effect.
If you follow this last suggestion, I'd caution about doing such things. They might work today, but down the road, some update might not like it. Might have worked for me because I created it as a function and not like it is event code that resides on a form.

[GraeagleBill]

Why would you have a mousedown trying to call a click sub on a form?

Two different functionalities, action1 on a simple click and action2 if the Ctrl key was pressed at the same time.

Did you pause code and ask what Me.Target.Name is?

Yes. Hummm, I didn't really even think about the "Me" in Me.Target.Name.

I have to go out, I finish absorbing all of the in the morning.

[Micron]

action1 on a simple click and action2 if the Ctrl key was pressed at the same time.

Sorry, I'm not getting it. What's wrong with something like

Private Sub mTarget_MouseDown(Button As Integer, Shift As Integer, x As Single, y As Single)

Select Case Shift
  Case 0 'no keypress
    do this
  Case 1 'shift key pressed
    do this instead
  Case 2 ' ctrl key pressed
    do this
  Case 3 'alt key pressed
   and so on
End Select

Mousedown happens before click IIRC, and I see no need for both. 

You know how it is - at our age, not hard to miss the point! Could be me...
End Sub

[Micron]

just tried this (rem'd out the other calls for now)

Private Sub mTarget_MouseDown(Button As Integer, Shift As Integer, x As Single, y As Single)
   Select Case Shift
      Case 0
         MsgBox "no keypress"
      Case 1
         MsgBox "shift key"
      Case 2
         MsgBox "ctrl key"
      Case 3
         MsgBox "shift+ctrl"
      Case 4
         MsgBox "alt"
      Case 5
         MsgBox "shift+alt"
      Case 6
         MsgBox "ctrl+alt"
      Case 7
         MsgBox "shift+alt+ctrl"
      Case Else
         MsgBox Shift
End Select
         
   'MsgBox Me.Target.Name & " Shift: " & Shift
   'Form_Form3.Last_Name_Label_Click
   'Last_Name_Label_Click
   
End Sub

Obviously you would not settle for msgbox functions; you'd code for whatever else it is you're trying to do. That could even be to call another procedure and pass the shift value to it so that you don't end up with a whole lot of code that probably doesn't really belong in your class, because it will become too specific. You would not be able to use the class for capturing actions on other forms.

[accesstos]

Thanks John, I wish I'd had your diagram back when I first tackled the common routine for labels. I will definitely recode a section of that form to make use of the class module, as well as the current OP dealing with MouseDown events that Micron labored over on my behalf.

You are welcome Bill,
I have been watching you for a long time now that you are involved with common procedures of many objects of a form. Class modules, in such cases, are the ideal solution. That is why I insist on it.

BTW, what's the skinny on "mTarget" versus "Target"?

In the first case of the suggested class, the Target is a public variable in module level. So, it becomes a public member of the clsLabel. In this case, Me.Target points to this variable directly and the outer code (in Form's module) has direct access to the Label variable of the class.



In the second case, I used a Property Set/Get procedure for the public member Target. So, in this case, the mTarget is a private variable in module level. Now, Me.Target points to the Property Get() procedure, and the user of the class doesn't have direct access to the mTarget. Thus, the outer code, doesn't care for the type of the Target member of the clsLabel (Label or TextBox).



When you tried the Micron's snippets, you used the event procedure(s) of the second case with the variable of the first. The names of the event methods of a local variable, always begins with the name of the variable.

I hope that I was able to make the Class programming a little a bit clearer.

(PS) And thanks also to Micron, what an exercise!

Indeed, seems that Micron has been convinced with the benefits of the class modules and seems that he gets a kick out of checking them.
Of corse, we have to remember that that approach has kept alive thanks to Cοlin's interference. A great thanks from me to both.

Cheers,
John

[accesstos]

Both lblClick and lblCtrlClick are Public in my form

In this case, you have to call that methods within the Parent of the Target, as seems below:

Call Me.Target.Parent.lblCtrlClick(Me.Target.Name)

Of corse, you can put that methods in the clsLabel and make them part of the class and available for any form that uses the clsLabel.

For now, give a try to this code for the clsLabel that manage attached labels too:

Option Compare Database
Option Explicit

Private WithEvents mTarget As Access.Label
Private WithEvents mParent As Access.TextBox

Property Get Target() As Access.Label
    Set Target = mTarget
End Property

Property Set Target(lbl As Access.Label)
    Set mTarget = lbl
    If mTarget Is Nothing Then
        Set mParent = Nothing
    Else
        If TypeOf lbl.Parent Is TextBox Then
            'In this case, use the events of linked TextBox
            Set mParent = lbl.Parent
            mParent.OnClick = "[Event Procedure]"
            mParent.OnMouseDown = "[Event Procedure]"
        End If
        With mTarget
            .OnClick = "[Event Procedure]"
            .OnMouseDown = "[Event Procedure]"
            .ControlTipText = "Click on " & .Name
        End With
    End If
End Property

Private Sub mParent_Click()
    Call mTarget_Click
End Sub

Private Sub mParent_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
    Call mTarget_MouseDown(Button, Shift, X, Y)
End Sub

Private Sub mTarget_Click()
    'You may code this proc as you need.
    'MsgBox Me.Target.Caption, , Me.Target.Name
End Sub

Private Sub mTarget_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
    With Me.Target
        If TypeOf .Parent Is Form Then    'Is unattached label.
            'Call the public method(s) of its Parent(the form).
            If Shift = acCtrlMask Then
                Call Me.Target.Parent.lblCtrlClick(Me.Target.Name)
            Else
                Call Me.Target.Parent.lblClick(Me.Target.Name)
            End If
        Else
            'Is attached label.
            'Call the public method(s) of its Parent.Parent(the Parent of TextBox etc).
            If Shift = acCtrlMask Then
                Call Me.Target.Parent.Parent.lblCtrlClick(Me.Target.Name)
            Else
                Call Me.Target.Parent.Parent.lblClick(Me.Target.Name)
            End If
        End If
    End With
End Sub

Leave the code in Form as it is.

[GraeagleBill]

lot of code that probably doesn't really belong in your class, because it will become too specific.

Point taken. As I venture into my first exposure to class code and methods, for now I just need to get things to work. John has flooded my old brain with a lot of new stuff, one has to move cautiously as these nuances are explored, lest one shoots a hole in one's foot

[GraeagleBill]

Call Me.Target.Parent.lblCtrlClick(Me.Target.Name)

What a wealth of information and help. For now, I'll pass the work to be done to the Target.Parent, but as time allows I'll return to

give a try to this code for the clsLabel that manage attached labels too

. I have a boatload of HELP text to update for this app and the primary user needs all this before Christmas. I've bookmarked the URL of this thread so I can revisit the discussion moving forward.

Thanks John, between your help and Micron's persistent dedication to the OP plus the lingering attention given by Colin with the somewhat related OP's elsewhere, I might just end up with some new smarts I hope those that have followed this thread have gained as much as I have, thanks again to all.
Bill