OpenArgs (my) class way

jwcolby54

Active member
Local time
Yesterday, 19:39
Joined
May 19, 2025
Messages
283
This thread is written solely to teach classes and framework concepts. To quote Paul, and it feels like I have done so waaay too often, there must be 50 ways to leave your lover. If you would like to teach how to use classes, events and frameworks, I encourage you to do so. Just not in this thread please. In the meantime, please refrain from "my way is better for reason xyz". Might be, not the point.

Man I hate doing that!

OpenArgs are a string passed into a form by the opening code. OpenArgs are used in any way that the developer desires to use them.

As an example of how they might be used, in my framework I allow my combo class dbl-click to open a form to edit the data in that combo.



As the form opens I use OpenArgs to pass in the PK of the record displayed in the combo. The form will read the OpenArgs, discover it has an OpenArg similar to "PKID=4" and based on that will seek to the record with PKID=4. This allows an easy way for a user to get at the data behind a combo box. If the data is modified, my clsCtlCbo will requery the combo when the opened form closes, and any changes will appear in the combo box.


That is OpenArgs at work.

The following is the code for OpenArg (singular):

Code:
Option Compare Database
Option Explicit

Private mstrArgName As String   'The OpenArg name
Private mvarArgVal As Variant        'The OpenArg value
Private mblnIsProperty As Boolean   'fills a form property

Function fInit(lstrArgName As String, lvarArgVal As Variant)
    mstrArgName = lstrArgName
    mvarArgVal = lvarArgVal
End Function

Function pName() As String
    pName = mstrArgName
End Function

Function pVal() As Variant
    pVal = mvarArgVal
End Function

Property Let pIsPrp(lmblnIsProperty As Boolean)
    mblnIsProperty = lmblnIsProperty
End Property

Property Get pIsPrp() As Boolean
    pIsPrp = mblnIsProperty
End Property


The following is the code for OpenArgs (plural). It is the supervisor. It gets the OpenArgs string if it exists, parses it, and stores any OpenArgs found in a class for each, stored in a collection. It also has a crude method for pushing any OpenArgs into form properties if the OpenArg name matches any form property name. Just a way to set the properties of a form as it opens. YMMV on that one.

Code:
Option Compare Database
Option Explicit

Private mfrm As Form     'A form reference passed in
Private mstrOpenArgs As String
Private mcolOpenArg As Collection
Private mblnApplyProperties As Boolean

Private Sub Class_Initialize()
    Set mcolOpenArg = New Collection
End Sub

Private Sub Class_Terminate()
    Set mfrm = Nothing
    Set mcolOpenArg = Nothing
End Sub

Property Get cOpenArgByName(strName As String) As clsOpenArg
On Error Resume Next
    Set cOpenArgByName = mcolOpenArg(strName)
End Property

Property Get colOpenArgs() As Collection
    Set colOpenArgs = mcolOpenArg
End Property

Public Sub fInit(lFrm As Form, _
                Optional lblnApplyProperties As Boolean = False)
    Set mfrm = lFrm
    mblnApplyProperties = lblnApplyProperties
    'The openargs string might be null
    On Error Resume Next
    mstrOpenArgs = mfrm.OpenArgs
 
    ParseOpenArgs mstrOpenArgs
    '
    'The default is false,
    'do not try and apply OpenArgs as form properties
    'If the deveopler wants to
    'They must say so
    '
    If mblnApplyProperties Then
        'ApplyFrmProperties
    End If
End Sub
'*+ Public Property interface
Property Get pName() As String
    pName = mfrm.Name & ":clsOpenArgs"
End Property
'*- Public Property interface
Private Sub ParseOpenArgs(lStrOpenArgs As String)
Dim lclsOpenArg As clsOpenArg
Dim arrSplitStrings() As String
Dim varStrOpenArg As Variant

    arrSplitStrings = Split(lStrOpenArgs, ";")
 
    For Each varStrOpenArg In arrSplitStrings
        '
        'handle a final ; in varStrOpenArgs if it exists
        If Len(varStrOpenArg) > 0 Then
            Debug.Print varStrOpenArg
            Set lclsOpenArg = cOpenArg(varStrOpenArg)
            mcolOpenArg.Add lclsOpenArg, lclsOpenArg.pName
        End If
    Next varStrOpenArg
 
End Sub

Private Function cOpenArg(lStrOpenArg As Variant) As clsOpenArg
Dim arrSplitStrings() As String
Dim varOpenArgPart As Variant

