Using clsMsgPD - The Big Edit

[jwcolby54]

I have a new blog up about clsMsgPD which is a predefined or predeclared class which I use to pass messages around. In this case a client asked me to create a "big edit" form. The user could dbl-click into any text box following a naming convention and doing so would open a form with a single large text box which would contain the text back in the text control dbl-clicked in. They could edit the text and when they closed the form the edited data would appear back in the text control that was dbl-clicked in.

This demonstrates several powerful abilities of VBA.

• Predeclared classes - clsMsgPD
  
  Predeclared classes - default instance
  
  
• Raising events - clsMsgPD.Send(varFrom As Variant, varTo As Variant, varSubj As Variant, varMsg As Variant)
  
  RaiseEvent Message(varFrom, varTo, varSubj, varMsg)
  
  
• Passing a control into a variant - clsCtlTxt.mctlTxt_DblClick ...
  
  clsMsgPD.Send "", "frmLongDataEntry", "", mctlTxt
  
  
• Coercing a variant into a text box - frmLongDataEntry.mclsMsgPD_Message event sink
  
  Set mtxtPassedIn = varMsg

The full blog is found at Using clsMsgPD - The Big Edit

The forms and classes can be found in the demo database.

EventDrivenProgrammingInVBA.pdf

EventDrivenProgrammingDemoDB.accdb

Any questions about how it works will be fielded right here.

Thanks!

 

[arnelgp]

you can also use a Public sub and a Form to do similar, without using a Custom class.

 

[isladogs]

@jwcolby54
Your example app is 32-bit only.
There don't seem to be many declarations needing conversion.
What about variable definitions in procedures and type statements which I haven't checked

 

[jwcolby54]

There must be 50 ways to leave your lover.

Events form an "asynchronous" interface for doing things. I am teaching how to use events, and frameworks. I could teach how to use public subs I suppose, but most devs know that already. Not necessarily true with using custom classes and events.

I wrote a framework which, when a form loads, loads a custom class called clsFrm. clsFrm has a control scanner which scans the form and loads custom classes for each control. One of those classes is clsCtlTxt, which is loaded for every text box. clsCtlTxt has code in it to implement this behavior. Until my client asked for this, clsTxt did not have this behavior.

• I use clsFrm to make my user interface consistent.
• I already use clsCtlTxt to manage text controls and allow then to do consistent things in every form in my app.
• I did not have this text box behavior until my client asked for it.
• When the client asked for it, I created the form frmLongDataEntry.
• I added code to my already existing clsCtlTxt to check its name and if it followed a naming convention, use a dbl click to open the form and pass in a pointer to itself.
• My entire app, across every form and every text box, can now have this ability.
• Since this is in my framework, which is a library, I can have this in every app I develop.
• I developed this framework starting in 1998 or so, and used it in many different apps to make my apps UI all work the same way.

Of course if the dev wants this turned on (s)he will need to name text boxes a certain way. So it will not "turn this on" for existing forms without the dev going in and renaming text controls which (s)he wants to use this behavior. But any control across the entire app which uses the naming convention has a new behavior.

I make no claim that this is the only way to make this behavior happen. Nor for that matter the best way.

 

[jwcolby54]

@jwcolby54
Your example app is 32-bit only.
There don't seem to be many declarations needing conversion.
What about variable definitions in procedures and type statements which I haven't checked

@isladogs I don't build apps any more. I have never used 64 bit. What would I need to do to be able to make the demo simultaneously 32 and 64 bit enabled?

I don't know that I have a huge need to do this thing, though I am willing. I would think that any devs using 64 bit would be able to make these conversions themselves. Or am I "putting off" a huge reading public, needing to learn classes and events, that use 64 bit and need me to do this for them?

TBH I am not sure I have a huge reading public!

 

[isladogs]

@isladogs I don't build apps any more. I have never used 64 bit. What would I need to do to be able to make the demo simultaneously 32 and 64 bit enabled?

I don't know that I have a huge need to do this thing, though I am willing. I would think that any devs using 64 bit would be able to make these conversions themselves. Or am I "putting off" a huge reading public, needing to learn classes and events, that use 64 bit and need me to do this for them?

TBH I am not sure I have a huge reading public!

I would say you are putting off potential readers by being 32-bit only - not just me!
The proportion of developers using 64-bit is increasing all the time and surveys at Access DevCon etc suggest its now probably the majority.
Whilst those who need it may be willing to do the conversion themselves, there are a lot of classes to check!

There are many articles about converting to 64-bit, though many make it unduly complicated (or are incorrect)
The process is fairly easy but can be time consuming.
It really needs someone who knows the code so they can check it is working correctly in 64-bit

I have a series of 5 articles on the subject starting with:

32 to 64-bit Conversion

This article provides links to various web pages & utilities to assist with converting VBA code for use in 64-bit applications.

www.isladogs.co.uk

