FWIW, I only get one message box for each item using the class module code provided by @accesstos.
Not sure what he edited in his post after I had posted my last reply
FWIW, I only get one message box for each item using the class module code provided by @accesstos.
Not sure what he edited in his post after I had posted my last reply
Hi Colin,
I will re-visit this issue in a day or so.
Bill
Hi Colin,
Nothing changed in code by editing. It’s exactly the same as the code in your sample.
I just correct the word cldLabel to clsLabel in the text of the message. I am sorry, I had to mention it.
Thanks a lot for the reference to my suggestion and for the demonstration as well.
As far as I know, there is no better way than using a Class for cases like that. The other ways are poor alternatives that demands a lot of code and hard maintenance as the project grows up. With a Class, a unique piece of code is using for unknown count of controls at run time and the possibly changes in the future are taking place in this unique piece of code. Take a look in attachment the second version of your form2 and some additional features of the 'advanced' clsLabel. Imagine how many lines of code demands to achieve this functionality using the 'alternative' programming ways.
@Micron
I have no idea what are you talking about. In my suggested code there is no "Last_Name_Label" to appear in any message box. Obviously you checked someone else code.
This is not mine:
But, seems like the part "_Label" is missing from the second reference in the snippet above.Code:Me.Last_Name_Label.OnClick = "=GetCtlName(""" & Me.Last_Name.Name & """)"
Cheers,
John
Really?? Last_Name is the only label on my test form that can take a click event. It's your code - do you not recognize when it returns the name of a label that might not be on your test form?In my suggested code there is no "Last_Name_Label" to appear in any message box. Obviously you checked someone else code.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.
Hmm, now I got you.
Probably, you use the clsLabel while you didn't remove the event procedure of the label in the form's code module. The first message box comes from the form's code module and the second from the class module.
Sorry. It was not clear enough to me from the beginning what you checked and where. I thought you were referring to the Colin's sample.
I thought that there might be additional events going on so I checked that thoroughly (I think). Anything in the events that doesn't apply to your code is for some other reason and should not have any bearing on this AFAIK:
Form Load:
Form Close:Code:Private Sub Form_Load() Dim lngEntry As Long, strExp As String lngEntry = 1 strExp = "=DLookup(""[first name]"",""[attendance log]"",""[entry]=" & lngEntry & """)" 'Debug.Print strExp Me.Text3.ControlSource = strExp Dim L As clsLabel Dim C As Control 'Keep an instance of the clsLabel for each label in the form. Set mcolLabels = New Collection For Each C In Me.Controls If TypeName(C) = "Label" Then C.OnClick = "[Event Procedure]" C.ControlTipText = "Click on " & C.Name Set L = New clsLabel Set L.Target = C mcolLabels.Add L, C.Name End If Next C End Sub
Form Module Level:Code:Private Sub Form_Close() Set mcolLabels = Nothing End Sub
clsLabel:Option Compare Database
Option Explicit
Private mcolLabels As Collection
What I find 'interesting' about your class is that the event is assigned to any label, regardless of whether or not a click event is applicable. As you probably know, attached labels have no events, so I'm not sure why that does not raise some sort of error.Code:Option Compare Database Option Explicit Public WithEvents Target As Access.Label Private Sub Target_Click() 'You may code this proc as you need. MsgBox Me.Target.Caption, , Me.Target.Name End Sub
I have compiled, closed and re-opened db several times without any difference. No matter, I guess. Perhaps it is a 'ghost' effect caused by some prior attempt I made (i.e. the other examples I posted where I used VBE methods).
In the end, I personally don't see the value in anything I researched, tried, or a class for this "issue" when I could avoid the whole problem by using a textbox that looks like a label instead of a label (and gain access to several properties and methods). That is what I did in the past, and that's the approach I would take in the future. Still, it was an interesting exercise.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.
Hi John
Ah yes. I'd forgotten that I changed the 'cld' to 'cls' when I copied your code.
I agree that using the class module requires less code/maintenance, especially if you have a lot of controls.
I much prefer using another label to display such info rather than having to dismiss a message box.
I'm on a Windows tablet now but will look at your modified example properly later
Hi Micron,
I repeated your ‘issue’ (double message box) by adding a normal event procedure for a label in form’s module. So, somewhere in your form lives the normal event(s). Try to re-create and re-move that event(s) or disable the class code to see what happen.
Note that an attached label inherits the events of its linked control. That’s why the Label’s events doesn’t be exposed but there are still members of the Label object. So, you may refer to them without any error. By attaching a Label to a TextBox, the OnClick event of the TextBox becomes the OnClick event of the Label as well. Therefore, if you need to code the events of an attached label, you have to code the events of Label.Parent object (the Parent of unattached label is the Form). In case of the clsLabel, that could be achieved with code like below:
clsLabel code module:
Also, that simplifies the code in Form_Load procedure:Code: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]" End If With mTarget .OnClick = "[Event Procedure]" .ControlTipText = "Click on " & .Name End With End If End Property Private Sub mParent_Click() Call mTarget_Click End Sub Private Sub mTarget_Click() 'You may code this proc as you need. MsgBox Me.Target.Caption, , Me.Target.Name End Sub
As you can see, you may have multiple same events for a specific control. In some cases, this could be very useful.Code:'[...] For Each C In Me.Controls If TypeName(C) = "Label" Then Set L = New clsLabel Set L.Target = C mcolLabels.Add L, C.Name End If Next C
About the personal programming style of each of us, of course I have no something to say. Anyone is free to choose his own.
Cheers,
John
You were half right. All the code I posted is what is written for that form BUT I had commented out a mousedown event from the code and even though I had saved, compiled, closed/reopened several times it was still running. The event was still in the property sheet, but no 'active' code existed for it. Once I removed the property it stopped the 2nd msgbox. The only other thing I could have done was to decompile, I guess. Odd that the code would still run when it was completely commented out.So, somewhere in your form lives the normal event(s)
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.