access the form layouts properties (1 Viewer)

I'm just reviewing my form layout functions and wondered if I can simplify the code.

The basic concept is I divide the form into areas on a grid system. Simplistically top left, top right, bottom left, bottom right.

if a form is resized (typically width is narrowed) so all the controls are not shown, controls in top right are moved and inserted below top left, bottom left is moved down to accommodate and bottom right moved to below bottom left.

The real world requirement for this is having a form that is equally usable on a PC screen (typically 19"+) and a tablet - not only a smaller screen, but controls have to be larger to accommodate the lack of precision with using a finger instead of a mouse. You see the principle frequently with web pages on phones.

To design for the smaller tablet screen (which will utilise more vertical scrolling) and apply to a larger screen can make it look rather 'inefficient'.

At the moment when a form opens I loop through the controls to identify which controls belong to which 'section' (based on their top/left properties)and put them in an appropriate collection. I don't use layouts.

When the form is resized, code loops through the collections to reposition the controls. All works fine but as I said I am reviewing it.

It occurred to me that maybe if I used layouts, I could use the layoutID instead of the control top/left properties to move controls wholesale rather than individually. I would need to know the layout top/left/height/width properties and these would need to be updateable (not read only).

From my investigations, If (using vba) I move a single control in a layout with multiple controls, all the controls move, but only vertically, not horizontally. So a halfway step.

To address the lack of horizontal movement, I'm wondering if the layout properties can be accessed, but I can't find them. I've looked in form properties and tried to find an appropriate collection but to no avail.

I've looked on line using keywords like 'form collections', 'properties', 'layouts' etc but perhaps not found the right keyword.

Any suggestions?

I found this:-

F. Scott Barker's Microsoft® Access 2000 Power Programming
by F. Scott Barker
Published by Sams, 1999

Chapter:-
MANIPULATING CONTROLS THROUGH CODE

Extract:-
This example can be done by using the native Access Tab control described earlier in the section “Working with the Native Access Tab Control.” I use the option group here to show manipulating controls on-the-fly and creating dynamic interfaces.

I haven't studied it... And my first thoughts are there's nothing there you don't already know.

It does mention "Layouts properties", which was my search term on Safari Books online, but I don't think its what you want.

It does show code for looping through an array to set the controls positions.

The code does work in Runtime..

From Microsoft:-
Control.LayoutID Property (Access)
https://msdn.microsoft.com/en-us/library/office/ff845775.aspx

Extract:-

Returns the unique identifier for the layout that contains the specified control. Read-only Long.

Syntax
expression .LayoutID
expression A variable that represents a Control object.
Remarks
The LayoutID property returns 0 (zero) if the specified control is not part of a layout.

What I get from this is that the layout ID just tells you the particular layout the control is part of.

CJ:

You probably knew most of this, but I'll do a mini-brain-dump (from my mini-brain) in hopes that something useful to you falls out. And also hope that nothing useful to me falls out and hits the floor. I will further preface by noting that the product of which I speak doesn't belong to me and therefore I cannot post ANY code for it. It was, and is now, solely the property of the U.S. Department of Defense. (OK, disclaimer offered.)

The concept and instantiation of a "Layout" is something that you run into when you auto-generate a form. Layout structures are rectangles in which your wizard placed the controls to keep them aligned. You see the layouts in (what else?) Layout view, but it is possible for you to turn off the ability to see that particular view option from the File>>Options>>Current Database menu (I think).

The problem I have with them is that you cannot just resize a control any more unless you take the layout rectangles into account. Layouts lead to really annoying side effects during resizing. I've never liked layouts and one of the first things I do after creating a wizard-built form is to immediately remove the layouts so that each control can be separately managed. When I was doing this, I far preferred to "roll my own" control positioning because I knew where I was putting things and know that it would work correctly (or equally, immediately knew when it did NOT work correctly).

I have many times done things like moving controls around on a screen. In my case, the primary effect was that the forms were dynamic according to current context. One of the cases (very frequent) was that until "enough" data had been entered into a form, my "COMMIT" button was invisible, but "CANCEL" was visible. When my form was not dirty, "CANCEL" wasn't visible either - but I would allow "CREATE" and "DELETE" buttons to be seen. "HELP" and "FILE TROUBLE REPORT" (usually abbreviated) were also visible. As the forms changed context, I moved the visible buttons to be flush starting from the right-hand top line of the form. It would not be impossible for a form to have eight or nine buttons but usually you would only see five at a time in the worst case. But for all 25+ forms in my app, the buttons would stay flush with each other.

The other case was that depending on what you were doing with the personnel form, you might have the ability to add or remove items from various lists. Depending on the function you chose, combo boxes that allowed you to select various values would move in flush to the right of the list of function buttons. That form had four possible combos but you would never use more than two of them at a time - it just was not predictable as to WHICH two until you picked the function.

It is a pain in the toches to set up but the idea is simple enough. To move a control, you have access to the properties .Left, .Top, .Height, and .Width. To move stuff around, you simply have to keep track of where you started and the next free place on the form in which you could put something. Using conventional top-down, left-to-right placement, you add a control's .Top and .Height to see the form position available below that control where you could place the next non-overlapping second control. Ditto, .Left and .Width properties for horizontal placement.

I ended up writing a set of subroutines to compute the four corners of any control, and to place a control in-line with another control but not overlapping, stuff like that. You need a couple of primitives. One routine defined a box in which to put controls - I used a data structure for that, and it could be organized along the lines of the quadrants that you described. Yes, in essence I was doing the same thing as layouts - but not REALLY the same, since I could dynamically control things within the boxes.

I had a subroutine that if you defined a box, it initialized the box data structure including direction codes as to which way to "auto-fill" the box. Another function would take a control and an initialized box and place that control inside the box at the first place where it would fit (or return an error code if it would not fit). Other functions resized the controls before placing them.

One issue that I had to consider is that depending on screen resolution, I found some visual anomalies that detracted from the appearance of the product in question. The edges of two adjacent controls would interact unless I left a 1-twip "gutter" between controls (on all four edges).

You just have to remember that Access places stuff top-down and left-to-right, so the 0,0 position on the form is upper left. Also, knowing the form height and width seems like it should be all you needed to know to get started, but forms have sections (or at least CAN have them) so you need to watch out for section position issues.

If this is not useful to you, I'll back off. If you need more specific answers, I'll tell you what I can within the confines of the non-disclosure agreements that are ALWAYS a part of working with the government. Descriptives are OK. Actual code - not so OK.

Referring back to F. Scott Barker. He uses a page break control to effectively give the form an extra page. He keeps extra controls within this page. I'm wondering if this is something you could take advantage of.

By the way, my experience of searching Safari for information related to MS Access isn't particularly good when trying to find something which is a little out of the ordinary. I have more success with a general search of the Internet using the Google advanced search feature. I have mentioned Google advanced search before, so I imagine you have seen it. However I have included a link just in case you haven't.

Google Advanced Search
https://www.google.co.uk/advanced_search


Google Advanced Search of AWF (Access World Forums) Only
https://www.google.co.uk/advanced_s...en&cr=countryUK|countryGB&safe=off&as_qdr=all

thank you both for putting in the legwork, it is much appreciated.

@Unc - I'm referring to the layout 'facility' available from 2007, a reference from 1999 kinda predates that however as you surmise I am very familiar with the concept referred to, although I now use collections rather than arrays.

Also the layoutID - is what I was referring to - if there is an ID, then it must be part of something - a collection, an array, perhaps a dictionary? And if so, can it be manipulated?

@Doc - this is what I already do, and like you I find the layouts restricting - in an address 'block' for example, you don't necessarily want the postcode control to be the same width as the other controls, but you do want it to be left aligned and it to maintain its position in relation to the other address controls if they are moved. And like you say there is a fair amount of code.

Kind of in line with windows terminology, I think of my control groups as being tiles and when a form opens code parses through the controls collection and compares top/left properties with the tile property (hard coded for the form- controltop<formheight/2, controlleft<formwidth/2 means the control is top left sort of thing) and adds them into a tile collection.

The problem has been visualising that - if I move a control slightly it can end up in the wrong 'tile'. So I was thinking layouts would provide a visual aid to how it would work and perhaps simplify (or at least reduce the amount of) the code - move the layout rather than all the controls.

On visualisation I hadn't though about using a hidden box control which you mentioned. Visible in design view but not in normal open view. It simplifies my open form code to populate the collections. So many thanks for that suggestion. Just throw the controls over the relevant box, correct the tab order if required and a routine to line them up nicely.

As I said, I'm just reviewing my code to see if I can make it better, easier to use etc. The box idea is one that will do that. So thanks again.

I'll leave the thread open for now - I would like to track down where the layout 'object' is and investigate its potential but suspect it's limitations will still remain.

CJ,

When I search this forum, I note that you have answered most questions re forms, resizing, controls etc., so I have little to offer -- I think you have written/discussed most approaches/concepts.

I am going to provide a link to an article by AD Tejpal who was a member of a user group I was on. I don't know if it's relevant, but AD certainly had many posts and examples, and I was always impressed with his posts.

His article is at RogersAccessLibrary here. He has written many articles on MS Access/vba.

I hope this is helpful.

Thanks JDraw, I'll take a look

CJ,

Here's a link that may be useful (Form resize). I tried to find this earlier - I knew I had it book marked-- but couldn't find it or remember any "memory aids" or details. Anyway, this may have some use to you.

It is from PDTech.co.uk.

Thanks JD - I've being doing something similar for years with a similar technique. What I am actually after is refining a relaying out of the form once certain resize limits are reached.

The issue is if you take an 'average' form on an 'average' PC monitor you can design for the smallest version.

But with the introduction of tablets, three things happen.

a) screen sizes become much smaller - typically say 1/2 the size of an 'average' PC monitor in terms of resolution
b) controls need to be bigger because of the larger footprint of a finger compared with a mouse. Although styluses refine this they still have a largish footprint
c) due to the small screen size/relative high resolution, font sizes typically need to be larger.

