Solved Me Variable is Referencing Two Different Form Objects (problem)

[ADIGA88]

Hi guys

I have a problem and can't find a solution to it please if you could help.

I have a form that I use as a selector for records, I instantiate the form using the docmd.openform "frmVendorInvoicesSelector" command and referring it by using forms collection forms("frmVendorInvoicesSelector") .
I found out that the Me variable (inside frmVendorInvoicesSelector) is referring to two different form objects by using ObjPtr(Me) to check the memory address.

The following is debug output for ObjPtr Function:

Me:Form_Load 2412068985136    (good)
Me:Form_Current 2412068985136 (good)
Transmittal:Forms:AddInvoice 2412068985136 (good) this is from the caller form ObjPtr(Forms("frmVendorInvoicesSelector"))
Me:Form_Current 2412068985136 (good)
Me:txtInvoiceNo_DblClick 2413677744752 (what?!)

the txtInvoiceNo_DblClick is an event handler inside the frmVendorInvoicesSelector form

I repeated the test with a new project and I didn't encounter an issue.

Does anyone know what may cause this issue or how to approach it to find a solution?

attached is the modules of the caller form and the selector form

 

[arnelgp]

i don't really know what ObjPtr does or do you?
if it is giving you different Address, then we really need
to know what ObjPtr does or can it point to different location on same object?
what does it say here:
VBA Function OBJPTR (bettersolutions.com)
you are asking for a solution? then i supposed this is a problem for you?
but i don't see any line in your code that consumes an Object using it's ObjPtr?
if it is not broken... don't fix it.

 

[ADIGA88]

Thanks @arnelgp I just figure it out, it's the split form, they said it's cursed but I didn't listen (really don't use the split form, use a subform instead).

I just change the type of the form to a single form and it worked normally and all the object references were right.

for the ObjPtr, as far as I understand it gives the pointer value (the memory address) of an object and I am using it for troubleshooting:

Me:Form_Load 2257354118320  (good)
Me:Form_Current 2257354118320 (good)
Transmittal:Forms:AddInvoice 2257354118320  (good)
Me:Form_Current 2257354118320  (good)
Me:txtInvoiceNo_DblClick 2257354118320  (good)
Me:AddToTransmittal 2257354118320  (good)
Me:UpdateInvoiceTransmittal 2257354118320  (good)
Me:UpdateInvoiceTransmittal 2257354118320 (good)

All the Me references pointing to the same memory location 2257354118320

 

[The_Doc_Man]

Knowing the address of something is interesting, I suppose, but "standard" VBA doesn't use pointers this way very often. Usually you just pass in the actual object variable rather than copying the address to a variable and passing that in to some routine. What did you hope to do with the address? Which, in your case, is a 64-bit address because 32-bit addresses don't go that high. (You have a 14-digit address there but 32-bit stops at 10 digits.)

Other than satisfying your curiosity, what were you doing with it? You can capture the LONGLONG output (of a QUAD integer), but you can't then pass that integer back as an address because the data type will be wrong.

 

[Pat Hartman]

"Me" is only used INSIDE a form's class module and only refers to objects belonging to that class. So if "Me" is referring to something other than what you anticipate, the code is not running where you think it is running.

When you are running code outside of a form's class module that reference an object of that class, you must use the Forms!formname!ControlName format

 

[ADIGA88]

Knowing the address of something is interesting, I suppose, but "standard" VBA doesn't use pointers this way very often. Usually you just pass in the actual object variable rather than copying the address to a variable and passing that in to some routine. What did you hope to do with the address? Which, in your case, is a 64-bit address because 32-bit addresses don't go that high. (You have a 14-digit address there but 32-bit stops at 10 digits.)

Other than satisfying your curiosity, what were you doing with it? You can capture the LONGLONG output (of a QUAD integer), but you can't then pass that integer back as an address because the data type will be wrong.

