How to change the height of the 'detail' part of a form?

[sueb]

I know how to set this Property, but what I'm really asking is how I can set it to something smaller than it wants to be.

On a continuous subform, I have a set of fields (all at the bottom of the Detail section) that normally I want to be invisible. On the click of a button, I want to set all their Visible properties to True.

So when the fields are invisible, I'd like to set the height of the Detail section to exclude the "real estate" reserved for the invisible fields, and then, on the click of the button, reset the height at the same time that I set the visibility properties.

Can this be done?

[Rabbit]

You can if you first move all the controls out of that area. Then move them back before you make them visible.

[sueb]

Rabbit, move them where? Do you mean just to a part of the detail that will be visible? Or, maybe, to the footer and then into the detail?

[Rabbit]

To a part that will be visible. Probably from whatever coordinate they're at to (0,0). You will, of course, have to keep track of their old coordinates so you can move them back when you need to.

[sueb]

So I thought that just setting the Top property would do it, but that did nothing. What Property do I set? And what are the units? inches?

[sueb]

Maybe I should mention that I'm really just trying to move a single Tab Control, but it looks like all the fields on all the tabs are sort of "stuck" and prevent the Tab Control from moving freely. Does that even make sense?

I am able to make everything invisible by just setting the Tab Control's visibility, so I thought that I could move the Tab Control and all the fields would come right along.

[Rabbit]

You'll have to bring all the controls up, then bring the tab control up, and finally shorten the height of the tab control.

[sueb]

Wow, I really have to handle each control and label individually? And by "bring up", I'm assuming you are talking about setting the Visible and Top properties? I sort of need specific words.

[Rabbit]

Yes, that's what I mean. You could, conceivably, store all this information in a table and just loop through it. That way, if you add, rename, or delete controls, you don't have to constantly rewrite your code. The table could store the name of the control, the original top, and the "hidden" top.

[sueb]

Since I've never done anything like this, I wonder if you'd be so kind as to post an example of what this would look like. Thanks!

[Rabbit]

It looks like you figured this out in a different thread?

[sueb]

In that thread, someone posted the code to iterate, but I am very interested in your "table" idea, so maybe you could show me that?

[sueb]

And I still haven't figured out how to "move" the tab control and its contents, all in one piece, to, say, the FormFooter and back, so that I can change the height of the detail section.

Any help on that?

[Rabbit]

In pseudocode, basically you would do this.

Dim x As Recordset
Set x = DoCmd.OpenRecordset("Table Name")
 
Set top of tab control to 0
 
Do Until x.AtEndOfRecordset
   Me.Controls(x!NameOfControl).Top = 0
   x.MoveNext
Loop
 
Set height of tab control to some small number
Make tab control invisible
Set height of detail section to what you want

You don't have to move them out of the detail section.

[NeoPa]

Essentially Sue, the size of any section is always constrained to be at least large enogh to include all the items within it. For a form, the width is always as wide as the widest section and the height of any section is determined by the controls within that section.

Thus, if there are controls at the bottom, whether or not they are visible, the section will be high enough to encompass them all completely. This is true both for when designing the form via the interface, and for when making changes on the fly in the code.

Tab controls are something else again.
It's not uncommon for controls to be added, with the idea that they are added onto a page of a tab control, but in realitity to the section underneath. This is something to look out for when having trouble controlling tab controls.

[Adam Tippelt]

One extra thing to note is any size or location properties that you try to change with VBA, such as the Top value, must be done using a measurement of "twips" as opposed to centimetres.

You can do a simple search for centimetre to twip converter to work these values out.

So if you wanted to change a control so it was only 5cm from top, the code would look something like this:

Me.myControl.Top = 2835

Hope that helps.

Adam.

[NeoPa]

While we're on 'other points worth bringing up', I found out quite recently (a couple of years back at most) that you could actually change the current size of a form from code using its Move() method. I'd struggled manfully for ages to find a way to resize (as the Height and Width properties are both R/O). You can still only make the size one such that all controls fit completely within it, but nevertheless the concept is doable (even if the actual method to use is far from obvious).

[sueb]

I do understand about making sure all the controls are actually on their tab page. In fact, I know that even more surely precisely because when I try to move my tab control, and the contained controls won't move, the tab control's bottom stays exactly where it was.

Isn't there a way to move the entire tab control (and all its contents) at once? It would be great if someone could tell me how to move it to the footer, because the footer will allow me to turn it off (even if it contains controls), and then I could move the tab back to the detail section when I needed to; but all this would work only if the "contained" elements just rode along nicely.

[Rabbit]

Moving a control from one section to another is a design only function. You would have to put the form into design mode, move it, put it back into view mode, and then move back to the record you were on.

[sueb]

Ah. I see. Okay, then, I guess what I need is advice about how to move the tab control that I have (which contains a boatload of controls), all in one piece so that it retains its size/shape. Once I can move it, I know I can make it inVisible, and then resize the Detail section appropriately.