Dim strArgName As String
Dim varArgVal As Variant
Dim lclsOpenArg As clsOpenArg

    arrSplitStrings = Split(lStrOpenArg, "=")
    Set lclsOpenArg = New clsOpenArg
    lclsOpenArg.fInit arrSplitStrings(0), arrSplitStrings(1)
    '
    'See if we explicitly say ApplyProperties
    '
    mblnApplyProperties = (lclsOpenArg.pName = "ApplyProperties")
    Debug.Print lclsOpenArg.pName & ":" & lclsOpenArg.pVal
    Set cOpenArg = lclsOpenArg

End Function
 
Last edited:
Why would you not just use the WHERE argument of the OpenForm method? No code is required in the opening form. Access, the RAD tool, handles opening to the requested record.

PS, you might want to use the code tool to post code so it retains its formatting.
 
BTW clsOpenArgs can just be dimensioned in any form header and used directly in that form.

Code:
Option Compare Database
Option Explicit

Dim mclsOpenArgs As clsOpenArgs

Private Sub Form_Close()
    Set mclsOpenArgs = Nothing
End Sub

Private Sub Form_Open(Cancel As Integer)
    Set mclsOpenArgs = New clsOpenArgs
    mclsOpenArgs.fInit Me
    txtOpenArgs = Me.OpenArgs
    txtOpenArgsParsed = fDisplayOpenArgs
    fDisplayOpenArgs
End Sub

Function fDisplayOpenArgs() As String
Dim colOpenArgs As Collection
Dim lclsOpenArg As clsOpenArg
Dim strOpenArgsParsed As String
    Set colOpenArgs = mclsOpenArgs.colOpenArgs
    For Each lclsOpenArg In colOpenArgs
        strOpenArgsParsed = strOpenArgsParsed & lclsOpenArg.pName & ":" & lclsOpenArg.pVal & vbCrLf
    Next lclsOpenArg
    'txtOpenArgsParsed = strOpenArgsParsed
    fDisplayOpenArgs = strOpenArgsParsed
End Function
 
Last edited:
Why would you not just use the WHERE argument of the OpenForm method? No code is required in the opening form. Access, the RAD tool, handles opening to the requested record.

PS, you might want to use the code tool to post code so it retains its formatting.
LOL is this necessary? There must be 50 ways to leave your lover. I am teaching classes, not where clauses in SQL. Of course you can write your own posts demonstrating however you think would be better.

I designed a framework. A framework allows every form to have behaviors. In my world, Every form, when it opens, has access to it's OpenArgs. Automatically. I found that useful. If that is not useful to you, cool beans, go elsewhere and read other posts? Or write your own?

In my world, every clsCtlCbo could dblclick to open a form and seek to the record the combo was currently on. I found that useful.

In my world, my user interface had dozens of behaviors which were automatically created, in every form, in every database I designed, just because the form opened clsFrm. I found that useful. That is what I am trying to teach.

If you do not find any of this useful, cool beans. Not everyone does. But telling me how everything I am doing is the wrong way is annoying.

The code tool puts a blank line between every line for me. I will edit to place those
Code:
tags around my code.
 
Last edited:
I designed a little form to demonstrate OpenArgs. Go to the debug window and type in:

docmd.OpenForm "frmOpenArgsDemo",acNormal,,,,acWindowNormal,"OpenArg1=OpenArgVal1;CarVal=$12345.92;Color=Blue;"

The code behind form shown above runs the show here. It isn't doing anything particularly useful but it demonstrates how you can actually use clsOpenArgs directly in a form, should you find it useful. Or just use a where clause I suppose. :eek:

If you are interested in learning how classes work, put in break points and watch the stuff run.

Microsoft gave us OpenArgs for some unknown reason. They can actually be useful.;)

1749069441457.png
 
One thing I would avoid...
• If the calling form holds a reference to a clsOpenArgs instance, you risk a memory leak if clsOpenArgs also holds a reference to the calling form. In a crash, clsOpenArgs.Class_Terminate() will not run, and neither object will go out of scope because you have a circular reference.
To solve this I would....
• Refactor clsOpenArgs so it 1) only deals with value types, and 2) performs what it needs to on startup. The impact of this change is that clsOpenArg is no longer required. If we apply properties during Init, there is no need to save the IsProperty flag, and without it, clsOpenArg is just a name/value pair, which is more simply managed using a dictionary...
So a simpler and safer (and not tested) approach might look like...
Code:
Private dcn_    As New Scripting.Dictionary