I am using it for troubleshooting, In my case, I added some attributes (module variable/Property) to the targeted split form for configuring it, but after configuring the form and when accessing the attributes (properties get/let) from inside using the Me variable, the values I assigned to those attributes were gone, so by checking the pointer I could figure out that the Me (inside the form) referring to different objects during the lifetime of the form (i think it's a bug) so i suspected the split form may causing the issue (I head many articles saying the split is a bad boy) so I changed the type of the form to single then the Me variable start referring to the same pointer during the form lifetime.

 

[ADIGA88]

Knowing the address of something is interesting, I suppose, but "standard" VBA doesn't use pointers this way very often. Usually you just pass in the actual object variable rather than copying the address to a variable and passing that in to some routine. What did you hope to do with the address? Which, in your case, is a 64-bit address because 32-bit addresses don't go that high. (You have a 14-digit address there but 32-bit stops at 10 digits.)

Other than satisfying your curiosity, what were you doing with it? You can capture the LONGLONG output (of a QUAD integer), but you can't then pass that integer back as an address because the data type will be wrong.

if you are interested I can prepare a compact example showing the case

 

[The_Doc_Man]

No, as a way of discovering a problem, you take any indicators you can find. It's just a rather unusual "metric" compared to the ones I would normally use.

 

[Minty]

When you refer to a form using the following syntax

by using forms collection forms("frmVendorInvoicesSelector") .

It instantiates another instance of the form. Normally this is inconsequential but it's not the correct way to do it.
The issue/point is discussed here https://www.access-programmers.co.u...n-about-binding-controls.316219/#post-1747913 in an unrelated thread.

 

[Pat Hartman]

The form is already a class module with objects and properties and events. So are you making a class to contain an existing class because Microsoft forgot something?

 

[ADIGA88]

The form is already a class module with objects and properties and events. So are you making a class to contain an existing class because Microsoft forgot something?

it's the same form class module, and I am defining new property using the Property Keyword to configure the form. but the value I assign to the form (stored in module-level variables) just disappears when using the split type form.

 

[ADIGA88]

When you refer to a form using the following syntax

It instantiates another instance of the form. Normally this is inconsequential but it's not the correct way to do it.
The issue/point is discussed here https://www.access-programmers.co.u...n-about-binding-controls.316219/#post-1747913 in an unrelated thread.

I don't think this is the case I open the form first by using the docmd.openform command then I referring the forms collection, This is from the calling form:

DoCmd.OpenForm "frmVendorInvoicesSelector"
Forms("frmVendorInvoicesSelector").TransmittalID = Me.BatchID
Forms("frmVendorInvoicesSelector").ProjectCode = Me.strProjectCode
Debug.Print ObjPtr(Forms("frmVendorInvoicesSelector"))   '>>> the result will be 2412068985136

The frmVendorInvoicesSelector will be:

Dim mTransmittalID As Long
Dim mProjectCode As String
Private Sub Form_Load()
    Debug.Print(ObjPtr(Me))  '>>> will be the same 2412068985136 and it's a good sign
End Sub

Property Let TransmittalID(argTransmittalID As Long)
    mTransmittalID = argTransmittalID
    Debug.Print(ObjPtr(Me))  '>>> will be the same 2412068985136 and it's a good sign
End Property

Property Get TransmittalID() As Long
    TransmittalID = mTransmittalID
End Property

Property Let ProjectCode(argProjectCode As String)
    mProjectCode = argProjectCode
    SubForm.Filter = "strJobNo = '" & mProjectCode & "'"
    SubForm.FilterOn = True
    Debug.Print(ObjPtr(Me))  '>>> will be the same 2412068985136 and it's a good sign
End Property

Property Get ProjectCode() As String
    ProjectCode = mProjectCode
End Property

Private Sub CmdClear_Click()
    Debug.Print Debug.Print(ObjPtr(Me))    '>>> the result will be 2413677744752 Bad Sign 
    Me.txtSearch.Value = ""
    Me.Filter = "strJobNo = '" & mProjectCode & "'"
    Me.FilterOn = True
    Me.Refresh
End Sub

The forms("frmVendorInvoicesSelector") is referring to the same object compared to Me from the form's On_Load event. but the reference change when a button click event inside the "frmVendorInvoicesSelector" fired by checking the Me variable and it's referring to another object.
so the form I am clicking is different from the form I opened and the existing in the Forms("frmVendorInvoicesSelector")

 

[Minty]

Okay, for the sake of completeness what happens if you don't use that syntax, and instead use

Forms!frmVendorInvoicesSelector!TransmittalID = Me.BatchID
Forms!frmVendorInvoicesSelector!ProjectCode = Me.strProjectCode

Do you still get the second pointer reference?
Something is changing the pointer to a different reference.