Solved How to add custom properties to a subform (1 Viewer)

[Startup]

I ve been working with VBA for a few weeks, so I'm a newbie and my english isnt good. Sorry for that and hope you understand my issue.

Is it possible to add custom propertys by VBA to a subform? Specifically, I want to save the changes of the user. For example the size of the subform (customX, customY, customWidth, customHeight). Its should work only at runtime. It should only work at runtime.


It might look like this:

Private Sub Form_Load()
frmMySubform.addNewProp paramName ' create a new property
.
.
End Sub

Private Sub Form_Resize()
frmMySubform.paramName = frmMySubform.width ' write to the new property
.
.
End Sub

Thank you in advance

 

[CJ_London]

Short answer is no, you cannot add new properties to access controls. Usual method would be to store the custom values in a user table or similar and apply on form open (and save on form close or other event). If there are only a few you could create new properties in the db itself or perhaps the main form object (I've never tried the latter)

But I don't really understand the actual requirement so there may be an alternative to achieve what you want. I understand the user environment is runtime but what is the purpose of these custom properties? If it is just to do with resizing based on user screensize or user manual resizing of the main form, investigate the insidewidth and insideheight properties, or there are the anchoring properties of the control

 

[ebs17]

An Access form is a class. New properties can only be inserted in design mode.
A normally open form is "only" an instance of the class and can only access existing properties.

Design changes at runtime should be strictly avoided. If you pass on your application as an ACCDE, such design changes are no longer possible anyway.

So create your properties once in the draft in the VBA project of the form.

Private m_lMyWidth As Long

Public Property Get MyWidth() As Long
    MyWidth = m_lMyWidth
End Property

Public Property Let MyWidth(ByVal lMyWidth As Long)
    m_lMyWidth = lMyWidth
End Property

At runtime you can now read or write such a public property on the outside.

 

[Startup]

Thank you ebs17. I copied the code and it works fine. It is possible to read and write the additional property internal and from external modules.

Problem solved

 

[CJ_London]

I didn't mention the property get/let option because I thought the OP wanted to save the property value

I want to save the changes of the user.

So you would still need a table or similar to store the changes before the form closes as the property will go out of scope once closed. So in this instance simple code to save/retrieve the values would suffice.

 

[Startup]

I come from the microcontroller world with C and my English is not good. I apologize.

The user changes something on the form and the old and new data are saved only during runtime. Undo is therefore possible. The changes are not saved for a restart. The example with Get/Let is really ok for me. Furthermore, I got a better understanding of the classes. Therefore add properties or methods to a form.

 

[Josef P.]

If the data should be preserved:
I think the variant with the table makes the most sense.
Use the code example from Eberhard and add code to read and save data to a table.

e. g.:

Private m_lMyWidth As Long

Public Property Get MyWidth() As Long
    if m_lMyWidth = 0 then
         m_lMyWidth = DLookup("PropName", ....)
    end if
    MyWidth = m_lMyWidth
End Property

Public Property Let MyWidth(ByVal lMyWidth As Long)
    m_lMyWidth = lMyWidth
    SaveDataToTable "PropName", lMyWidth
End Property

But you can also save something in the form (at runtime).
For this you can add your own properties to an AccessObject.

Public Sub SaveToFormProperty(ByVal FormName As String, ByVal PropertyName As String, ByVal NewPropValue As String)

    'AccessObjectProperties
    Dim ao As AccessObject
    Dim Prop As AccessObjectProperty
    Dim PropExists As Boolean

    Set ao = CurrentProject.AllForms(FormName)

    For Each Prop In ao.Properties
        If Prop.Name = PropertyName Then
            PropExists = True
            Exit For
        End If
    Next

    If PropExists Then
        Prop.Value = NewPropValue
    Else
        ao.Properties.Add PropertyName, NewPropValue
    End If

End Sub

(Extract from https://github.com/AccessCodeLib/be...-add-in/source/BacChartConfigurationTools.cls)
Note: I use this e.g. for Better-Access-Charts so that I can store the chart properties directly in the form as a default setting without having to write anything in the code.

 

[Pat Hartman]

The problem with your initial concept is that if you use the form object to save settings for the user, they will be lost whenever you distribute a new version. Therefore, as Joseph recommended, you should save the settings to a table BUT the table needs to include the User's login id and the form/report name as well as the property name AND the settings table must be kept in the BE so that it is not replaced when the FE is replaced.

 

[Startup]

@Josef P. now i tryed out your example. After adding some new props and start access again, the data still there. It works find. In contrast to the table variant, i didnt understand where the data are stored.

As i said with ao it works fine. But if i use this loop form my form, the new props are not shown. Only standard props like insidewidth are shown.


For Each Prop In Me.Properties
Debug.Print Prop.Name
Next

I appreciate that I was able to learn so much new things within one question.

 

[CJ_London]

i didnt understand where the data are stored.

it's hidden away in the form's properties which can only interrogate by referencing the properties of the object. If you look in the msysobjects system table you will see some fields prefixed with 'lv' which stores long binary data. Don't know which one it will be (probably LvProp) but it will be in there somewhere along with the other properties.

You can also use the database documenter - you should see the values there in the properties section

 

[Pat Hartman]

@Startup -- it is inappropriate to store user settings in a form for the reasons I described above. Use a table in the BE that includes the UserID so that each user gets to save his settings.