Solved Error 2100: Control or subform is too large for this location. (1 Viewer)

Joined
Feb 28, 2023
Messages
671
This one has me baffled. I created a new status bar/navigation pane in this thread: https://www.access-programmers.co.u...-add-new-record-button-only-how.329982/page-3

We've been using it for some time. I was using this code in the Form Open procedure:
Code:
    Me.FooterBanner.left = 0
    Me.FooterBanner.Width = (Me.InsideWidth / 2) - (1.625 * 1440)
    Me.zz_frmNavButtons.left = (Me.InsideWidth / 2) - (1.625 * 1440)
    Me.zz_frmNavButtons.Width = (Me.InsideWidth / 2) + (1.625 * 1440)

FooterBanner is just a rectangle which is the height of the navigation buttons. The navigation buttons are 3.25 inches wide, so this code makes the navigation buttons centered and the footerbanner go to the start of the navigation buttons and then the buttons go to the right.

This code also seems to work and is somewhat simpler:
Code:
    Me.FooterBanner.left = 0
    Me.FooterBanner.Width = Me.InsideWidth
    Me.zz_frmNavButtons.left = (Me.InsideWidth / 2) - (1.625 * 1440)

Most of our team uses 1920x or less screen resolution and the database is maximized when opening.

Recently, we added a new user who is using 3840x1600 resolution and she was getting the subject error, so I commented out the code above and the database opened without issues. I added a message box and the database shows my form width as 25650 for both .width and .insideWidth. For her, it shows width of 25650 and 24840, which doesn't make sense to me. (Also, she is running the database on a laptop at 3840x1600 and remoting into it from another laptop at the same resolution - which I don't think should matter.)

I tried stepping through the code, and I got the above error on the second line, which doesn't make much sense to me, b/c that line should be setting the width of the footerbanner to less than half of the form width.

Then I tried changing line two to the code above and I got an error "Overflow" - and I got that same error if I changed that line to Me.FooterBanner.Width = Me.InsideWidth - 100.

Does anyone see some error that I am missing?
 
Just as a troubleshooting step, what happens if you hard code the values for the size based on the new user's screen resolution? Do you still get the error?
 
I think so. You are suggesting setting Me.FooterBannerWidth = 24840 and going from there. Odd thing is:
It seems to be working for everyone else.
Unless I am misunderstanding, I'm not sure how she has double the screen resolution and her form is smaller inside width than mine.

Unfortunately, I don't have hardware capable of running at 3840x1600 so I have to try to test while she is available, which won't be before tomorrow.
 
As an aside: MSFT is working on providing better support for high-DPI devices. The old 16-bit coordinate system is on the chopping block.
 
I would double check the inside width value carefully. The max form width is 32760 and on a wide screen monitor the inside width can easily exceed that and can return a misleading value which might explain the smaller inside width v form width

Any control where its left plus width exceeds 32760 will generate your error.
 
@CJ_London - I think you are onto something, but I'm getting lost in the circular logic - i.e. if windows is returning a misleading value, how do I get the true value?

I found a Stack Overflow post where the max value was 31680 - I'm not sure if it is 32760 or 31680. (I'm not trying to start an argument).

My first attempt at fixing it was to put in the Form Open Code:
If Me.Width > 31680 Then Me.Width = 31680
That still gave me the error.
Later, I added:
MsgBox "Width = " & Me.Width & vbCrLf & "InsideWidth = " & Me.InsideWidth
which returned 25650 for width and 24840 for the InsideWidth.

Circular logic - If the width was being reported as 25650, that explains why my if statement was ignored and the form was not sized down to the maximum width. OTOH, if the InnerWidth was being incorrectly reported as 24840, my code should have stopped the navigation buttons at that width. It wouldn't be full width as I desired, but it shouldn't have given an error code.

So it seems like Access is incorrectly reporting the width to VBA, but if it is not correctly reported, I'm not sure how I can take action on the true value?

