Wrapping controls WithEvents in classes

Are you actually following all this stuff?
John,
I communicated with you in late 2022 when you were working with version 7...9(when it had ~60 pages). And before your PAUG sessions. I have followed you on AccessD for years. Having been retired for 16+ years I don't have projects and was never a developer as such. I have always been in awe of your approach to classes and events. I was following "some of this stuff", but without projects it is difficult to get and stay focused -- so NO not really, but I know your enthusiasm and hope that many readers will have that "classes light-bulb" turn on for them.
Glad things are progressing, and I see you are now retired.
 
@Gasman, you didn't say whether you want me to just stop adding to the book.

And if I am to continue, then it would be helpful if you would look at the demo database for the AccessPG, and tell me what of the demos, looks and feels most impressive or useful. What would peak someone's interest. IE what to work on adding.

I have a new blog post with the link to the YouTube videos I did for the Access Pacific user's group, and included in that post is a link to the demo I did for them.
 
Well I think the book is essential for anyone trying to learn from your expertise.
Send me a link for that AccessPG and I will take a look.

ATM I am having to compare my Demo1 db with your db and the book, and finding these discrepancies.
 
The XXX being the control type isn't always possible because a class can wrap several controls if the class deals with a system.

As for the two forms not found, this demo (see the demo out in the demo database) demonstrates the main form creating the date range, then raising an event which can be sunk by a different form. Or two different forms in this case.

It feels like you are resisting looking at the demo db. One of the things I feel is important is to show the reader actual examples of events (as I use them) at work in the real world. OK the demo world. The demo database allows me to get some things demonstrated which are not (yet) in the book at all.
It feels like you are resisting looking at the demo db.
Not at all. I am trying to work through the pdf file and understand the code as it is created.
I *thought* the whole idea was to create your own Demo1 DB and slowly apply the code as it is explained and created?

I looked into your DB to find the missing cDateRange() function?
 
Not at all. I am trying to work through the pdf file and understand the code as it is created.
I *thought* the whole idea was to create your own Demo1 DB and slowly apply the code as it is explained and created?

I looked into your DB to find the missing cDateRange() function?
And of course the whole idea is to actually write the code and understand it. However I also created the demodb for a reason as well.
 
clsCtlCmd added to the database, the book, the pdf. All three pushed to GitHub.

Back in the day (when I worked Access for a living) I had small command buttons to do stuff. Close, save, MoveNext, Move Previous, Move last etc. I would cut and paste those into a new form, or even use a "template" form with all those buttons already in place. clsCtlCmd Handles all of those command buttons.

In the demo database EventDrivenProgrammingDemoDB.accdb I have a demo frmTestEditField. Since that is the only form that I have created a test data table for, I created examples of all these command buttons in that form.

1748352388526.png
 
Last edited:
BTW this form also demonstrates one (Event Driven) way to do updates to any field where the form needs a bunch of small text boxes but the field being edited may have more data than can be easily edited in a small text box. If you dbl-click in any of the edit fld 1,2 or 3, a new form will open. This form is one big text control with the contents of the field you just dbl-clicked on. Edit away, close the form, and the new edits will be back in the original field.

1748355311661.png
 
Last edited:
The event driven way I used is to set up a message class, clsMsgPD. See my blog for that. Or the demo database.

In the dblClick in frmTestEditField some text box (named correctly) ... txtDE then XXXXX for the rest of the text box name.

I open frmLngDataEntry, then call a function in clsMsgPD.Send to pass a pointer to the text box over to frmLngDataEntry.

Over in frmLngDataEntry I sink events from the message class. Grab the pointer to the text box passed in. Copy the contents into the big text box for editing.

Once the user finishes editing to their hearts content, they close the form

As the form closes it moves the new edited data back into the text box originally passed in and closes the form.

Why go through all this? Because I can now add this behavior to clsCtlTxt. clsCtlText now can sink the dbl_Click event for any text box, anywhere, in any form. If the text box is named to a convention, it can call clsMsgPD.Send to pass the text control off. Any form anywhere can use this behavior of clsTxt just by naming a text box with that naming convention.

This is an event driven way. The point is to make my user interface consistent everywhere, in every form. Want a big text editing box to edit the data? You got it.

It sounds a bit complex to the Event Driven novice but for me it was a half hour development, just because it really is simple. Event Driven programming rocks!

'
'Double click will open an edit form for long text entry
'
Private Sub mctlTxt_DblClick(Cancel As Integer)
On Error GoTo mctlTxt_DblClick_Error
'
'Set up a naming convention for this text control wrapper to recognize
'The text box name has to start with txtDE
'for "text data entry"
'
'This allows the developer to create a user interface to
'edit long text fields easily and consistently
'
If Left$(mctlTxt.Name, 5) = "txtDE" Then
'
'If it starts with that "txtDE" then
'Open the data entry form
'
DoCmd.OpenForm "frmLongDataEntry"
'
'Send a message to the form, passing in this text box control
'Pass in "frmDataEntry" as the to: in the message
'and mctlTxt in the Msg:
'
clsMsgPD.Send "", "frmLongDataEntry", "", mctlTxt
'
End If


Exit_mctlTxt_DblClick:
On Error GoTo 0
Exit Sub
 
@Gasman. My apologies but I just remembered that I need a name property for the classes. I am going back in and retrofitting the classes already written and "published". Access uses .Name for their objects. Sadly I have to deal with my class itself, and Me.name isn't a thing. Me being MY class. So I have to pick something to pass back for the name. Where the class wraps a control I have decided to pass back ctl.name

ClsFrm:
Property Get pFrmName() As String
pFrmName = mFrm.Name
End Property

clsCtlCbo:
Property Get pCtlName() As String
pCtlName = mCtlCbo.Name
End Property

clsCtlRecSelSimple:
Property Get pCtlName() As String
pCtlName = mCtlCbo.Name
End Property

clsCtlTxt:
Property Get pCtlName() As String
pCtlName = mctlTxt.Name
End Property

clsCtlCmd:
Property Get pCtlName() As String
pCtlName = mCtlCmd.Name
End Property
 
@Gasman I just realized what one of your frustrations is, when I change the book you have to change your database you have been writing. I am trying to clean up the Demodb to make it consistent in naming.

In half the places I was just doing something like dim mTxt as text box.
In other places I would do dim mCtlCbo as ComboBox.

I REALLY want to be consistent if possible and I REALLY want to use the mCtlXXX in the variable names.

In this case you need to find and replaced mcbo with mCtlCbo for sure. I ended up with something like 90 changes both in the database and in the book.

But that means that

Private Sub mCbo_LostFocus() turns into
Private Sub mCtlCbo_LostFocus()

So in penitence, I will submit myself in the public square (No, Not X, previously known as Twitter) for a flogging. I would allow you to do the flogging but I'm a little worried I would not survive.

In the future I will immediately discuss the change and what I did as far as the find and replace, both in my demodb and in the book so You can fix your db up to match.
 

Users who are viewing this thread

Back
Top Bottom