I have selected the Forms category but this applies equally to Functions, Modules as well as Subs. I did create examples of this but it does not format correctly in this little window.
When you write code you cannot use the Tab or space to align code to make it easier to read. As an instance, if you are declaring variables, they will often have names of different lengths, there is then the '=' followed by the value to assign. You cannot set the '=' on each line to the same vertical position. What you end up with is a list of code lines that snake with the '=' and then the assigned values end up all over the place.
It is worse if the ':' is used to insert a new line on a line.
If you (say) declare four variables on one line, separated with ':' each of the lines snake all over the place. Resulting in a jumbled mess.

There are other sections in code where being able to insert spaces or a tab stop would aid reading and checking later. Particularly months or years later.
Other languages allow a developer to align their code and I am at a loss to understand why Access doesn't.

The only part of your Access code that you can place at a chosen position is when you use the apostrophe ' for the Rem or reference notes. You can Tab it out or use spaces to position the apostrophe anywhere. Basically it is that option I would like to have within the code itself.

Regards, Will

Every now and again, each of our developers experiences an issue where Access will crash the first time you try to use intellisense when writing VBA code.

To get back up and running, decompiling the database always fixes the issue, but surely the editor could deal with this by suggesting the user decompiles and recompiles the code, instead of dropping out and potentially losing a lot of unsaved changes.

Example from such a crash -

Faulting application name: MSACCESS.EXE, version: 16.0.13029.20534, time stamp: 0x5f53f9d7
Faulting module name: VBE7.DLL, version: 0.0.0.0, time stamp: 0x5ea725ac
Exception code: 0xc0000005
Fault offset: 0x000256bc
Faulting process ID: 0x3748
Faulting application start time: 0x01d6a38b4a0cc91c
Faulting application path: C:\Program Files (x86)\Microsoft Office\Root\Office16\MSACCESS.EXE
Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.DLL
Report ID: 14338b0a-4d1f-432d-b845-f3272647ccc1
Faulting package full name:
Faulting package-relative application ID:

Many organizations around the world are getting benefited from Microsoft Office 365 services. This cloud-based email solution has enabled businesses with the utmost productivity. Often the need arises for Office 365 to Office 365 Migration. For this, essential Office 365 mailbox / documents need to be migrated. As Office 365 related processes are complex, most users do not know how to migrate mailbox from one Office 365 account to another one. This issue will be resolved now with EdbMails Office 365 mailboxes migration.

EdbMails Office 365 Migration has the ability to migrate emails, calendars, contacts, and tasks of one Office 365 account to another. Even if the data export is between different Office 365 domains, this application can perform it easily. Users can also select specific folders only to migrate as this tool allows Office 365 selective data transfer. In a nutshell, it is an ideal solution for Office 365 Mailbox Migration.

Some of the highlighted features are:

Migrates all items between Office 365 tenants
Exports data between different Office 365 Domains
Selective data migration using “Date Filter”
Incremental migration if you pause and resume migration between the same mailboxes.

Conclusion:
If you are looking for Office 365 mailbox migration, this is the right migration tool for you. This tool ensures smooth migration between Office 365 Mailboxes.

To Know More Visit: https://www.edbmails.com/pages/office-365-migration-tool.html

For MS Access textboxes on Forms that handle dates you can set the textbox to allow the user to optionally use a built-in DatePicker. However the DatePicker returns the date in a format set by the Windows system (e.g. as Set by Control Panel > Region > |Formats| > [Additional Settings ...] > |Date| > Short Date:)

If you use a unorthodox windows system date format, e.g. "yyyy-/MM-MMM/-dd, ddd" returning "2021/-05-May/-18, Wed" then this can be undesirably returned by the DatePicker.

Instead the DatePicker should return a date that honors any custom format set by in Format property of the Textbox control itself. E.g. If the developer sets an ISO8601 format "yyyy-mm-dd" in the Textbox format property then the DatePicker should return text like "2021-05-18".

For MS Access textboxes on Forms that handle dates you can set the textbox to allow the user to optionally use a built-in DatePicker. However the DatePicker returns the date in a format set by the Windows system (e.g. as Set by Control Panel > Region > |Formats| > [Additional Settings ...] > |Date| > Short Date:)

If you use a unorthodox windows system date format, e.g. "yyyy-/MM-MMM/-dd, ddd" returning "2021/-05-May/-18, Wed" then this can be undesirably returned by the DatePicker.

Instead the DatePicker should return a date that honors any custom format set by in Format property of the Textbox control itself. E.g. If the developer sets an ISO8601 format "yyyy-mm-dd" in the Textbox format property then the DatePicker should return text like "2021-05-18".