The tabbed windows option in Access 2007 is quite a different concept than
the overlapping windows in earlier versions. I'm curious about the
experiences with the tabbed windows. Is it used a lot or do most developers
stick with the overlapping windows? Any pitfalls?

Thanks,

Lars

Lars Brownies wrote:
Access has had tabbed windows since I started using Access in 1997.

Could you be more verbose on what you mean by overlapping windows?

Is an overlapping window similar to having a main form and pressing a
button to open another form so you have 2 forms open at the same time?

With 'overlapping windows setting' checked you can see two open forms
simultaniously, like I was used to in A2003. With the tabbed windows setting
checked, you can have one or more forms open, but only one of them can be
visible at a time. The other forms are hidden, only their formtabs are
visible.

Lars

"Salad" <salad (AT) oilandvinegar (DOT) com> schreef in bericht
news:6YKdnQYbn-Bbw0HWnZ2dnUVZ_qednZ2d (AT) earthlink (DOT) com...

On 5/1/10 10:03 AM, Salad wrote:
I think you may be talking about something different because it only had
that feature in 2007 and later. Tabbed windows simply means that when
you open two forms, you only have one form visible and taking up all
screen inside the MDI window but you can switch between two forms by
clicking on the tabs which are lined up at the top of MDI windows. Kinda
similar to how some browsers have tabs.

This is what we have had since the inception of Access.

On 5/1/10 8:59 AM, Lars Brownies wrote:
I personally prefer tabbed for development - it makes for much easier
workflow and helps keep the clutter clean by giving me tabs to switch
between various open objects without having to hunting for it.

However, that does not necessarily apply when using it as an end user. I
think overlapping windows tend to make more sense to the end user. A
part of reason for this is that because most of time they'll be working
only one active form at a time, so having tabs would be kind of waste of
space and offers nothing in functionality to them not to mention
possibly introducing more opportunities for bus or weird behaviors as
the users switch between forms and generate unexpected side effects that
code didn't anticipate.

"Banana" <Banana (AT) Republic (DOT) com> wrote

I agree 100% on the above. The above is much the same conclusion I made.

I find during development, tabbed works very well. I don't have to position
the form, don't have re-size the form. And in fact during development I
USUALLY did work on a form maximized. So during development I don't have to
max forms, I don't have to re-size them. And I then can display the property
sheet docked on the right side (out of the way) by using alt-enter. So I
never messing to move the property sheet out of the way - I really like
this. After done then alt-enter closes the property sheet (I do this so then
ctrl-w at that point will then save the form - this means less mouse dance
between keyboard). This layout with nav pane on left side, the form in the
middle and the property sheet on right supports wider screens very well
indeed.

Many years down the road when I start actually building wider Access forms,
then this layout might not have enough room for the Access form in design
mode in the middle of the screen - so this might become a bit of a problem.
I suspect by that time all likely get the hang of how to do correct control
anchoring that we received in access 2007. This feature means the controls
actually automatic re-size when the form re-sized. For web developers they
are used to this type of re-sizing every day when one re-size their browser.
Even in Access standard client forms they can benefit much from controlling
anchoring that we received in access 2007. This means we can have controls
re-sizing in a form without any third party add-ins.

The tabbed mode is more important when you're building and designing web
based forms. I can't really say it's a bug, but if you try to design a web
based form then resizing is defined by the grid layout. If you expand the
rows of grid in a web based form (to make the form larger) then the form
does not reflect this resizing until you close and save the form and reopen
it WHEN in window mode. So, as a result of this, then it is next to
impossible to do web based development unless you use the tabbed mode.
Thus, it strongly recommended for WEB based forms development, you're pretty
much relegated to using mode.

The only exception to the above tabbed mode is if you're going to create a
dialogue WEB based forms (and in fact regular non web also). In these two
cases then I flip access into overlapping windows. I then can re-size the
form correctly (you'll still have to insert grids to lay it out and re-size
web forms,and you have to close + then re-open the form to see the re-size
change). But this process at least lets you judge the size of the resulting
form. Whe done, you then flip back into tabbed mode.

I should point out instead of exiting Access and reentering it when you
change the window mode (and you also get a prompt warning into that affect
that you must exit Access, and then reenter it), I simply placed a compact
and repair button on the qat. So when a change in settings where Access
requires a restart, I just do ONE mouse click on the qat and it's the same
thing as if I exit and Access and re-launch Access.

This compact and repair button trick on the qat also applies when you doing
ribbon development. After you modify a custom ribbon in USYSRibbons table.
You then simply click on the compact and repair button on the QAT and it's
almost like a ribbon compile button to me. In fact I don't even close the
current table record with XML in it. I simply click on the compact and
repair button to close the current record I am editing with that xml in it.
Thus with one click the table + open record is closed, and the ribbons are
then re-loaded all with one mouse click.

Regardless of what you're doing, in all cases a one button click is a heck
of a lot faster and far less work than shutting down Access and restarting
it to reflect some change that requires a restart.

So, I find tabbed mode works VERY well for development.

I find tabbed development mode works great even for previous existing
applications because I don't move around forms or have to max them. I never
move them around or have to mess with re-sizing. However for WEB based
development tab mode not only helps, it's pretty much a requirement.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

Thanks Banana, Albert, for valuable info!

Lars

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> schreef in bericht
newsM1Dn.60668$4W2.12473 (AT) newsfe01 (DOT) iad...

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:6YKdnQYbn-Bbw0HWnZ2dnUVZ_qednZ2d (AT) earthlink (DOT) com:

Not in the sense that A2007 has tabbed windows. All A97 had was a
tab control. The tabbed windows are at the next level up in the
hierarchy, as a navigation replacement for the MDI.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Lars Brownies" <Lars (AT) Browniew (DOT) com> wrote

Tabbing non-related windows is even more disconcerting than tabbing separate
non-related windows. I never use it for development. With Access 2007, I
hide the database container (Navigation Pane) the same way I did with
earlier versions.

--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.accessmvp.com
http://www.mvps.org/access