Support for Forms and Reports on Large Monitors has appeared on the Access Roadmap (1 Viewer)

[GPGeorge]

Long anticipated news of support for monitors larger than 22 inches appeared on the Access Roadmap yesterday, April 4, 2025.

Visit the Access Roadmap

The goal is to remove the 22-inch size limit and modernize Access forms and reports to work well on large format monitors and to provide responsive behavior for different form factors.

We should see this exciting new functionality starting this Summer.

 

[KitaYama]

...... modernize Access forms .....

To be honest, I prefer them bring back the previous height of the title bar instead of modernizing anything.
With each update, Access is going downhill.

 

[GPGeorge]

To be honest, I prefer them bring back the previous height of the title bar instead of modernizing anything.
With each update, Access is going downhill.

You haven't even seen it yet....

 

[KitaYama]

You haven't even seen it yet....

By IT, you mean the recent title bar or the modernized forms?

 

[GPGeorge]

By IT, you mean the recent title bar or the modernized forms?

The topic of this post-- support for large monitors and responsive forms.

 

[The_Doc_Man]

I am encouraged by the idea that they are doing anything at all to bring Access to a more modern ability. The thing that would REALLY knock my socks off is the 32/64-bit ability dichotomy. Word and Excel documents (and presumable, Power Point) can build larger data files, but Access-64 still has the 2 GB limit per DB file. We already had work to do converting 32-bit to 64-bit for mostly cosmetic features. Not discounting the "Large-Address Aware" option, just not a spectacular announcement.

Breaking the 22-inch limit simply means that the INTEGER values used for graphic coordinates in twips will change from 16-bit to something larger. That is something, at least. Breaking the 2-GB limit... now THAT would be interesting.

 

[KitaYama]

The topic of this post-- support for large monitors and responsive forms.

Yes, I saw that. I meant a lot of users prefer the current problems being solved before adding anything. If you google "microsoft access Thick Title Bars" you'll see how many users are suffering from the height of titlebar. I know a lot of users that have stopped updating office to keep the previous height. Our organization one of them.

I meant I hope they look at the priorities. As Doc says, 2 GB limit is something more important than 22" monitor limit.
I'm sorry if I wasn't clear.

 

[GPGeorge]

Spoiler:

I am encouraged by the idea that they are doing anything at all to bring Access to a more modern ability. The thing that would REALLY knock my socks off is the 32/64-bit ability dichotomy. Word and Excel documents (and presumable, Power Point) can build larger data files, but Access-64 still has the 2 GB limit per DB file. We already had work to do converting 32-bit to 64-bit for mostly cosmetic features. Not discounting the "Large-Address Aware" option, just not a spectacular announcement.

Breaking the 22-inch limit simply means that the INTEGER values used for graphic coordinates in twips will change from 16-bit to something larger. That is something, at least.

Breaking the 2-GB limit... now THAT would be interesting.

SQL Server Express

 

[AHeyne]

Or Microsoft SQL Server LocalDB.

 

[Pat Hartman]

Large monitors cater to large spreadsheets and people with 20-20 vision. I don't see them as a dire need to Access work. One of my clients upgraded all workstations a year or so ago and I hated working with it. I reverted back to my two largeish monitors.

 

[MarkK]

Glad to hear it, thanks George. Looking forward to hacking this line of code...

Private Const MAX_WIDTH = 22 * 1440

...out of a bunch of forms.

 

[isladogs]

I believe this is a significant update that will be welcomed by a large number of users.
The support for large monitors will also be useful for those who, like myself, use two 22" monitors side by side as you can extend Access and its forms across both monitors.
The ability to zoom forms and their controls within Access is even more significant. For almost 20 years, I have been using automatic form resizing to accomplish this. We've had this feature for many years with reports. Having this as a built-in feature for forms will be amazing and it will also apply to design view.

As for the disparaging comments earlier:
1. The increased height of the title bar is an Office-wide feature. I have no idea why it was changed but its size is not under the control of the Access team. At worst, it is an irritation. Certainly not the most important issue that needs fixing.

2. The 2GB limit only applies to unsplit Access databases. Using an FE with a single Access BE effectively doubles the maximum size and as already mentioned, using e.g. SQL Server Express gives you another 10 GB at no additional cost.

