Print Preview Toolbar in A2K7 Runtime

[David W. Fenton]

I've never distributed a runtime app, ever, and am somewhat puzzled
about how to preview a report in the runtime and allow the user to
print it (without them hitting Ctrl-P). I can see the print preview
menu not displaying by default in the runtime, but when I ask for it
explicitly, it doesn't display. Nor does a custom toolbar that I've
created. Is this because I've turned off the ribbon?

I don't want the ribbon -- it looks hideous and unnecessarily takes
up a bunch of space that is of no value to the user. Am I forced to
have the ribbon just to get print preview? I thought old-style
toolbars worked fine in A2K7?

 

[Albert D. Kallal]

when I ask for it
explicitly, it doesn't display.

I assume by the above you mean you specify the custom menu bar in the
report. If you using an accdb, and have hidden the ribbon then specifying
the menu bar in the report shows nothing (because custom menus bar shows as
an "ad in" on the ribbon as a seperate tab)

If you're using an mdb/mde format file, then in that case you CAN actually
get a custom menu bar to display for reports. This ONLY works if you're
actually showing a main menu bar in your application (this simply means you
have to specify a menu bar for the main application part, then any menu bar
specified in a report should show its custom menu bar).

Nor does a custom toolbar that I've
created. Is this because I've turned off the ribbon?

