Building Forms for different size monitors

[Paul H]

We all use vintage (3 to 4 years old) laptops which serve us pretty well. They are all connected to one or two 21" monitors which improves the work environment vastly. The problem is that some users are stuck with using the smaller 15" display of the laptop which as you can imagine presents some problems when you have done all your development on the 21" monitor. Considering that there is no way to know what kind of display is being used at disparate locations, do you have any suggestions for designing for this. Is there a setting or some codes that would adjust the display to the monitor size? I would hate to design for the smallest, lowest resolution possible. Should I split it down the middle and design for a 17" or 19" monitor. It's not that the forms can't be used, but they are awkward and don't look that great. I am going to shrink down the forms a bit, but I'm wondering if there is another solution.

[CJ_London]

would hate to design for the smallest, lowest resolution possible

that is the usual method - it is always easier to make things bigger rather than smaller.

Since access 2007 controls can be repositioned through the properties (see the control anchor properties) or on the ribbon in form design view, the anchoring option on the Arrange ribbon

If you really want to get into it, there are code examples out there to determine the screen size the form is open (not sure how well it will work with multi screens). When you know that you can have more code to resize controls/fonts etc. There are also modules you can purchase to do this for you.

Also look at the form insidewidth/insideheight properties, the section height properties and the control move function to move and resize controls.

[Missinglinq]

First off, screen size, in and of itself, has nothing to do with the problem; the problem is resolution! It just so happens that newer, bigger monitors tend to come with their default resolution set higher than the maximum possible for older machines. You can usually set your newer monitors to a lower resolution than they're set at, from the factory, and possibly find common ground among all the machines involved, here. The higher resolutions offered, especially on larger monitors, are great if you're dealing with commercial graphics programs...or playing advanced video games...but are really overkill for most business applications, such as running databases.

There are hacks out there for adjusting the size of Forms (some for free, some for a fee) based on the resolution of the machine they're running on, but all of these come with the same caveat, as Ajax touched on; they all only perform well when the programs are developed in the lowest resolution you're likely to encounter!

Using the lowest common denominator, in program development, is pretty much always the best policy! You can't, for interest, develop a database in Access 2010, using features just introduced in that version, and expect to run the app on a machine running Access 2003, can you?

Here's a link to one of these hacks that has been around for a very long time and has a good reputation:

ShrinkerStretcher

Linq ;0)>

[Paul H]

Thanks to both Ajax and Missinglinq. I've decided at the point not to go for a hack. I created some extra space for my continuous form, which had only enough room to display one record in its original format. Now it will display 3 or 4 which should be sufficient for most purposes, except for one item. My scroll bar doesn't display correctly. Two things. The down arrow does not display on the lower resolution laptop making it difficult to scroll down. The "grab bar", the thing you use to drag the scroll bar up and down tends to be hidden compounding the scroll down issue. When the same form is displayed on the high res monitor, none of this occurs. This is hard to describe, so ask away if I need to clarify.

Thanks in advance. Going home now, I'll check back in the AM.

Paul

[CJ_London]

there are some simple things you could do if relevant. I tend not to use the access 'anchor' properties partly because I've been developing a lot longer then they've been around and I had already developed my own techniques and partly because they don't do everything I want to be able to do.

So for example, if you have a continuous subform at the bottom of the main form, to make sure it fits (subject to there being enough room anyway) and therefore scrollbars will work, this code will resize the subform to fit when placed in the mainform resize event

'no form header/footer
me.subformname.height=insideheight-me.subformname.top-60 '-60 to provide a small margin at the bottom

'subform in footer section
'me.subformname.height=me.section(2).height-me.subformname.top-60

'to adjust for width
me.subformname.width=insidewidth-me.subformname.left-60

[Paul H]

I tried the first two with unexpected results which I have decided not to debug. I have a simple work around if all else fails. Using the scroll wheel on the mouse allows the user to scroll through the records, but I would prefer a functioning scroll bar. Again, this only happens on the low res version. See the picture below.

You can see the up arrow, but not the down. Also when you see the scroll bar near the last record you can use it to drag all the way to the first record, but when you try to drag it down it only lets you scroll so far then disappears at the bottom of the subform.



I don't know how many people this will affect, but I would prefer a normal functioning form for all users.

Thanks for your patience.

Paul

[CJ_London]

don't see what the unexpected results would be but the reason your vertical scrollbar doesn't work is because the subform extends below the screen

[Paul H]

Had this all typed out carefully yesterday, but must have forgot to post. I'll try again.
The first code,

• 'no form header/footer did nothing to help the low res laptop display, but the down arrow disappeared on the 21" high res display. Taking the code out restored it to normal.

The second code,

• 'subform in footer section displays the arrows, but shrinks the subform size to about 1.5", only displaying 2 records on either low res or high res, instead of the normal 5 to 10.

I didn't use the 3rd code since width is not a problem

The subform in question sits in the main section of the main form. There is another subform in the Main form's footer.

Nothing I have tried has worked so far.

[CJ_London]

suspect we are only seeing half the picture, suggest provide a screen shot of the entire form in design view, one in normal view from the pc and one normal view from the laptop. black out any sensitive data

[Paul H]

I agree Ajax. Here are the screenshots.

• Design View
  
• High Res Monitor
  
• Low Res Monitor
  

The only real differences are that you can see fewer records on the low res, which is not a problem, but also there is no down arrow on the scroll bar, which is the main problem.

Hope this clarifies a few things.

p.s. All the maladies are fiction and have been used in development and testing.

[CJ_London]

OK so to be clear it is the subform in the detail section you need to resize

To resize it, it needs to take into account the header and footer heights, so something like

me.subformname.height=insideheight-me.section(1).height-me.section(2).height-me.subformname.top-60

or you can try

me.subformname.height=me.section(0).height-me.subformname.top-60

[Paul H]

Ha! Success! Your first suggestion worked. I didn't even bother with No. 2. So much trouble for such a little thing, but necessary I think. I hate to send out a flawed applications.

I never would have solved this without your help.

Thanks again.

Paul

[CJ_London]

So much trouble for such a little thing, but necessary I think

only when you don't know the solution. If you are using 2007 or later there are also the anchor properties of the subform control that perhaps can be used. I don't use them because I am used to coding and was only reminded of them in another thread this morning.