'******************************************************** Jun 04 2025 *****
'
'   Property
'
'**************************************************************************
Property Get DCValues() As Scripting.Dictionary
    Set DCValues = dcn_
End Property

Property Get Value(Name As String) As String
    If Exists(Name) Then Value = dcn_(Name)
End Property

Property Get Exists(Name As String) As Boolean
    Exists = dcn_.Exists(Name)
End Property

Property Get Count() As Integer
    Count = dcn_.Count
End Property

'******************************************************** Jun 04 2025 *****
'
'   Constructor
'
'**************************************************************************
Public Function Init(OpenArgs As String, Optional ApplyProperties As Boolean) As cOpenArgs
    Parse OpenArgs
    
    If ApplyProperties Then
        'ApplyFrmProperties
    End If
    Set Init = Me
End Function

'******************************************************** Jun 04 2025 *****
'
'   Method
'
'**************************************************************************
Public Function ToString() As String
    Dim tmp As String
    Dim key
    
    For Each key In dcn_.Keys
        tmp = tmp & key & "=" & dcn_(key) & vbCrLf
    Next
    ToString = tmp
End Function

Private Sub Parse(args As String)
    Dim var
    
    For Each var In Split(args, ";")
        If Len(var) Then ParseItem CStr(var)
    Next
End Sub

Private Sub ParseItem(arg As String)
    Dim var
    
    var = Split(arg, "=")
    If UBound(var) = 1 Then dcn_(var(0)) = var(1)
End Sub
As far as I can see, this class does everything your clsOpenArgs does, does it immediately, has zero risk of memory leaks, consumers can test if a named value exists, can retrieve values by name, can enumerate Dictionary.Keys or .Items, and get a complete presentation of contents by calling ToString().

Then all you do on a form is...
Code:
Private args_ As New cOpenArgs

Private Sub Form_Open(Cancel As Integer)
    args_.Init Nz(Me.OpenArgs)
    
    txtOpenArgs = Me.OpenArgs
    txtOpenArgsParsed = args_.ToString
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Set args_ = Nothing
End Sub
 
As I have said dozens of times now, I am attempting to teach classes and frameworks. As I have said many times, there must be 50 ways to leave your lover. If I am not careful I can have a dozen developers chipping in how their (fill in the blanks) solution is so much better and why. Not the point.

There is a lot to unpack here. Let's start with Scripting is not built in to Access, and MS keeps threatening to get rid of it.

As for circular reference, as a long time dev I am accustomed to cleaning up behind myself. Yes the parent (whatever that is) has to intentionally release the pointer to clsOpenArgs. Once it does so however, given that there is no longer a pointer to clsOpenArgs, there is no longer a circular reference. The garbage collector cleans up the instance of clsOpenArgs and in doing so the class terminate event fires, cleaning up the pointer to the form.

Even your own code cleans up behind itself:

Code:
Private Sub Form_Unload(Cancel As Integer)
    Set args_ = Nothing
End Sub

As for getting back xyz from clsABC, this is a brand new class I created for just teaching this subject. It actually works reasonably well.

>>>If we apply properties during Init, there is no need to save the IsProperty flag

As it happens, I actually allow clsOpenArgs to test whether each OpenArg.name matches a form property. If it does, clsOpenArgs attempts to place OpenArg.Value into that form property. In essence passed in OpenArg values can (might be able to) be pushed into a form property, thus "setting" that property from an openarg. If the openarg is pushed into a form property, the "IsProperty" flag is set. Just a way to tell the parent that a given OpenArg was successfully placed into a form property. Some form properties can be written to, some can't. That is on the dev to know or experiment with. If that doesn't work for you, Oh well.

I could include class properties for all kinds of things. I didn't, but if we want to do that to demonstrate such, I certainly am capable of that.

As for my class only holding value types... yea. My clsFrm has a control scanner which finds every instance of however many controls are on the form, loads a class instance for each of them, and stores them in a collection. By the time clsFrm finishes loading I could, quite literally, have hundreds of instances of classes loaded. Think subforms on tabs on forms each filled with a dozen controls.

I am not afraid of classes. I have done this for 20+ years. Yes I have to consistently clean up behind myself. So should everyone.

When I started working with classes sinking and raising events, in A97 in 1998, Access crashed with regularity. Now it does not. And I still clean up behind myself.
 
