A Quick Question (...but are they ever 'quick'?) - Can we get to the Default Form via VBA in Access? (1 Viewer)

Papa_Bear1

Papa_Bear1

Member
Local time
Yesterday, 23:54
Joined
Feb 28, 2020
Messages
168
I would like to be able to read/write the default form that is set in MS Access.
I've tried looking in the usual places like CurrentdB., Application.SetOption, CurrentProject., but can't seem to find it anywhere.
I've even tried peeking into the MSys tables, and it seems to be well hidden.

Is it super easy and I've just glossed over it?
Or is it something I simply shouldn't expect to be able to access via VBA?
 
Code: 
Sub ShowAllDBProperties()
Dim prp As DAO.Property
On Error Resume Next
For Each prp In CurrentDb.Properties
    Debug.Print prp.Name & " = " & prp.Value
Next prp
End Sub
 
This lists the startup form name

Code: 
Sub ShowStartupForm()
    On Error Resume Next
    Debug.Print CurrentDb.Properties("StartupForm")
End Sub

To set a form as startup using vba
Code: 
Sub SetStartupForm(FormName As String)
    Dim db As DAO.Database
    Dim prp As DAO.Property

    Set db = CurrentDb

    On Error Resume Next
    db.Properties("StartupForm") = FormName

    If Err.Number = 3270 Then
        Err.Clear
        Set prp = db.CreateProperty("StartupForm", dbText, FormName)
        db.Properties.Append prp
    End If
End Sub

Example Usage: SetStartupForm "frmStart"
 
Gasman said:
I believe the one set in Options?, the startup form?
Click to expand...
Probably, but in the real world "Startup"<>"Default".

Sorry, but ambiguity always sets my teeth on edge. Maybe today is just the right day to let it out.
 