The standard approach is to design for the smaller screen - but with my clients I might have 10 people using a normal monitor and 2 using tablets. And a form that is now twice as big in both directions looks a bit ridiculous for the 10 users. OK, users can reduce the form window, but you then end up using tabs (which I don't particularly like) or having a scrollable form which is unnecessary on a PC monitor.

My objective is to be able to relocate blocks of controls depending on the screen size/resolution to provide a form which works well for both pc and tablet users. Tablet users are used to scrolling (particularly vertically) and also have the benefit of flick scrolling, pinching etc. They are also probably not using the tablet for intensive input but more for information and occasional input. Scenarios within my client base include walking the warehouse for stock taking, sitting in a meeting, tablet by each personal care station (hairdressing/beauty).

In summary, the 'flow' of a form on a tablet is different from a pc monitor. I could design two forms, one for each device but prefer a single form which configures itself.

I have a routine that works, but I am just seeing if I can make it better and make use of access functionality I have not researched up until now.

I do appreciate the suggestions tho'

Many thanks

One of the worst aspects of resizing for screen-size variability across platforms is that the fonts have to be scaled. The text that was perfectly readable on my 19" or 23" monitor now is almost not visible on a smaller screen (which I simulate with windowing). This would not be a terrible problem except that the ability to know how much space is required to display a text string is not supported for FORMS, only for REPORTS. You could Google that yourself for "computing size of a text string" as a topic.

I might offer the suggestion that if you know the number of characters to be displayed and if you use a NON-proportional font (anything in the Courier family comes to mind), you can compute the size of your string (admittedly, a bit tedious to do so) by remembering that one point (in font sizing) is 1/72nd of an inch, and one twip is something like 1/1440th of an inch - so it is like 20 twips per point. The fonts are laid out for the old 4x3 format screens, so an 8-point font is 8 points high, 6 points wide (or close to that).

If you went with a proportional font, the point height is usually the same but the width is less, so your computation would suggest more horizontal space is required than is really the case. Add in fonts that do "kerning" and horizontal space requirements shrink even more.

CJ_London said:

From my investigations, If (using vba) I move a single control in a layout with multiple controls, all the controls move, but only vertically, not horizontally. So a halfway step.

To address the lack of horizontal movement, I'm wondering if the layout properties can be accessed, but I can't find them. I've looked in form properties and tried to find an appropriate collection but to no avail.

I've looked on line using keywords like 'form collections', 'properties', 'layouts' etc but perhaps not found the right keyword.

Any suggestions?

Click to expand...

You need to move the first (top or left most) control depending on the layout type.

@Doc: I found a thread a long time ago which provided some good code to modify the size of a control depending on font size and number of characters, I've adapted it so I get a readable font size depending on screen size/resolution. It referenced this at Stephen Lebans website http://www.lebans.com/textwidth-height.htm

I also have a routine which translates captions into another lanquage - the translation can be longer or shorter than the English equivalent so it caters for that as well - particularly useful for continuous forms.

@static: Got it! I was moving the text box, not the associated label

CJ_London said:

Unc - I'm referring to the layout 'facility' available from 2007, a reference from 1999 kinda predates that however as you surmise I am very familiar with the concept referred to, although I now use collections rather than arrays.

Click to expand...

I was pretty sure I wasn't showing you anything you didn't already know however I thought it worth documenting...

The results I got back from safari Books Online (a search of nearly 100 MS Access books, were basically books pre 2007 and took me to information about the printer object. I couldn't find anything in reference to programmatically editing the form layout properties. Nothing! Not one book even hinted at it. The only thing that did pop up once was "LayoutID" which I assume lets you know if a control is in a particular layout.

I might get different results if I was to change my search criteria so it's not 100% but it does seem to indicate that no one else has tried to manage the form layout properties directly.

I could assume that it's not possible! But I from past experience recording your assumptions on a public forum is not necessarily a good idea... so I didn't say this...

Hi Unc

Thanks for continuing the search. The layout 'object' does seem to be very obscure, like you I've not been able to find anything.

Static has corrected me for why I couldn't move layouts horizontally in vba and Doc has suggested a more flexible alternative using a hidden box control

What I can do is loop through the controls and create layout collections based on the layoutID and layout properties (or box collections based the control position/size properties relative to the box for Doc's suggestion) which I can then manipulate, rather than using an existing layout collection.

Both of the above suggestions means I can simplify what I am currently doing to populate the collections and if I go the layout collection route, simplify the code for moving controls. But as Doc points out, the layouts are less flexible.

I haven't had a chance to implement either solution yet, I need to look at the real world situation as to which will be more effective but suspect I will end up developing two solutions

When I'm done, I'll see if I can put a simple example together

But for now I think it is time to call time and say this thread is solved

Once again, many thanks

CJ

Don't forget anchors

I haven't - but they all relate to control sizing in relation to form size rather than position.

When I'm done, I'll see if I can put a simple example together

Click to expand...

CJ, I think that would be helpful to many.
Thanks in advance.

Good luck.