Wrapping controls WithEvents in classes

I think I did exactly that. Maybe I didn't push the latest version of the book (pdf) to GitHub. As you might imagine I don't download the version from GitHub, though I guess I should.

Can you spell out what the conflicting instruction is? I am paging back and forth between the book in LibreOffice, the PDF and the database in that class. I guess I am overlooking something because they look identical to me.
 
Last edited:
I have downloaded the latest pdf and db.
In the pdf on page 51, I have confliicting instructions?

I can guess which it should be, but it is still conflicting?
Also we seem to have different naming conventions for Init?
We have Init, mInit and fInit. fInit does not exist?

.Name will not compile as no with?, you need to use Ctl.Name.

I think it would be easier if you took code from the DB that does compile and put back into the PDF?

View attachment 119933
As I mentioned somewhere I went through and cleaned up my naming conventions. I try to use mXXX as a module level variable in classes and modules, but fXXX in the header of forms for the variables there. I went through and did a find and replace both in the database and the book to make those changes and get them to match between the book and the database.

I know this can be confusing but I have to be able to do this kind of thing when we find such inconsistencies. And when I make changes I try really hard to export the book to pdf and push it to GitHub, then push the db to GitHub. Which is why we need to be working against the same exact thing. In general I don't work out of the pdf, I work out of the LibreOffice document. To make matters even more confusing (for me), the PDF and LibreOffice look very similar. So when I do open the pdf I find myself trying to edit it!:oops:
 
I just exported the doc to pdf and pushed it to GitHub.
I just pushed the db to GitHub.
 
I think I did exactly that. Maybe I didn't push the latest versiomn of the book (pdf) to GitHub. As you might imagine I don't download the version from github, though I guess I should.

Can you spell out what the conflicting instruction is? I am paging back and forth between the book in LibreOffice, the PDF and the database in that class. I guess I am overlooking something because they look identical to me.
You say you need to change the code for actextbox, but it is actually the combobox?
Now I spotted that, but perhaps a good few would not? Then there was the .Name error, so that could never have come from a compiled dB code?

TBH I know how hard this is. I created a manual for one of my systems when I was working, and had to walk through the system, step by step, and then write the words and add pictures.

And I was just documenting the interface. :)
 
Last edited:
You say you need to change the code for actextbox, but it is actually the combobox?
Now I spotted that, but perhaps a good few would not? Then there was the .Name error, so that could never have come from a compiled dB code?

TBH I know how hard this is. I created a manual for one of my systems when I was working, and had to walk through the system, step by step, and then write the words and add pictures.

And I was documenting the interface. :)
can you give me actual wrong text that I can use Find on?

OK I found the thing about acTextBox...
Now what is the .Name error?

And again Millones de Gracias for doing this @Gasman .
 
Just below the actextbox error. See pic in post #83
 
I have downloaded the latest pdf and db.
In the pdf on page 51, I have confliicting instructions?

I can guess which it should be, but it is still conflicting?
Also we seem to have different naming conventions for Init?
We have Init, mInit and fInit. fInit does not exist?

.Name will not compile as no with?, you need to use Ctl.Name.

I think it would be easier if you took code from the DB that does compile and put back into the PDF?

View attachment 119933
...We have Init, mInit and fInit. fInit does not exist?

