Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Form resizes on other computers
- Thread starter RobLehman
- Start date
you can RESTORE the form which keeps the form size. go to design view of the form, on the "event" tab find "on activate", select the "..." which is an event builder, then type: DoCmd.Restore
it has worked for me in the past.
good luck
it has worked for me in the past.
good luck
spiralmind
Technical User
also check to see if the client machines have a different screen res than the one you're working on, because that could also cause an appearent "resizing" of your forms and alter their alignment on the screen and in thier container windows.
- Thread starter
- #4
spiralmind
Technical User
there are three:
1) you could make a habit of designing your forms with the user's screen resolution in mind (i do this by setting my screen resolution to that of the target workstation(s), sizing my form's outer boundries, and setting my resolution back to its higher setting. this way i can trust that the form will fit the size i wish for it to have on the screen it will be used on, but i still have the extra screen space on my machine for my toolbars, property windows, helpfiles, code editor, etc. - i also test each of the forms at their destination resolution to ensure that the controls on them scale properly (sometimes text does some strange things as the font sizes don't seem to follow quite the same rules as everything else)
2) you could write some code to set the size of everything on your forms at runtime to fit the user's screen resolution. to do this you would essentially have to keep a table of all of your controls on all of your forms and their relative sizes, and a conversion table stating how many twips (microsoft's basic unit of measure - supposed to be 1/1440", but i've never seen it work out that way as it, too, is a function of screen resolution). The code would have to go through each of your controls to resize and reposition them at runtime before each form could be displayed. this works (if done right - see the Access 2000 Developer's Handbook by Getz and Litwin), but can be a little cumbersome. for a quicker version of this solution go to [blue]developershandbook.com/downloads.htm[/blue] for an mde that will do this for you (no source, though, you have to buy the book for that)
3) use an api function to change the users' screen resolution to match yours (provided their hardware supports it), just make sure this code has very good error prevention/handling and that you set the their screen resolutions back to what they were before opening the program, because that kind of thing could be a little disturbing. also keep in mind the fact that some people have their screen resolutions deliberately set low to make everything on their screen really big and easy to see, so this option wouldn't be a terribly considerate one if your application has small type, crowded forms, or a need to be run alongside something else that might have small type or crowded forms.
1) you could make a habit of designing your forms with the user's screen resolution in mind (i do this by setting my screen resolution to that of the target workstation(s), sizing my form's outer boundries, and setting my resolution back to its higher setting. this way i can trust that the form will fit the size i wish for it to have on the screen it will be used on, but i still have the extra screen space on my machine for my toolbars, property windows, helpfiles, code editor, etc. - i also test each of the forms at their destination resolution to ensure that the controls on them scale properly (sometimes text does some strange things as the font sizes don't seem to follow quite the same rules as everything else)
2) you could write some code to set the size of everything on your forms at runtime to fit the user's screen resolution. to do this you would essentially have to keep a table of all of your controls on all of your forms and their relative sizes, and a conversion table stating how many twips (microsoft's basic unit of measure - supposed to be 1/1440", but i've never seen it work out that way as it, too, is a function of screen resolution). The code would have to go through each of your controls to resize and reposition them at runtime before each form could be displayed. this works (if done right - see the Access 2000 Developer's Handbook by Getz and Litwin), but can be a little cumbersome. for a quicker version of this solution go to [blue]developershandbook.com/downloads.htm[/blue] for an mde that will do this for you (no source, though, you have to buy the book for that)
3) use an api function to change the users' screen resolution to match yours (provided their hardware supports it), just make sure this code has very good error prevention/handling and that you set the their screen resolutions back to what they were before opening the program, because that kind of thing could be a little disturbing. also keep in mind the fact that some people have their screen resolutions deliberately set low to make everything on their screen really big and easy to see, so this option wouldn't be a terribly considerate one if your application has small type, crowded forms, or a need to be run alongside something else that might have small type or crowded forms.
![[pc]](/data/assets/smilies/pc.gif "[pc] [pc]")
spiralmind
Technical User
this site: Ken Peterson's One Stop Source Shop has all sorts of info on APIs presented in a vb/vba specific format. if you don't find what you need here there are other sources, notably microsoft iteself, but they are usually presented for C++ developers
- may seeds of dreams fall from my hands
and by yours be pressed into the ground
- Status
Similar threads
- Locked
- Question