Last edited:
I am attempting to teach classes and frameworks.
In support of your efforts, for which I have indeed previously expressed my appreciation, I offer readers an idea about how they might to provide this same or better functionality, with less code.
Cheers,
:cool:
 
In support of your efforts, for which I have indeed previously expressed my appreciation, I offer readers an idea about how they might to provide this same or better functionality, with less code.
Cheers,
:cool:
LOL, indeed. Look, I appreciate any effort anyone makes to teach this stuff. However I am getting banged with "why don't you just use a sql statement) or etc etc etc.

There are literally a dozen ways any given problem can be approached. Do you honestly believe I am not capable of just using a collection and storing each of the openargs in the collection as a key/value? A dictionary is not required.

I am trying to teach something specific. I am not trying to teach how to use a dictionary. Or make things simpler by XYZ. Or avoid possible circular references. Or turn two classes into one single class. I absolutely support you in doing so. You can go to the top of this forum page and start a new thread, and explain how you would approach anything you wish to teach. You are even welcomed to say "John over in this thread taught it this way, this is the way I would do it." Then you can deal with half a dozen devs saying "yea but I can do it better this aways." In your own thread.

I promise not to hijack your thread. :D I can't speak for the other half dozen devs who think their idea is better though.
 
I am not trying to teach how to use a dictionary. Or make things simpler by XYZ. Or avoid possible circular references.
You're trying to teach us how to make a class that may cause a circular reference? You know it and you don't explain it?
What kind of a teacher does that? If @MarkK hadn't explained it and someone follow your steps, where his app would end?
I really had faith in you, but reading your recent posts, now I'm in doubt.
 
You're trying to teach us how to make a class that may cause a circular reference? You know it and you don't explain it?
What kind of a teacher does that? If @MarkK hadn't explained it and someone follow your steps, where his app would end?
I really had faith in you, but reading your recent posts, now I'm in doubt.
LOL. I am writing an entire book. Which is free BTW.

The book - Event Driven Programming in VBA

A circular reference is where class A references class B which references class A. It is common, in fact it is entirely widespread. My clsFrm (read the book) grabs a pointer to the form and stores it in the header of the class. Yep, the form opens clsFrm and saves a pointer to clsFrm in the form's code behind form, and then passes a pointer to itself into clsFrm. clsFrm saves a pointer to the form (Withevents BTW, so it can sink the form events) in clsFrm's header. A circular reference. clsFrm iterates the controls collection for the form that clsFrm now has a pointer to (one of many reasons it needs a pointer to the form) and instantiates a class instance for many if not most of the controls on the form, some of which themselves need a pointer to the form. And a pointer to the clsFrm. Yep another circular reference. Two in fact.

In my framework I have a tab collection, which can have subforms. Which are stored in subform controls. Which are stored in clsCtlSFrm. With references to the form which are stored in those clsCtlSfrm.

It can be made to sound catastrophic, but it is just the norm in programming. And yes proper cleanup is required.

"If Access crashes then..." If Access crashes you have bigger problems than a circular reference. And BTW I haven't had Access crash in ages? Have you??? I guess it could. "When I was a boy" (from Clifford the big red dog which I watched 20 years ago with my 3 year old son Robbie in my lap) ... When I was a boy, in 1998, in Access 97, Access crashed several times a day. It was crazy unstable. But we soldiered through, MS fixed the bugs and Access became very stable.

At any rate if someone follows my steps then they will clean up behind themselves. I teach that over and over and over. And they will be fine, and have a deeper understanding of classes, events and frameworks.

I'm sorry if I sound annoyed but I am annoyed. I have better things to do with my time than answering a dozen "I have a better way" posts. I am not seeing those devs actually starting threads to teach their better way. Or writing a book to explain their better way either. Just sayin...

If you really want to learn this stuff, download the book, it's free. Download the example database, it's free. Dig in. There is plenty in there that needs looking at. If you know all this stuff you likely won't gain much from reading the book, and I am not targeting you as a reader. If you don't understand classes, sinking events in classes, raising events in your own classes, wrapping controls to add your own behaviors... I am trying to reach you. You can go over to my thread about the book and comment there as you read it. I encourage that.

And I will do my best to not be grouchy. ;)


The Book
 
Last edited:
I'm sorry if I sound annoyed but I am annoyed. I have better things to do with my time than answering a dozen "I have a better way" posts.
@jwcolby54 I really don't want to start an argument, but :