[Rabbit]

To do this, refer to post #14 for pseudocode. But in short, set the top of the tab control. Move all the controls in the tab control. Set the height of the tab control.

[NeoPa]

Just a thought (so I'm not certain it will work) but would cutting (not copying) and pasting of the tab control work?

[Rabbit]

That would have to be done in design mode wouldn't it?

[NeoPa]

I'm not absolutely certain. That's certainly what I was suggesting, but such things are often supported in code too. I would have thought doing it in design mode made more sense anyway, whatever the capabilities of the code are.

[sueb]

Just so it's clear: I need to be able to make this change at the request of the user.

[NeoPa]

SueB:
Just so it's clear:

I'm afraid that clarifies nothing for me Sue. What did you mean to indicate?

[sueb]

Maybe I don't know enough about when design mode is available to me, but I assumed that, once I deploy a front end, and the user is actively using it, design mode would not be available to that user. (at least, I would certainly hope that my users don't find themselves in design mode--they wouldn't have the faintest idea what to do!)

[Rabbit]

If they have the full version of Access, and they are not using a runtime version of the database, they have access to design mode.

If the front end is stored locally on their drive as opposed to on a network location, it should not be a huge problem to use design mode if you want to.

[sueb]

Okay, I guess I really don't understand. Are you saying that design mode is something I can code right into the procedure for the users' button? If that's so, then I have absolutely no idea how to execute design commands from code.

[Rabbit]

I think you can but I've never had to do it myself.

[NeoPa]

Design Mode is generally available to designers (such as yourself) when designing the various forms and other objects in your database. However, opening an object in Design Mode can also be done using code. It's less common certainly, and comes with a few gotchas that you should be careful of, but the option is there.

Design changes may be made by code when the object (form) is open and in normal use, but such changes are session level. They only persist for the duration of the current session and would not effect another user who had the same object open at the same time. If the object is opened in Design Mode though, and changes are made then the object is saved, this new version becomes the object for future uses. It is very rarely a good idea to work that way, but the facility is available should you choose to (If you hadn't got it before, I certainly wouldn't recommend using this facility).

Sue, You said before :
Just so it's clear: I need to be able to make this change at the request of the user.
I'm still not clear what you meant by that. Did you possibly mean you wanted the user to be able to make such a request of you personally and you would design it into the database? That's what the wording implies.

If you want to design the database such that a user could choose to move the tab control and its contents to another section on the click of a button then that's something else again.

As I say, I'm still not sure.

[sueb]

NeoPa, what I need is the latter: in other words, I want to put a button on a form that displays an otherwise-invisible tab control.

[NeoPa]

From that last comment the solution is easy. Unfortunately, I believe we've already been there and you weren't happy because you needed the tab control and its contents not even to be there as invisible on the form due to the constraints which that put on the size of the section it was contained within. As such, this only seems to leads us around the same circle again.

At one point you were attempting to move the tab control and all its contents into another section. How far did you get with that and was it ultimately helpful?

[Mihail]

Hi all !
Maybe my english is not enough to understand the problem. So sorry if my idea can't work.
Sueb, take a look to InsideHeight command (Me.InsideHeight = ....). I think that is the answer to your problem IF you use Overlaping Windows. For Tabbed Documents do not work.

[sueb]

Mihail, what version is that attachment? I have 2003, and it can't open it.

[Mihail]

Is 2007.

Look: Create 2 buttons (Command1 and Command2) then use the CLICK event for each one.

Private Sub Command1_Click()
    Me.InsideHeight = Me.InsideHeight + 100
End Sub
 
Private Sub Command2_Click()
    Me.InsideHeight = Me.InsideHeight - 100
End Sub

Do not forget: Overlapping windows for your forms.
Hope the code work in 2003. I can't test it in this version.

[sueb]

Mihail, also I don't know what Overlapping Windows is. Can you please explain?

[Mihail]

I try to explain using my poor English.

I do not know if "Overlapping Windows" exist in 2003 version.
If you open more forms (2, 3, 4 .... ) in the same time you can see as many windows as opened forms (as usual windows in Windows operating system) but using only the Access window area.

On the other hand you can set the form to be as large as the Access window. In this case you'll see only one form at a time. This is NOT "Overlapping Windows" (2007 say that is "Tabbed document").

Maybe someone else wish to explain better using a true English :)

[Adam Tippelt]

Basically Microsoft has done for Access 2007 what browsers have done to internet pages - the windows now have tabs to allow the user to easily switch between opened forms within the same Access window, so multiple forms can be open and accessed at once.
Tabs can however be turned off in the database settings if you want to hide them from users.

[sueb]

I see. No, I don't think that 2003 has tabbed windows. What I've done with some of my forms and reports is to "free" them from the Access window area by making them pop-ups. That seems to work pretty well.