There are some kludge methods I could use - i.e. I know it works for 1920x with an inside width of 25650, and I have @isladogs code for getting the screen resolution. So I can probably uses something like "If X resolution > 1920, set control width to 25650, otherwise, use InnerWidth - sloppy, but it should work.

Keep the ideas coming!!!
 
Sloppy but solved. In FileOpen:
Code:
    Dim HRes As String, i As Integer
    CheckMonitorInfo 'check current monitor in use
    i = Nz(DLookup("MonitorID", "tblMonitors", "CurrentMonitor=True"), 0)
    HRes = Nz(DLookup("HRes", "tblMonitors", "MonitorID = " & i), 0)
    ' Access gives Error 2100 Control to large if Inside Width > 31680 or 32760 Twips, which would be 2112 pixels. 2048 if the largest common resolution below that. (Errors on 3840x displays otherwise).
    '31680/2= 15840
    If HRes > 2048 Then
        Me.FooterBanner.left = 0
        Me.FooterBanner.Width = (15840) - (1.625 * 1440)
        Me.zz_frmNavButtons.left = (15840) - (1.625 * 1440)
        Me.zz_frmNavButtons.Width = (15840) + (1.625 * 1440)
    Else
        Me.FooterBanner.left = 0
        Me.FooterBanner.Width = (Me.InsideWidth / 2) - (1.625 * 1440)
        Me.zz_frmNavButtons.left = (Me.InsideWidth / 2) - (1.625 * 1440)
        Me.zz_frmNavButtons.Width = (Me.InsideWidth / 2) + (1.625 * 1440)
    End If

This assumes modMonitorInfo and tblMonitors is imported from one of @isladogs databases.
 
The theoretical maximum width in twips is the integer limit = 32767 (or 22.75486111111111 inches).
The quoted maximum form width of 22.75 inches = 32760 twips.

My automatic form resizing code prevents the form trying to scale up larger than that in order to avoid display glitches
 
Last edited:
Semi-related question ...
What determines the foreground/background priority for items. For example, this is my current code (for non-HD monitors):
Code:
        Me.FooterBanner.left = 0
        Me.FooterBanner.Width = (Me.InsideWidth / 2) - (1.625 * 1440)
        Me.zz_frmNavButtons.left = (Me.InsideWidth / 2) - (1.625 * 1440)
        Me.zz_frmNavButtons.Width = (Me.InsideWidth / 2) + (1.625 * 1440)
It works, the banner is on the left and extends to the navigation buttons. The buttons are centered and then the buttons width is extended to the right to fill the window.

This also works and would be a bit simpler:
Code:
        Me.FooterBanner.left = 0
        Me.FooterBanner.Width = Me.InsideWidth
        Me.zz_frmNavButtons.left = (Me.InsideWidth / 2) - (1.625 * 1440)
This works as long as the buttons are on top of the banner. But potentially the buttons MIGHT be shown behind the banner (They are the same height and the same Top position.)

The second option seems more simple to me, but the first shouldn't ever have priority issues, so ...
 
in the design ribbon you can send controls to the back or bring to front

a control that receives the focus automatically come to the front
 
...
in the design ribbon you can send controls to the back or bring to front

a control that receives the focus automatically come to the front
...but not all controls can receive focus. Labels & images are amongst those that can't get focus.
 
Most of our team uses 1920x or less screen resolution and the database is maximized when opening.

Recently, we added a new user who is using 3840x1600 resolution and she was getting the subject error, so I commented out the code above and the database opened without issues. I added a message box and the database shows my form width as 25650 for both .width and .insideWidth. For her, it shows width of 25650 and 24840, which doesn't make sense to me. (Also, she is running the database on a laptop at 3840x1600 and remoting into it from another laptop at the same resolution - which I don't think should matter.)

At the moment you just have to deal with two resolutions but that may change in the future.
Rather than hardcode for each resolution, why not incorporate automatic form resizing to automate the process?
 
AFR didn't work very well for this. It's a fantastic idea, but the database wasn't really designed for it from the beginning and I tried it previously and ended up switching back. But if you design for it from the beginning, it's a fantastic idea!
 

Users who are viewing this thread

Top Bottom