There are three types of people who use these forums.
1- Novice users. These users, have not enough knowledge about Access, and copy paste whatever they see. (me, when I joined AWF)
2- Users who know about Access and VBA less and more, and try to be better. (me, at present)
3- Experts. Who help groups 1 and 2 above. (what I'm dreaming of to be in future.)

I really don't understand why you're triggered when an expert tries to tell there are better ways. I, as someone who read your article, and tries to learn, should be aware of what I'm learning and what is waiting for me going the way you're suggesting. Should everyone follow your ways blindly? No.
If you teach your solution, why are you annoyed seeing others expressing their points of view on your style? Does it hurt?

IF there's a possibility of a circular reference, someone has to explain it. Obviously, you didn't. And are annoyed because someone else pointed it out?
If there's no possibility, you could explain how it's prevented.

My advice (or need) as someone who tries to learn : Don't start with a "Hello World." class. I have to feel how a class helps me before I try to learn how it's done. If you start with a class that shows "Hello World", no wonder I'm like : "What the heck. I can do it in a sub". Do you blame me for thinking so?

Thanks and I apologize if I seem to be beyond the limits of acceptability or fairness.
 
Last edited:
I am getting banged
It is optional that you receive it as being "banged." It is a public forum. If you post SolutionA billed as education grade content on a public forum, and it "bangs" you that Joey Q. Public posts a claimed-to-be superior SolutionB, then I gently invite you to manage your expectations differently.
• I really like the topics you raising. I am interested enough to bother to spend my time to comment.
• If you have an agenda in a thread, feel free to stick to it. You have no obligation to defend your work or answer 25 "I have a better way" questions.
• • Similarly, I have no obligation to confine my comments to your particular topic-of-the-day.
• Thanks for your lively contribution.
Mark
 
@jwcolby54 I really don't want to start an argument, but :

There are three types of people who use these forums.
1- Novice users. These users, have not enough knowledge about Access, and copy paste whatever they see. (me, when I joined AWF)
2- Users who know about Access and VBA less and more, and try to be better. (me, at present)
3- Experts. Who help groups 1 and 2 above. (what I'm dreaming of to be in future.)

I really don't understand why you're triggered when an expert tries to tell there are better ways. I, as someone who read your article, and tries to learn, should be aware of what I'm learning and what is waiting for me going the way you're suggesting. Should everyone follow your ways blindly? No.
If you teach your solution, why are you annoyed seeing others expressing their points of view on your style? Does it hurt?

IF there's a possibility of a circular reference, someone has to explain it. Obviously, you didn't. And are annoyed because someone else pointed it out?
If there's no possibility, you could explain how it's prevented.

My advice (or need) as someone who tries to learn : Don't start with a "Hello World." class. I have to feel how a class helps me before I try to learn how it's done. If you start with a class that shows "Hello World", no wonder I'm like : "What the heck. I can do it in a sub". Do you blame me for thinking so?

Thanks and I apologize if I seem to be beyond the limits of acceptability or fairness.
@jwcolby54 I really don't want to start an argument, but :

There are three types of people who use these forums.
1- Novice users. These users, have not enough knowledge about Access, and copy paste whatever they see. (me, when I joined AWF)
2- Users who know about Access and VBA less and more, and try to be better. (me, at present)
3- Experts. Who help groups 1 and 2 above. (what I'm dreaming of to be in future.)

I really don't understand why you're triggered when an expert tries to tell there are better ways. I, as someone who read your article, and tries to learn, should be aware of what I'm learning and what is waiting for me going the way you're suggesting. Should everyone follow your ways blindly? No.
If you teach your solution, why are you annoyed seeing others expressing their points of view on your style? Does it hurt?

IF there's a possibility of a circular reference, someone has to explain it. Obviously, you didn't. And are annoyed because someone else pointed it out?
If there's no possibility, you could explain how it's prevented.

My advice (or need) as someone who tries to learn : Don't start with a "Hello World." class. I have to feel how a class helps me before I try to learn how it's done. If you start with a class that shows "Hello World", no wonder I'm like : "What the heck. I can do it in a sub". Do you blame me for thinking so?

Thanks and I apologize if I seem to be beyond the limits of acceptability or fairness.
>>>I really don't understand why you're triggered when an expert tries to tell there are better ways.

Well... an expert was proposing that you use a dictionary for "the better way".

Scripting being deprecated

No dictionaries needed to do what was being proposed. A dictionary is a neat tool but it is not even required. I am annoyed that a dictionary isn't part of VBA but it isn't A collection would do nicely in this case.

Another expert was proposing that I "use a where clause" when opening a form.

An expert was suggesting that you avoid circular references. As I explained, circular references are a normal daily occurrence out here in class land. It would not even occur to me to "avoid" circular references. If you are going to wrap the form Withevents, be able to sink events inside of your class, you have to dimension a variable at the top of the class and store a pointer to the form (in this case). You have to deal with circular references, which I explain how to do. Clean up behind yourself!

>>>>My advice (or need) as someone who tries to learn : Don't start with a "Hello World." class. I have to feel how a class helps me before I try to learn how it's done. If you start with a class that shows "Hello World", no wonder I'm like : "What the heck. I can do it in a sub". Do you blame me for thinking so?

My solution for OpenArgs is not "hello world". It is a useful pair of classes that I actually used in my framework. It demonstrates a supervisor class (as I call them) the clsOpenArgs (plural) which does the big picture part (getting and breaking down the OpenArgs into its pieces) and instantiating another clsOpenArg (singular) which holds the pieces. It demonstrates creating those pieces. It demonstrates instantiation, the process of creating an instance of a class. It demonstrates storing a pointer to clsOpenArg instances in a collection so that the clsOpenArg instances don't simply "go away" when that function exist, as would happen.

One of the points of Object Oriented Programming is to creates an Object, which performs a process. It embeds all of the code for performing that process into a class. It embeds all of the variables and data for performing that task into that same class. I am attempting to teach the use of classes. I get "I could do this in a single function" kind of argument all the time. That does not make the single function method better. It just makes it different. Often, though not always, the "single function" method is actually more complicated because it is trying to stuff so much stuff into that function. Breaking down a problem into smaller pieces is what we are all about.

In addition to teaching classes, I am attempting to teach the concept of frameworks. Windows is a framework, used to support writers of programs so that they do not have to deal with writing code for handling the mouse, the disk, memory management etc. Access is a framework, used to allow database developers to build a database without writing their own code to make tables from scratch, or forms from scratch. clsOpenArgs is just a small part of a bigger framework.

And so I have an agenda. This thread was just demonstrating the class pair concept that I use all the time, supervisor / data piece. And turning that into a tool which is actually useful. Which will be used automatically inside of another clsFrm to automatically parse out and provide to clsFrm (and the parent form) the parent form's OpenArgs.

And finally, yes, anyone at any time can jump in and demonstrate their "better way" which is a problem for me. How many people are out there who want to showcase their "better way"? Probably dozens if not hundreds. Many if not most of their better way solutions are not particularly better and certainly do not teach classes, wrapping controls, wrapping the form, raising events, sinking events etc.

I will work on a one paragraph description to be used at the top of my threads explaining what I am doing and asking up front for folks to refrain from chipping in with their "better way". Not, as has been pointed out, I can prevent them from doing so.
 
Last edited:
• • Similarly, I have no obligation to confine my comments to your particular topic-of-the-day.
True. There are actually folks out there called wedding crashers who just enjoy crashing weddings. :ROFLMAO:
 
One of the things I played with long ago was intentionally passing in form properties values as OpenArgs. As an example the visible property can potentially be set as it opens. The x/y coordinates could be set to position the form on the screen. My class was designed to just test across all of the passed in properties to see if any of them "fit" into a form property. Obviously to avoid conflicts the class had to be told to try to do this.

I think I will go back in and play with that concept. Or maybe add a method that allows me to poke form property name / values into a method which then tries to poke those values into the matching form property.

Just a fun thought experiment to lighten the mood.
 
Well... an "expert" was proposing that you use a dictionary for "the better way"....

An "expert" was suggesting that you avoid circular references.
That was MarkK.

Another "expert" was proposing that I "use a where clause" when opening a form.
That was Pat.

John, I do not presume to know your meaning by putting "expert" in quotations. When I use them in that manner, my intention is to question the word in quotes as questionable.

It is there that I am coming from.

The two individuals you alluded to, I can assure you are indeed experts - recognized as such by every member of this forum and elsewhere in the Access Developer community. Their contribution to this thread, whether you or anyone else agrees with it, does not in any way negate that.

If I misunderstood your intent, then please disregard and accept my apology. If I have it right, then understand I will call out you, and anyone else for that matter, each and every time I perceive a slight towards this Forum's experts, or Heavyweights as I like to call them.
 

Users who are viewing this thread

Back
Top Bottom