.Init( should not exist anywhere. OK I have searched for init( and found a ton of them in the book. I replaced them all with fInit( meaning (F)unctionInit. In the book.

Holy cannoli was that a pita.
 
OK, I know this is what you do not want to hear, but I think you need to try my approach, that I used for a user manual.
Create your code, make sure it works, then pass it on to the pdf file, just as you would, if you were starting from scratch.

The reason I say this, is your latest changes, have now affected what I had already added to the Demo1 DB?
So Now I have to compare what has changed from what I have already copied into that Demo1 DB?

So I would ask you step back and consider how to create this pdf, that explains how to create your classes?
To me that would be from your step 1 on how you normally work.
Ignore the fact that you already have those classes, but create a pdf with them, and a DB just as I am trying to do, and see what compiles.

You would have to pretend that you do not know classes that well, I know, but think like the audience you are trying to attract.

That way, for the most part, except for syntax/grammitical errors, the pdf should reflect the DB.?

Of course, people could just use the DB, but then never learn about classes, which I do not think is your reason for the book?

I have used @MajP 's classes in my db without having to understand them too much, but if I needed to enhance them, then I would need to use your book, or someone else's.

Let me know your thoughts on this please.
 
OK, I know this is what you do not want to hear, but I think you need to try my approach, that I used for a user manual.
Create your code, make sure it works, then pass it on to the pdf file, just as you would, if you were starting from scratch.

The reason I say this, is your latest changes, have now affected what I had already added to the Demo1 DB?
So Now I have to compare what has changed from what I have already copied into that Demo1 DB?

So I would ask you step back and consider how to create this pdf, that explains how to create your classes?
To me that would be from your step 1 on how you normally work.
Ignore the fact that you already have those classes, but create a pdf with them, and a DB just as I am trying to do, and see what compiles.

You would have to pretend that you do not know classes that well, I know, but think like the audience you are trying to attract.

That way, for the most part, except for syntax/grammitical errors, the pdf should reflect the DB.?

Of course, people could just use the DB, but then never learn about classes, which I do not think is your reason for the book?

I have used @MajP 's classes in my db without having to understand them too much, but if I needed to enhance them, then I would need to use your book, or someone else's.

Let me know your thoughts on this please.
@Gasman, let's be clear, I want critiques as well as criticism. You do a great job of keeping "personal" out of your criticisms.

That said, I do exactly what you are discussing, write the code, get it working, then paste it into the book. Then you come along and find issues which I fix in the database, get working then... mostly but not always manage to get back out into the book.

The other thing to know is that I have a framework with all of these things in there. But... they are waaaaaaay to complex to just cut and paste into the book. The first one would drive every single reader away, not to mention that I couldn't even explain it in book format. So I am stuck with either bring the thing into the demo db and starting to prune, or rewriting it from scratch using the concepts.

I know this sounds like one big excuse but this is just my reality. I spent 5 years writing my framework inside of a functioning FE database, then moving the classes out to a library. Moving on to the next piece. As such my old code is old, and to some extent creaky of course. I developed my ideas over that 5 years and more before I even learned classes / events in access.

My objective now is to write about the concepts. Why am I doing this thing? How am I doing this thing. How do I expand this thing as I come up with new ideas.

And you (and I) my dear friend are stuck in that no man's land trying to get a rewrite working as a book. Teaching principals as well as actual working code.

>>>Ignore the fact that you already have those classes, but create a pdf with them, and a DB just as I am trying to do, and see what compiles.

I actually did this before you volunteered. I did that exact thing. I wrote it in the db, then I pasted it into the book, Then I started reading and cutting the code back out and putting it into a brand new database. And I found and fixed a ton. But... well... You came along and "volunteered" to do that for me, which freed me up to use you as the wonderful resource you are instead of doing everything by myself. Additionally I decided half way through that I really needed to standardize the format of the sections so that the book itself looked and felt consistent.

And in the end, you and I are creating a "finished" product such that the eventual reader will not run into all the issues that you are. Finally, I implore you, do not give up on this. I have had many people say that would do what you are doing but none ever did. As @The_Doc_Man pointed out, someone in your role is what makes the book work.

You can write your own Forward. Who you are, what a PITA this work has been, why you kept at it etc. and any other such stuff. And I will give you the praise and credit for all of that.:D
 
Well all I can say, is that if I was thinking on writing a book for others on what I know, is that I wouldv take that approach.

For you I would pretend that you are starting off from scratch, and the first pages of that pdf were that way.

I could read the paragraph, understand it, then paste into my demo dB.

However then we get the syntax,naming errors,and either have to guess or ask, which in this scenario is doable, but when published, not the case?

This is why I suggest taking a step back, and likely recreating the pdf, step by step as you imagine creating your classes, and copy the relevant pdf paragraphs to the new pdf, but ensuring that reflects the true code.

That, to me, is the only way I could be sure that what I would post to a pdf reflects the db.

A lot more work, I realise, but required IMHO, and we are not even halfway way through the pdf.
The first few pages were good, then we just lost the way.
 
I am not creating a pdf, I am writing a document in LibreOffice. All I do to create the PDF is "export to pdf" and it takes whetever is in the book and exports it into the pdf. Are you looking in the demo database? Or just creating yours from scratch. I know that I suggested exactly "creating one from scratch", but that assumes that the book tells the user how to do that. Once we have the book straightened everything out then the actual reader can do exactly that. And it will all just work.

As for starting over, I have 180 pages written. It feels like half of that is pretty much proofed.

>>>>However then we get the syntax,naming errors,and either have to guess or ask, which in this scenario is doable, but when published, not the case?

The point of your work is finding that stuff. Me fixing it. The end reader will not ever see that. I just found and fixed a dozen or more naming convention mismatches. That is stuff you found, stuff that is now fixed.

If you would like to take a break, I can go back to the start and cut and paste from the LibreOffice doc into a brand new database as you have been doing. I did that for awhile, I can do it again.

All that you have done is not wasted and I most appreciate all of your effort to get where we are.
 
A different question. A couple of weeks ago I went in and did a major format push to get a consistent outline in each class. the

Header
Initialization
Properties
Events
Methods
Summary

thing.

I did so to make it explicit that every class might have these parts. If creating a new class, I create the class pretty much like that. I create the header with the global variables including whatever type of control we are wrapping, the Class_Initialize / Class_Terminate, the fInit(), and event sinks, and class properties, any class functions. I often create a shell, then fill it in with functionality. But I want the reader to see this process, thus the outline.

However the outline "gets in the way" In a document that stuff are lines of actual text with header "properties"

The question - is there an easier way both for me and the reader? Are you even using that outline stuff? Does it make it visually obvious? Does it make the PDF easier or harder to work with? Should I only do it a couple of times then stop?

In the document in the editor I use the outline to collapse and expand to get stuff out of the way when I want, to work on what I am working on. The same thing can be done in the PDF.
 
Last edited:
No I have seen those, and think they are very useful.
I am approaching it as someone who knows vba but not the logic of classes, which TBH is me.
However, I am also applying the fact that I am pretending I have no clue as to classes or how they work. Which I would think is the intention of the book.
I feel (from experience) that you are losing focus of each topic as amendments are made.
The initial naming is a classic example.
If you were coding in a db, they would be consistent, but trying to push to a pdf, they are getting changed.
At the point I got to, those functions were working, but then you supply names which will never work. I am able to determine why, but a book should not even expose that issue.
That is why I think starting from scratch and copying text from pdf a to pfd b with correct and tested code, would be the way to go.
 
OK. I am working out of EventDrivenProgrammingDemoDB.accdb. It completely compiles and runs. But it was using an advanced clsFrm. I put clsFrm back in and yea, it didn't run. It was expecting a textbox name for the PID that didn't match my form. A huge part of our problem is that I am trying to keep advancing the book.

I have a couple of very cool things (I think) I want to finish. Things like a class which parses the OpenArgs passed in to a form. OpenArgs allows me to do a behavior where I double click in a combo, open a data entry form for the table behind the combo, pass in (as an OpenArg) the PKID of the record that is being displayed in the combo in the form. And finally to seek to that record so that it can be edited. IOW, open a form, seek to a record, edit the record, close that form and requery the combo that was double clicked in to display the change just made.

OpenArgs is a pair of classes which you haven't gotten to yet but which work already.

I have a message class clsMsgPD. Working, in use in a new pair of demo forms.

If you want I will just stop writing.
 
No I have seen those, and think they are very useful.
I am approaching it as someone who knows vba but not the logic of classes, which TBH is me.
However, I am also applying the fact that I am pretending I have no clue as to classes or how they work. Which I would think is the intention of the book.
I feel (from experience) that you are losing focus of each topic as amendments are made.
The initial naming is a classic example.
If you were coding in a db, they would be consistent, but trying to push to a pdf, they are getting changed.
At the point I got to, those functions were working, but then you supply names which will never work. I am able to determine why, but a book should not even expose that issue.
That is why I think starting from scratch and copying text from pdf a to pfd b with correct and tested code, would be the way to go.
@Gasman, I am not editing in a PDF. I don't have a clue how to cut out of a pdf and paste it into a new pdf.

My workflow is as follows:

Write code in EventDrivenProgrammingDB.
This involves writing classes, or just editing an existing class.
Build a table to be behind a form.
Build a form, or forms. A pair in this case.
Get it working in the database.

Stop to answer your questions. Find and fix what you have found... can be anywhere in the middle of my workflow...

Open the book TEXT FILE, a LibreOffice .ODT file.
Move to some place where what I am doing fits.
Create a new section of the book. Add all of those header thingies.

Stop to answer your questions. Find and fix what you have found... can be anywhere in the middle of my workflow...

Write explanatory text about the class.
Paste in the code for that class.
Write explanatory text about the form which is going to use the class.
Paste in the code for that form.

Stop to answer your questions. Find and fix what you have found... can be anywhere in the middle of my workflow...

Once I am happy with my edits in the LibreOffice editor book, export that new version of the book to a EventDrivenProgrammingDB.pdf. Which overwrites the old version.
Copy the EventDrivenProgrammingDB.PDF from my dev directory on my D: drive to the Github directory on my D: Drive.
Push the book EventDrivenProgrammingDB.PDF to GitHub using GitHub Desktop.
Copy EventDrivenProgrammingDB.ACCDB from my D: dev directory to my D:GitHub directory
Push the accessdb to GitHub using Github desktop.

Stop to answer your questions. Find and fix what you have found... can be anywhere in the middle of my workflow...

This is Waaaaaaaay more than copy from one thing into another thing.

Perhaps it is time to just accept what is already in there and call it enough. I was using your editing to free me up to build the next piece. If I have plenty of examples already then more isn't better. I love what I do and have done. But in the end SOMETHING has to get finished and if you are running out of steam I need to protect what steam you have left and use it to finish what is already done.
 
@Gasman, I found and fixed the issue you were having I think. I was in the middle of importing an advanced version of csFrm, which is in the db as clsAdvFrm, and which uses clsAdvXXX other classes. Sorry!!!

I went back to using clsFrm, which promptly caused a compile error because of the name of the txtPKID in the class / form did not match the book / clsFrm. I found and fixed that. Now I have to find and fix it in the book.

I have pushed the db to GitHub. Do me a favor and download that. Then open it and open frmPeople. That demonstrates clsFrm and the record selector combo and class. Click around and watch the combo change to match the position in the form, and vv. Close that when you are done playing.

Then do me a favor and open frmTestEditField. This form demos a ton of stuff which we haven't gotten to yet, and in fact most is not even in the book.

DblClick in any of the three text boxes. A new form will open with the textual contents of the text box clicked in available to be edited.
Edit the data to your heart's content.
Close the form.
Notice that the data you changed is now in the text box that you double clicked in originally.
DblClick in each of the three text boxes. Each one will open the same frmLongDataEntry, passing in its contents to be edited.
Edit as desired, then close the form.

This is an actual behavior that a client requested. They needed a form with a dozen text boxes which could contain huge quantities of text. It can't even be displayed, never mind edited back in the original form. They needed a way to see the actual data in each text box, edit it and save it. This is a solution.

Now open frmPeopleAdvanced. What is different here:

dblClick into the EyeColor or HairColor drop down combos. An edit form will open and the cursor will move to the record that the combo was displaying back on frmPeopleAdvanced.
Edit the color
Close the edit form
The combo back in frmPeopleAdvanced will requery and now display whatever you edited the contents to.

This is just a solution I created to allow users to edit the combo data.

These are things I am (or was) working on for future book content.
 
Changed MCtlScanner to fCtlScanner in the db and in the book. About 8 times!!!

txtRecSelPK replaced with txtPKID. Only one time in the book.

txtPKID has been my goto for 20 years. Why all of a sudden did I use txtRecSelPK?

Brain farts is the only excuse I can come up with.

PDF and db pushed to GitHub.
 
Sorry, I forgot you were creating it in a word program.
 
Ok, something is out of sync.

In the book, you originally had clsAdvCtlCboRecSel without the Adv but did have the cbo.
This was meant to be placed at the top of clsFrm.

Yesterday, it was changed to Private mclsCtlCboRecSelSimple As clsCtlCboRecSelSimple

So I am getting a little lost here? :(


Also, you have corrected the .Name issue by including the With , but have not amended the fCtlScanner function in the book.
The code shows

Code:
Private Function FCtlScanner()
Dim ctl As Control
     For Each ctl In mfrm.Controls
        With ctl
         Select Case ctl.ControlType

clsAdvCtlCboRecSel does not exist in the book yet?
1748256447153.png
 

Users who are viewing this thread

Back
Top Bottom