UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
4 Pages V  1 2 3 > »   (Go to first unread post)
   Reply to this topicStart new topic
> Auto Resize Forms, Access 2016    
 
   
VBStudent
post May 28 2017, 11:37 AM
Post#1



Posts: 72
Joined: 17-April 16



Hello Guys,

Is there a way to have forms and their controls auto resize in different screen size? My users have different monitors and my database doesn't look very good for some of them.

Thank you!
Go to the top of the page
 
GroverParkGeorge
post May 28 2017, 12:02 PM
Post#2


UA Admin
Posts: 36,084
Joined: 20-June 02
From: Newcastle, WA


This is a long-standing problem, with no really good solutions available.

You can try code that attempts to resize forms on the fly, which is doable, but not simple.

You can adjust users' monitors to a common size, but you should avoid that strategy, IMO.

Perhaps the most usable, least effort, approach is to use control anchoring on some controls.

[attachment=82622:controlanchoring.png]
Go to the top of the page
 
VBStudent
post May 28 2017, 12:25 PM
Post#3



Posts: 72
Joined: 17-April 16



Thank you George!

I will try to use anchoring. Thanks.
Go to the top of the page
 
theDBguy
post May 28 2017, 12:32 PM
Post#4


Access Wiki and Forums Moderator
Posts: 76,606
Joined: 19-June 07
From: SunnySandyEggo


There used to be demos floating around with the code to auto resize forms as George mentioned, and I think there's also a commercial version available.

Sent from phone...
Go to the top of the page
 
ADezii
post May 28 2017, 01:38 PM
Post#5



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


  1. I use a rather complex system to accomplish exactly what you are requesting and it is straight from the Access 2002 Developers Handbook. The Code will Resize a Form and all of its Controls independently of any Screen Resolution. You need not know the complexities of the Code but only how to Copy-n-Paste a Procedure Call, as well as a couple of Properties to optionally set.
  2. Open the Demo Database that I have attached for you and frmScaleTest will Open (StartUp Form).
  3. There are four critical pieces of information that you will need in order to Resize a Form and all of its Controls independently of any Screen Resolution, and they are:
    1. Width of Screen in Pixels.
    2. Height of Screen in Pixels.
    3. Number of Logical Dots per Inch (DPI) in the Horizontal Resolution.
    4. Number of Logical Dots per Inch (DPI) in the Vertical Resolution.
  4. These Values must be known for the Resolution at which you designed your Form and all of its Controls, and establishes a 'Base' to automatically readjust these Objects for other Resolutions.
  5. Lucky enough, these can be automatically calculated for you.
  6. Click the Open frmScreenInfo Command Button and you will see these critical pieces of information displayed.
  7. At the bottom of the Screen Info Form you will see a Text Box that displays the actual Procedure Call that you will need for your specific Resolution.
  8. CRITICAL: Copy this Procedure Call, then in Design View of frmScaleTest go to the Open() Event.
  9. CRITICAL: Overwrite this line of Code (Call frmResize.SetDesignCoords(1920, 1030, 120, 120)) which happens to be 'my' Horizontal and Vertical Resolutions as well as Logical DPI X and Logical DPI Y. This is the environment that I work in.
  10. In the Open() Event, there are four additional Properties that you can set, namely: ScaleFonts, ScaleForm, ScaleColumns, and ScaleControls. I set them all to True and I suggest you do the same initially.
  11. There is ample documentation on exactly what is going on should you wish to experiment with different settings to see their effects.
  12. Change the size of the Form and notice that all the Controls, Fonts, and Columns contained within will adjust accordingly.
  13. Run on a PC with a different Resolution and see what happens.
  14. Good Luck with your Project, and if you have any questions feel free to ask.

Attached File(s)
Attached File  Screen_Resolution.zip ( 183.61K )Number of downloads: 88
 
Go to the top of the page
 
projecttoday
post May 28 2017, 01:43 PM
Post#6


UtterAccess VIP
Posts: 11,208
Joined: 10-February 04
From: South Charleston, WV


If this works well I suggest putting it in the code archive.
Go to the top of the page
 
GroverParkGeorge
post May 28 2017, 01:44 PM
Post#7


UA Admin
Posts: 36,084
Joined: 20-June 02
From: Newcastle, WA


You can submit it for evaluation to be included in the code archives. Thank you.
Go to the top of the page
 
ADezii
post May 28 2017, 01:48 PM
Post#8



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


IMHO, it is the best approach that I have ever seen to resolve this problem. Hopefully, the StartUp Form will display properly on the OP's Screen so he does not have to resize the Form and its Controls initially prior to Copy-n-Pasting the Procedure Call.
Go to the top of the page
 
