A2007: Overlapping or tabbed
in [Help]
|
Prev: DLOOKUP being a PIA
Next: Access 2010 forms
From: Albert D. Kallal on 1 May 2010 18:17 "Banana" <Banana(a)Republic.com> wrote in message news:4BDC644A.2030107(a)Republic.com... > On 5/1/10 8:59 AM, Lars Brownies wrote: >> 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 > > 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. 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(a)msn.com
From: Lars Brownies on 1 May 2010 18:57 Thanks Banana, Albert, for valuable info! Lars "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> schreef in bericht news:pM1Dn.60668$4W2.12473(a)newsfe01.iad... > "Banana" <Banana(a)Republic.com> wrote in message > news:4BDC644A.2030107(a)Republic.com... >> On 5/1/10 8:59 AM, Lars Brownies wrote: >>> 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 >> >> 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. > > 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(a)msn.com
From: David W. Fenton on 1 May 2010 20:04 Salad <salad(a)oilandvinegar.com> wrote in news:6YKdnQYbn-Bbw0HWnZ2dnUVZ_qednZ2d(a)earthlink.com: > Access has had tabbed windows since I started using Access in > 1997. 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/
From: Arvin Meyer on 2 May 2010 21:45
"Lars Brownies" <Lars(a)Browniew.com> wrote in message news:hrhj52$17eg$1(a)textnews.wanadoo.nl... > 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? 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 |