Whether or not the 2 GB limit could be waived is another matter. In practical terms, exceeding 1 GB causes performance to drop away and aiming at anything close to 2 GB will cause Access to hang. Much of this is because Access needs space to use for temp tables when running queries etc. However, I suspect that large Access databases would perform very slowly even if maximum capacity were doubled.

 

[Pat Hartman]

A much more useful feature would be the ability to scale a report to fit the way you can do with a workbook you want to print.

 

[isladogs]

EDIT: This is a response to a post by The_Doc_Man which he has since deleted

I'm not sure about how relevant your comments are but do you have any documentary evidence for any of that?
The official Access specifications page states:

In other words, the 2GB includes all database objects. Whilst tables typically take up the vast majority of that space, other objects such as forms, reports and modules do occupy a certain amount of space within that limit. Certain items held temporarily in memory are not part of that total space though the temp tables created by Access for a variety of reasons do occupy disk space.
The limit in terms of the space occupied by 'physical objects' cannot be exceeded.
My Database Analyzer app allows developers to determine the disk space occupied by each saved database object.

I deliberately avoided mentioning having multiple BE files though that is also a solution that many of us regularly employ.
RI can only be enforced for tables within a single file and for BE files it must be set within that file.( but will apply to those tables when linked to the FE. Setting/modifying RI on BE tables from the FE has no effect.
However, I don't see how your description of using the same address space is relevant or indeed correct.
If you have documentation to back up your assertions, please provide it.

 

[isladogs]

A much more useful feature would be the ability to scale a report to fit the way you can do with a workbook you want to print.

You can of course already scale reports to fit one or multiple pages on the screen, either from the ribbon or from the zoom slider on the status bar.

I assume you mean automatically scaling a section of a report to fit on a printed page.
Layout view can be useful in achieving that goal but doing it automatically for any type of report would I think be incredibly difficult.
Unlike Excel, reports don't normally fit into a perfect grid to allow shrink/stretch scaling.

I doubt that 'feature' would be a particularly worthwhile use of the time available to the Access team

 

[The_Doc_Man]

I cannot find the Access memory-specific layout references, so I will modify this to things I CAN show by various references: The high-order address bit of the Access address space is used to delineate Access data (including forms, reports, code modules, tables, queries, and overhead specific to the app file) from MSACCESS.EXE data and instructions. I'm still going to look for that reference, but it occurs to me that the article I read might have been taken down due to EULA anti-reverse-engineering clauses. Therefore, I have removed the article. Didn't think about the EULA when I posted before.

 

[isladogs]

I'm sorry but I don't see anything in your new comment other than the space occupied by Access database objects in e.g. an ACCDB file is entirely separated from the MSACCESS.EXE file itself, If that's all you meant, then it goes without saying and is also true for Word, Excel etc.

However, I would point out that if a dump file is created whilst e.g. an Access file is in use, that will contain information related to all items/objects that were in memory at the time

 

[The_Doc_Man]

I believe the address space for the .DLL files is also in low memory. Based on the error messages, I think the stack and heap are adjacent to each other and are probably in low-address memory because they would be allocated in the .EXE file initially. You are right that a dump file would tell us a lot. Not sure that I have a recent Access dump, though, and there is that anti-reverse-engineering warning. Maybe, even though it is interesting, I should drop it. Good intentions, but perhaps I wasn't thinking the implications through.

 

[GPGeorge]

Yes, I saw that. I meant a lot of users prefer the current problems being solved before adding anything. If you google "microsoft access Thick Title Bars" you'll see how many users are suffering from the height of titlebar. I know a lot of users that have stopped updating office to keep the previous height. Our organization one of them.

I meant I hope they look at the priorities. As Doc says, 2 GB limit is something more important than 22" monitor limit.
I'm sorry if I wasn't clear.

I see. The difference in title bar height is visible, but on my 28" monitors it's negligible. I totally didn't notice it until you called it out. Maybe I had noticed it as some point and decided to not worry about it. It changes nothing usable about my Access forms and reports.

If I had clients or users complaining about it, of course, I would have taken notice. As it is, I am not at all bothered by it. Change for change sake though it may be, it isn't enough to evoke alarm, as I see it.

I think of this whole question of worthwhile investments in Access features and functionality in a different way.

I start with the assumption that Microsoft can invest development money in different kinds of projects. I'm sure there is no shortage of suggestions for projects coming at those managers.

In some cases a relatively small investment is required to change the application. It makes sense for them to invest that money.

In some cases, a relatively large investment would be required. In those cases, it's a tough call to make whether it's worthwhile to make that investment. After all, there is a queue of suggestions waiting for those same budget dollars.

In addition, there's a question of the downstream impact of the changes. What other existing features or functions would be impacted? But more importantly, how would a change impact millions of existing deployed Access databases? It wouldn't be the first time a regressive change was pushed out.

Changing the architecture of the accdb may or may not require a small investment. I don't know what it would take. But let's say it is cheap.

There remains the question of how that change might impact millions of deployed Access databases? Would they all continue to work the same way when run in the new beefed-up Access? There's reason to believe they could. There's reason to believe they might not.

Access still handles both mdb and accdb files, but only mdbs created in more recent versions of Access. Those created in Access 97, for example, must be migrated. It's an open question, as I see it, how such a fundamental change in accdb architecture might, or might not, create a similar divide. I simply don't know. It's worth considering, though.

All of that downstream impact has to be evaluated before any responsible manager would ask for budget to implement a major architectural change in the accdb format.

And to top it off, if you are in the group of developers who build Access relational database applications requiring more than 2 GB (approximately) of storage for data, there are multiple alternatives sitting there waiting already.

In the meantime, we can appreciate the fact that Access is still getting budget dollars to make changes that have some visibility in the general public.

 

[GPGeorge]

I see. The difference in title bar height is visible, but on my 28" monitors it's negligible. I totally didn't notice it until you called it out. Maybe I had noticed it as some point and decided to not worry about it. It changes nothing usable about my Access forms and reports.

If I had clients or users complaining about it, of course, I would have taken notice. As it is, I am not at all bothered by it. Change for change sake though it may be, it isn't enough to evoke alarm, as I see it.

Spoiler:

I think of this whole question of worthwhile investments in Access features and functionality in a different way.

I start with the assumption that Microsoft can invest development money in different kinds of projects. I'm sure there is no shortage of suggestions for projects coming at those managers.

In some cases a relatively small investment is required to change the application. It makes sense for them to invest that money.

In some cases, a relatively large investment would be required. In those cases, it's a tough call to make whether it's worthwhile to make that investment. After all, there is a queue of suggestions waiting for those same budget dollars.

In addition, there's a question of the downstream impact of the changes. What other existing features or functions would be impacted? But more importantly, how would a change impact millions of existing deployed Access databases? It wouldn't be the first time a regressive change was pushed out.

Changing the architecture of the accdb may or may not require a small investment. I don't know what it would take. But let's say it is cheap.

There remains the question of how that change might impact millions of deployed Access databases? Would they all continue to work the same way when run in the new beefed-up Access? There's reason to believe they could. There's reason to believe they might not.

Access still handles both mdb and accdb files, but only mdbs created in more recent versions of Access. Those created in Access 97, for example, must be migrated. It's an open question, as I see it, how such a fundamental change in accdb architecture might, or might not, create a similar divide. I simply don't know. It's worth considering, though.

All of that downstream impact has to be evaluated before any responsible manager would ask for budget to implement a major architectural change in the accdb format.

And to top it off, if you are in the group of developers who build Access relational database applications requiring more than 2 GB (approximately) of storage for data, there are multiple alternatives sitting there waiting already.

In the meantime, we can appreciate the fact that Access is still getting budget dollars to make changes that have some visibility in the general public.

Interestingly enough, now that you've called my attention to this "thick title bar" (in a discussion from 3 years ago when it appeared), I decided to look at it more carefully.

As it turns out, I believe the big complaint was that it made Access forms move down slightly and, as a consequence, some forms had to be resized to fit the screen.

If I am right about that, then I have to point out that the new feature is about both making it possible to display larger forms, but also making forms responsive to screen size, i.e. meaning forms no longer would have to be resized to fit the screen.

Perhaps I'm still missing something, though....