theDBguy
post May 28 2017, 02:45 PM
Post#9


Access Wiki and Forums Moderator
Posts: 76,606
Joined: 19-June 07
From: SunnySandyEggo


Hi ADezii,

Just curious... Have you tried using this technique with an ACCDB? If so, does it play "nice" with Anchoring? I use Anchoring and was just wondering if combining the two won't be a problem.

Thanks.
Go to the top of the page
 
VBStudent
post May 28 2017, 02:50 PM
Post#10



Posts: 72
Joined: 17-April 16



Sweet!!!

Thank you very much ADezii! This is exactly what I was looking for.

I am gonna start playing with it and will let you know. thanks.gif
Go to the top of the page
 
ADezii
post May 28 2017, 03:10 PM
Post#11



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


QUOTE
If so, does it play "nice" with Anchoring?

To be perfectly honest, I have never used this approach in conjunction with Anchoring.
Go to the top of the page
 
ADezii
post May 28 2017, 03:12 PM
Post#12



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


@VBStudent:
yw.gif Any questions, we are here for you. You can even have finer control by setting the READTAGS Constant. Setting READTAGS to true allows you to
control exact behavior of individual controls by setting values in their Tag Properties. The Code is complex but well documented.
Go to the top of the page
 
GlenKruger
post May 29 2017, 08:51 AM
Post#13


Utterly Crispy UA Forum Administrator
Posts: 8,813
Joined: 29-September 01
From: Edmonton,Alberta,Canada


Just be aware any type of code I have seen or used in the past must use True Type Fonts in order to be successful.
Go to the top of the page
 
ADezii
post May 29 2017, 09:42 AM
Post#14



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


Excellent point, Glen in that True Type Fonts should be used for any Control that you wish to Scale. Other points to consider are:
  1. Not sure but I do believe that the Default Fonts used in Controls are not Scalable.
  2. Ariel and Times Roman Fonts are Scale able and readily available.
  3. You must also be careful and avoid using any Fonts that may not be available on any User's machine.
  4. If I am incorrect on any of the above statements, please advise.
Go to the top of the page
 
VBStudent
post May 29 2017, 01:38 PM
Post#15



Posts: 72
Joined: 17-April 16



Great points. Thank you!
Go to the top of the page
 
ADezii
post May 29 2017, 04:04 PM
Post#16



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


Other points to consider are:
  1. If you do not intend to use the Tag Property to initialize individual Controls, you can remove the TaggedValue and TaggedValues Classes, bit you must set the READTAGS Constant in the General Declaration Sections of the ControlSize Class Module to False.
  2. Sub-Forms shown as Datasheets cannot be resized.
  3. Do not mix the AutoCenter Property of a Form with the ScaleForm Property of a FormResize Object. If you wish to Center a Form as it opens, set the CenterOnOpen Property of the FormResize Object to True. If you want to center a Form on the fly, use the Center Method of the FormResize Object.
  4. As stated earlier, use True type Fonts.
Go to the top of the page
 
GlenKruger
post May 30 2017, 12:47 PM
Post#17


Utterly Crispy UA Forum Administrator
Posts: 8,813
Joined: 29-September 01
From: Edmonton,Alberta,Canada


Here is a 64 bit version all I did was use the PtrSafe to declare functions and it works with Access 2013.
Attached File(s)
Attached File  Screen_Resolution.zip ( 192.64K )Number of downloads: 47
 
Go to the top of the page
 
ADezii
post May 30 2017, 01:48 PM
Post#18



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


@Glen:
What do you think of the idea of combining both the 32-bit and 64-bit Versions into a single Version via Compiler Constants? Never mind, just realized how many APIs exist backtotopic.gif .

Out of curiosity, didn't you have to change any of the Data Types in the 64-bit Declarations, such as: Long ==> LongPtr?
Go to the top of the page
 
skymou
post May 30 2017, 02:06 PM
Post#19



Posts: 4
Joined: 19-April 16



@Glen: Adding PtrSafe is good, but you also need to convert arguments like "ByVal HWND As Long" to "ByVal HWND As LongPtr" to make it work under both 32-bit and 64-bit Access.
Go to the top of the page
 
ADezii
post May 30 2017, 02:08 PM
Post#20



Posts: 2,690
Joined: 4-February 07
From: USA, Florida, Delray Beach


Sorry skymou, didn't mean to step on your toes.
Go to the top of the page
 
4 Pages V  1 2 3 > » 


Custom Search


RSSSearch   Top   Lo-Fi    21st November 2019 - 03:00 PM