I should probably read a bit farther into a post before I start answering!
Your assumption is correct (however keep in mind that you can turn the of
the ribbon off, and if you specifyed a main menu bar in the access options
settings and it is a mdb/mde, then a menu bar setting for report WILL show
correctly (in other words you have to do both of these things before this
will work).

I don't want the ribbon -- it looks hideous and unnecessarily takes
up a bunch of space that is of no value to the user.

You could consider using the ribbon in what I call auto hide mode. When the
ribbon is auto hidden, when you preview a report the ribbon does not take up
valuable screen real estate. And, when you go to use the ribbion it will
appear "over" the reprot.

I just uploaded two samples that show both of the above scenarios for you.

You can find them here:

try both...you might actualy like the auto-hidden ribbon...

autohide ribbon example here:
http://www.members.shaw.ca/AlbertKallal/msaccess/AutoHideRibbonWordMerge07.zip

mdb example that works in 2007 with custom report menu bar here:
http://www.members.shaw.ca/AlbertKallal/msaccess/07hide.zip

web page link to above two examples:
http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm

 

[Allen Browne]

That's strange, David.

Just tested this, and I get 3 ways to print the report:
- built-in ribbon
- my custom toolbar (on Add-Ins tab of ribbon)
- Print on the Office button.

So I guess I've set up something differently than you.
FWIW, my test set up was:
- Custom menu and toolbar (no custom ribbon.)
- Built-in menus not blocked.
- Report opened in Preview (not the new Report or Layout views.)
- Printer installed. (Suffered crashes without a printer.)
- A2007 SP1.
- Front end is an A2000 MDE (gets named as an ACCDR.)
- OS is Vista (under Virtual PC.)

 

[David W. Fenton]

I assume by the above you mean you specify the custom menu bar in
the report. If you using an accdb, and have hidden the ribbon then
specifying the menu bar in the report shows nothing (because
custom menus bar shows as an "ad in" on the ribbon as a seperate
tab)

No, I'm not using ACCDB, but an MDB.

If you're using an mdb/mde format file, then in that case you CAN
actually get a custom menu bar to display for reports. This ONLY
works if you're actually showing a main menu bar in your
application (this simply means you have to specify a menu bar for
the main application part, then any menu bar specified in a report
should show its custom menu bar).

Ah. This is a one-form application with one report and has no actual
need for a menu, so it doesn't have one. I guess I have to add an
EXIT menu (bloody stupid, that).

You could consider using the ribbon in what I call auto hide mode.
When the ribbon is auto hidden, when you preview a report the
ribbon does not take up valuable screen real estate. And, when you
go to use the ribbion it will appear "over" the reprot.

This is not an Access 2007 application. But it will be running on a
kiosk with the A2K7 runtime. Thus, no ribbon. I don't even own A2K7,
and don't want to do so, in fact. I have no desire to create an A2K7
app, nor get involved with ribbons. This app has absolutely no need
for such fills.

The key is obviously that my app has no main menu (because it
doesn't need one), so I'll just add a useless main menu to get the
print preview toolbar.

Grrr. Very, very stupid design, in my opinion.

 

[David W. Fenton]

So I guess I've set up something differently than you.
FWIW, my test set up was:
- Custom menu and toolbar (no custom ribbon.)
- Built-in menus not blocked.
- Report opened in Preview (not the new Report or Layout views.)
- Printer installed. (Suffered crashes without a printer.)
- A2007 SP1.
- Front end is an A2000 MDE (gets named as an ACCDR.)
- OS is Vista (under Virtual PC.)

Albert identified the issue -- I have no main menu for my app, since
it's a single-form app with one report, and a menu adds absolutely
nothing to the UI. I'll be forced to add one with EXIT on it, I
guess, as that's the only possible function the menu could have (the
single form is a wizard-type form, so menus don't apply to any of
its functionality).

I guess I understand *why* it works out this way, but it doesn't
strike me as a good design.

 

[Albert D. Kallal]

This is not an Access 2007 application. But it will be running on a
kiosk with the A2K7 runtime. Thus, no ribbon. I don't even own A2K7,
and don't want to do so, in fact. I have no desire to create an A2K7
app, nor get involved with ribbons. This app has absolutely no need
for such fills.

My suggestion would be to get your hands on a copy of the a2003 runtime
(or whatever version of access you are developing with). I not 100% keen on
the idea of developing in one version of access, but deploying to another.

Your mileage may vary on this issue, but I was developing in a2003 for a
client that was using a2000. I was REALLY amazed at the number of threading
and conditional formatting issues that arose when I moved my software to
2000. Hence, from 2000 to 2002, then to 2003..a LOT of little quirks were
fixed. If I had been developing in a2000 then some of the problems would
have showed up during testing and I would have worked around the problems.

I finally wound up moving that client to the a2003 runtime and things are
now bulletproof stability wise.

Access 2007 had a LARGE AMOUNT code changed as compared to the previous
version of access. I would either upgrade to a2007 (it only $109), or
try to find a runtime for the version you are developing with now.

 

[David W. Fenton]

My suggestion would be to get your hands on a copy of the a2003
runtime (or whatever version of access you are developing with). I
not 100% keen on the idea of developing in one version of access,
but deploying to another.

It's a one-form, one-report app. If an MDB developed in A2K3 can't
run reliably in the A2K7 runtime, then the Access development team
has major problems.

Your mileage may vary on this issue, but I was developing in a2003
for a client that was using a2000. I was REALLY amazed at the
number of threading and conditional formatting issues that arose
when I moved my software to 2000.

I just did a conversion from A97 (an app that began life in 1997) to
2003, and it was a nightmare, precisely because of timing issues. In
other words, events don't occur in precisely the same order in A2K3
that they did in A97, and it took me a lot of work to iron out the
problems.

But that was a *very* complex application (not particularly complex
in terms of forms/reports, but with two main forms that were
extremely complex). Compared to what I'm working on right now, it
would be like comparing the space shuttle to a Yugo.

Hence, from 2000 to 2002, then to 2003..a LOT of little quirks
were fixed. If I had been developing in a2000 then some of the
problems would have showed up during testing and I would have
worked around the problems.

Jet 4 is supposed to be a native format for A2K7.

I finally wound up moving that client to the a2003 runtime and
things are now bulletproof stability wise.

Access 2007 had a LARGE AMOUNT code changed as compared to the
previous version of access. I would either upgrade to a2007 (it
only $109), or try to find a runtime for the version you are
developing with now.

There is absolutly nothing complex enough in the app that I'm
developing that would run differently.

In the end, I did get it working, but only after much futzing
around. For one, the custom toolbar I made for print preview had the
CLOSE button on it (grabbed from the built-in print preview
toolbar). It worked a treat in A2K3, but when clicked in the A2K7
runtime, nothing happened. I ended up creating a macro to close the
report and this worked reliably in both. The only remaining
annoyance was with positioning the menu and toolbar, but I finally
got that worked out after much fiddling around.

One last bit:

You gave me the advice to hide the ribbon, but that conflicts with
startup settings if you have "show builtin toolbars" turned off.
With that setting OFF, hiding the ribbon triggered an error,
something like "cannot find toolbar 'ribbon'". Looks like turning
off the builtin Access toolbars in the startup settings would have
done the job without any coding.

 

[James A. Fortune]

In the end, I did get it working, but only after much futzing
around. For one, the custom toolbar I made for print preview had the

BTW, I am noticing that getting pre-A2K7 databases to convert even to
the non-runtime/normal A2K7 cleanly is going to involve many more code
changes than the code changes for any prior conversion. I'll either
post the issues I discover or keep a list so that others can be made
aware of some code patterns from prior versions that will not convert
cleanly to A2K7.

James A. Fortune
(e-mail address removed)

 

[Albert D. Kallal]

One last bit:

You gave me the advice to hide the ribbon, but that conflicts with
startup settings if you have "show builtin toolbars" turned off.
With that setting OFF, hiding the ribbon triggered an error,
something like "cannot find toolbar 'ribbon'". Looks like turning
off the builtin Access toolbars in the startup settings would have
done the job without any coding.

Interesting...thanks for sharing that. I not really tried the above, but it
makes some sense. I tend to "hide" the ribbon by using a custom ribbon, and
not that docmd as:

DoCmd.ShowToolbar "Ribbon", acToolbarNo

At any rate, as you said, since this is not a real complex app, then using
a2007 is not a problem.

And, I should point out that a number of regulars (Tony for example) here
that do deploy a2000 and 2002 "mde" files with the a2003 runtime without any
problems. So, it is common to deploy applications to different versions
including
the runtime.

I should explain that much of my references to "timing" issues etc. is more
of a issue when the code base of ms-access has CHANGED a lot. That occurred
when we went from a97 to a2000. They added ado, adp projects, uni-code,
changed the ide to a split ide and used the vb6 one etc etc etc etc.

This huge change also sure as the heck showed up as buggy product on our
side. However, to be fair, a2000 does run well now if it is fully patched.

So, a2000 to a2003 simply showed a nice steady progress in stability. in
fact, a2003 was the FIRST version of access I regularly deployed to clients
without any patches whatsoever (and I continue to do so now)

In fact when having a coffee with a lead ms-access developer at the Redmond
campus, he told me they changed a significant amount of code in a2007. This
is amazing because in reading posts here, and in my own experience is that
2007 has been VERY stable. That kind of stability does not usually occur
until product had a good many updates and versions.

So, my point about running previous versions was really mostly an issue when
the particular version of access had a LOT of changes. Just a warning flag,
not a really big deal. You likey will be just fine using the a2007 runtime.

 

[David W. Fenton]

In fact when having a coffee with a lead ms-access developer at
the Redmond campus, he told me they changed a significant amount
of code in a2007. This is amazing because in reading posts here,
and in my own experience is that 2007 has been VERY stable. That
kind of stability does not usually occur until product had a good
many updates and versions.

I wonder if we aren't hearing reports of problems because developers
are just not using Access 2007?

 

[Larry Linson]

I wonder if we aren't hearing reports of
problems because developers
are just not using Access 2007?

That would certainly reduce the number of problems encountered and reports
of same. You won't, for example, see me making any problem reports about the
2008 model Rolls Royce. <GRIN>

None of my clients, and few participants in the Access Special Interest
Group at my User Group, have moved to Office 2007.

Larry