Gasman said:
I believe the one set in Options?, the startup form?
Click to expand...
Correct... in Options where you tell it what form to start with. (I figured this meant it would be in Application.SetOptions - but I've had trouble finding a solid list of exactly what arguments are allowed with that.
 
isladogs said:
This lists the startup form name

Code: 
Sub ShowStartupForm()
    On Error Resume Next
    Debug.Print CurrentDb.Properties("StartupForm")
End Sub

To set a form as startup using vba
Code: 
Sub SetStartupForm(FormName As String)
    Dim db As DAO.Database
    Dim prp As DAO.Property

    Set db = CurrentDb

    On Error Resume Next
    db.Properties("StartupForm") = FormName

    If Err.Number = 3270 Then
        Err.Clear
        Set prp = db.CreateProperty("StartupForm", dbText, FormName)
        db.Properties.Append prp
    End If
End Sub

Example Usage: SetStartupForm "frmStart"
Click to expand...
OK - wild.
I thought I looked through every property of the database object. I probably looked for "DefaultForm" - so missed the "StartupForm".
I'll take a look at this --- thanks!
 
Ken Sheridan said:
Or do they mean the Form Template property?
Click to expand...
GPGeorge said:
Probably, but in the real world "Startup"<>"Default".

Sorry, but ambiguity always sets my teeth on edge. Maybe today is just the right day to let it out.
Click to expand...
Right - "Default" is not enough...
Sorry 'bout that...

So I'm talking about this:
 

Attachments

  • Default_Form_Setting_Screenshot.png
    Default_Form_Setting_Screenshot.png
    38.4 KB · Views: 11
I believe some db properties do not exist, until they are set?
 
I thought I looked through every property of the database object.
Click to expand...
That is because many properties do not exist until you add a value. That is not saying that the property has a null value, but that the property does not even exist.

You can see a demo here where the props do not exist until you add a value in the GUI.

Overview of subsequently added object properties that are only accessible via the "Properties" collection.

In the video contained here (https://isladogs.co.uk/aeu-11/index.html), Karl Donaubauer addresses the topic of 'New Properties of Objects'. It deals with properties of various objects that cannot be addressed using "." syntax, but only using the "Properties" collection of the respective object...
www.access-programmers.co.uk

So a simple example is the Caption property of a field or Table. If you look at the object there is no "Caption" property. Once you add a value, it creates the property in the properties collection and adds the value.
This is why isladogs code does this.
Code: 
Set prp = db.CreateProperty("StartupForm", dbText, FormName)
He has to first add the property to the properties collection before assigning a value. He could not simply set the value of StartUpForm because no such property existed.
 
MajP said:
That is because many properties do not exist until you add a value. That is not saying that the property has a null value, but that the property does not even exist.

You can see a demo here where the props do not exist until you add a value in the GUI.

Overview of subsequently added object properties that are only accessible via the "Properties" collection.

In the video contained here (https://isladogs.co.uk/aeu-11/index.html), Karl Donaubauer addresses the topic of 'New Properties of Objects'. It deals with properties of various objects that cannot be addressed using "." syntax, but only using the "Properties" collection of the respective object...
www.access-programmers.co.uk

So a simple example is the Caption property of a field or Table. If you look at the object there is no "Caption" property. Once you add a value, it creates the property in the properties collection and adds the value.
This is why isladogs code does this.
Code: 
Set prp = db.CreateProperty("StartupForm", dbText, FormName)
He has to first add the property to the properties collection before assigning a value. He could not simply set the value of StartUpForm because no such property existed.
Click to expand...
OK - Interesting.
I'm not certain if I was doing that searching in a DB that had a startup form already set - but I thought it did. (It may be more likely I simply missed it.)

But - as long as I can find one that IS there via VBA, and can set it, if needed, then that works out great. It is just one more thing that I can save/restore. But -I also don't want to get carried away. The primary goal driving this was really the code behind forms, but I also wanted to see how well I could 'reconstitute' an Access solution, so I am doing at least a little extra on that.

Thanks all again!!!
 
I'm not certain if I was doing that searching in a DB that had a startup form already set - but I thought it did. (It may be more likely I simply missed it.
Click to expand...
To be clear the Properties of the object are a subset of the properties of properties collection. That means certain properties will never show in the object browser. Also means you have to call them through the properties collection and not the object.
So properties of the object can be called like
myDB.Name
but you have to call the startup like
myDb.Properties("StartUpForm")

Running the properties collection before I add a start up form it does not show in the properties collection. After it appears at line 37.
Code: 
1: Name
2: Connect
3: Transactions
4: Updatable
5: CollatingOrder
6: QueryTimeout
7: Version
8: RecordsAffected
9: ReplicaID
10: DesignMasterID
11: Connection
12: ANSI Query Mode
13: Themed Form Controls
14: Use Microsoft Access 2007 compatible cache
15: Clear Cache on Close
16: Never Cache
17: AccessVersion
18: NavPane Category
19: Show Navigation Pane Search Bar
20: UseMDIMode
21: ShowDocumentTabs
22: Picture Property Storage Format
23: WebDesignMode
24: CheckTruncatedNumFields
25: HasOfflineLists
26: ProjVer
27: StartUpShowDBWindow
28: StartUpShowStatusBar
29: AllowShortcutMenus
30: AllowFullMenus
31: AllowBuiltInToolbars
32: AllowToolbarChanges
33: AllowSpecialKeys
34: UseAppIconForFrmRpt
35: AllowDatasheetSchema
36: DesignWithData
37: StartUpForm
38: Show Values Limit
39: Show Values in Indexed
40: Show Values in Non-Indexed
41: Show Values in Remote
42: Auto Compact
43: Use BigInt for linking and importing data
44: Continuous Form Record Navigation Keys
45: Use DateTime2 for linking and importing data
46: NavPane Closed
47: NavPane Width
48: NavPane View By
49: NavPane Sort By
50: CustomRibbonID
51: Property Sheet Label Width
52: Perform Name AutoCorrect
53: Continuous Form Navigation Keys
54: Option to enable Monaco SQL Editor
55: Theme Resource Name
 
MajP's list is excellent, but we can't forget that we CAN - in many cases - add a user-defined property (i.e. totally non-standard) to a property collection. So, not that we WOULD do such a thing, but we could add a property such as "IsALeftHandedMustacheCup" with Y/N options and add it to the Properties collection of something that gets saved - like a form. Of course, there would be no documentation on such a property - but you COULD create it and save it - and then later interrogate or update it in VBA.
 
The startup form is not used much by professionals. We typically use the pattern you also see in Northwind 2 Developer Edition template: AutoExec macro has one Action: RunCode, and it calls a function in a standard module.
This function would typically check several things (such as if the connection to the BE is good) before opening the first form. Or it sits back and waits until the user interacts with the Ribbon :)
 
tvanstiphout said:
The startup form is not used much by professionals. We typically use the pattern you also see in Northwind 2 Developer Edition template: AutoExec macro has one Action: RunCode, and it calls a function in a standard module.
This function would typically check several things (such as if the connection to the BE is good) before opening the first form. Or it sits back and waits until the user interacts with the Ribbon :)
Click to expand...
Indeed.
And I have used that approach before, but I vaguely recall running into problems at some point in our environment as the security posture has continued to tighten. I recall running into some friction with use of the AutoExec macro due to IT policy changes. I'll look back into that to see if I'm just imagining that.
 
The_Doc_Man said:
MajP's list is excellent, but we can't forget that we CAN - in many cases - add a user-defined property (i.e. totally non-standard) to a property collection. So, not that we WOULD do such a thing, but we could add a property such as "IsALeftHandedMustacheCup" with Y/N options and add it to the Properties collection of something that gets saved - like a form. Of course, there would be no documentation on such a property - but you COULD create it and save it - and then later interrogate or update it in VBA.
Click to expand...
Hmmmmmmm.
I did not know this.
This sounds like one of those things that I may have heard about once, it sounded intriguing, but then I never tried it out - and then forgot it. Interesting though.
 
MajP said:
To be clear the Properties of the object are a subset of the properties of properties collection. That means certain properties will never show in the object browser. Also means you have to call them through the properties collection and not the object.
So properties of the object can be called like
myDB.Name
but you have to call the startup like
myDb.Properties("StartUpForm")

Running the properties collection before I add a start up form it does not show in the properties collection. After it appears at line 37.
Code: 
1: Name
2: Connect
3: Transactions
4: Updatable
5: CollatingOrder
6: QueryTimeout
7: Version
8: RecordsAffected
9: ReplicaID
10: DesignMasterID
11: Connection
12: ANSI Query Mode
13: Themed Form Controls
14: Use Microsoft Access 2007 compatible cache
15: Clear Cache on Close
16: Never Cache
17: AccessVersion
18: NavPane Category
19: Show Navigation Pane Search Bar
20: UseMDIMode
21: ShowDocumentTabs
22: Picture Property Storage Format
23: WebDesignMode
24: CheckTruncatedNumFields
25: HasOfflineLists
26: ProjVer
27: StartUpShowDBWindow
28: StartUpShowStatusBar
29: AllowShortcutMenus
30: AllowFullMenus
31: AllowBuiltInToolbars
32: AllowToolbarChanges
33: AllowSpecialKeys
34: UseAppIconForFrmRpt
35: AllowDatasheetSchema
36: DesignWithData
37: StartUpForm
38: Show Values Limit
39: Show Values in Indexed
40: Show Values in Non-Indexed
41: Show Values in Remote
42: Auto Compact
43: Use BigInt for linking and importing data
44: Continuous Form Record Navigation Keys
45: Use DateTime2 for linking and importing data
46: NavPane Closed
47: NavPane Width
48: NavPane View By
49: NavPane Sort By
50: CustomRibbonID
51: Property Sheet Label Width
52: Perform Name AutoCorrect
53: Continuous Form Navigation Keys
54: Option to enable Monaco SQL Editor
55: Theme Resource Name
Click to expand...

This is one of those things that I just sort of muddle through, but also have wondered why it feels inconsistent.
Is there an obvious answer to: Why is it that you need not use myDB.Properties("Name") but you must use .Properties in the other case?
 
> I recall running into some friction with use of the AutoExec macro due to IT policy changes.

You may be thinking of File > Options > Trust Center > Macro Settings.
The typical setting is "Disable all macros with notification", which is how I run Northwind.
Then why does AutoExec macro work? Because the accdb (or accde in your Production app) is in a Trusted Location, which you can setup in the same Trust Center.
 
You must log in or register to reply here.

Similar threads

amorosik
Access to the web - DaDaBik - have you ever used it?
Replies
0
Views
568
amorosik
amorosik
C
Can we change the tab color or icon with "tabbed document" forms?
Replies
14
Views
1,832
xavier.batlle
X
C
Access instance remains in memory once closed
3 4 5
Replies
94
Views
8,121
isladogs
isladogs
J
Use VBA to export form data to Excel, but keep getting "We Found a Problem..." when opening the file in Excel
Replies
5
Views
1,349
June7
June7
B
Getting data from differently formatted Excel sheets to a table Form/VBA/Import question
Replies
13
Views
1,945
CJ_London
C

Users who are viewing this thread

Total: 2 (members: 0, guests: 2)
Back
Top Bottom