My advice is to ignore A2007 and earlier in which case you don't need conditional compilation - see article 2 in that series

 

[AHeyne]

@jwcolby54 , @isladogs : I updated the api declarations to be compatible for 64-bit too. Seems to work (at least the ones really being used).

My advice is to ignore A2007 and earlier in which case you don't need conditional compilation - see article 2 in that series

I agree.

 

[jwcolby54]

As I have never tried to run anything in 64 bit Access, what is required on my end to do so? Is this a "separate install" kind of thing. And no I do not use the subscription thing, I have 2019 version.

 

[jwcolby54]

 

[AHeyne]

Press the About Access button. The following dialog will shot the bitness of your Microsoft Office installation.

Edit:
If you want to check the bitness in VBA use such a function:

Public Function MicrosoftAccessIs64bit() As Boolean
    #If Win64 Then
        MicrosoftAccessIs64bit = True
    #End If
End Function

 

[arnelgp]

just tested your frmLongDataEntry (called from from frmTestEditField).
after closing this form, without doing any edits, the calling form is put in Edit mode (seen with Pencil).
if you did not do any edit on frmLongDataEntry, the calling form should not be put in Edit (Dirtied).

 

[arnelgp]

Press the About Access button. The following dialog will shot the bitness of your Microsoft Office installation.

you can just use the About button to see the Bitness of your office, without using any VBA.

 

[isladogs]

@AHeyne
Thanks for converting the APIs. Were many changes needed in Type statements and variable declarations in procedures?

@jwcolby54
Although you should check for yourself you must be running 32-bit Office as you would be getting compilation errors yourself in 64-bit.

My advice would be to create a virtual machine and install 64-bit Office on that. Your Office license should permit at least two installations and the 64-bit version can be downloaded if you don’t have it already

 

[jwcolby54]

just tested your frmLongDataEntry (called from from frmTestEditField).
after closing this form, without doing any edits, the calling form is put in Edit mode (seen with Pencil).
if you did not do any edit on frmLongDataEntry, the calling form should not be put in Edit (Dirtied).

The db is fixed and up on github.
[EDIT]
Private Sub Form_Close()
'
'When the form closes, place the edited text from txtDataEntry
'back into the textbox that was passed in.
'
'Only do so if the passed in data is <> the edited data.
'Because mtxtPassedIn is bound to a field, it will cause the
'calling form to be placed in edit mode.
'
If mtxtPassedIn <> txtDataEntry Then
mtxtPassedIn = txtDataEntry
End If
'clean up behind ourself
Set mclsMsgPD = Nothing
Set mtxtPassedIn = Nothing
Set mtxtDataEntry = Nothing
End Sub
[/EDIT]

 

[jwcolby54]

@jwcolby54 , @isladogs : I updated the api declarations to be compatible for 64-bit too. Seems to work (at least the ones really being used).

I agree.

Thanks but...
I need such changes to be in my db out on GitHub.

 

[jwcolby54]

@jwcolby54 , @isladogs : I updated the api declarations to be compatible for 64-bit too. Seems to work (at least the ones really being used).

I agree.

Did you pull this straight off of GitHub before making your change and posting it back here? I love your participation but i do need to keep things in sync!

Thanks.

 

[isladogs]

Did you pull this straight off of GitHub before making your change and posting it back here? I love your participation but i do need to keep things in sync!

Thanks.

That's one reason why I didn't convert it as I can't keep up with your prolific postings!

 

[jwcolby54]

@AHeyne
Thanks for converting the APIs. Were many changes needed in Type statements and variable declarations in procedures?

@jwcolby54
Although you should check for yourself you must be running 32-bit Office as you would be getting compilation errors yourself in 64-bit.

My advice would be to create a virtual machine and install 64-bit Office on that. Your Office license should permit at least two installations and the 64-bit version can be downloaded if you don’t have it already

Well.... I do not do dev anymore. Creating a VM and installing the 64 bit version, switching back and forth, keeping the database files in sync... seems like a lot of work for what I am trying to accomplish. OTOH if a guru on this board wants to work with me in testing such stuff I would appreciate that.

 

[jwcolby54]

That's one reason why I didn't convert it as I can't keep up with your prolific postings!

And I have no idea how to do simultaneous dev in access, even given GitHub. I have pulled the db posted here with the bitness conversions, updated it with the minor change to frmLongDataEntry. I suppose I will just cross my fingers, and push this latest up to GitHub.

My issue here is I don't use 64 bit and so have no clue how to even test it.

So the version with "bitness" updated is out on GitHub. If someone could test that it actually works that would be good.

Does one get compile errors without the fix on a 64 bit machine?

 

[jwcolby54]

That's one reason why I didn't convert it as I can't keep up with your prolific postings!

I am in the middle of writing this book. I believe it is a usable work as it stands, though @Gasman might disagree!

As such, yea, the prolific postings will likely continue for awhile. If anyone finds anything that needs fixing I will be doing that as well.