When I click on a new report I want the Print Preview Tab to become
visible AND have the focus.

I can't find a way in vba to put the focus on the tab w/o using
sendkeys.

Anyone know? It's obviously used by Access' internal mechanisms
somewhere but doesn't seem like that functions are exposed for us
users.. er ah 'developers'.

On Aug 2, 4:49*pm, "christianlo... (AT) yahoo (DOT) com"
<christianlo... (AT) yahoo (DOT) com> wrote:
When Microsoft says "developers," they are really thinking of .NET
developers, not Access developers :-).

See:

http://groups.google.com/group/micro...5c265597d62a6b

Maybe it's possible to use the unmanaged API from Access to gain
control of the Ribbon's buttons. I believe there's also an API just
for the Ribbon.

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com

OData is the web-based equivalent of ODBC, OLEDB, ADO.NET and JDBC.
-- http://msdn.microsoft.com/en-us/data/ff478141.aspx

On Aug 10, 3:07*pm, "James A. Fortune" <CDMAPos... (AT) FortuneJames (DOT) com>
wrote:

I got it working today. Thankfully I was able to rip code from here:

http://www.wordarticles.com/Shorts/R...bonVBADemo.php

RibbonDemo.dotm

It never ceases to amaze me how impossible Microsoft makes simple things.

What a complete royal pain this turned out to be. I've searched a long
time for this and wasted countless hours for something so damn simple.

It also amazes me how few people notice this is a problem. Good grief.

Also, if anyone can figure out how to reduce the hundred lines of code
to just a few steps to set the tab focus - I'd love to see it. As is,
the routine iterates over the IAccessible Property Page, then the
Tabs, then the controls in the tabs it seems. From there to set the
focus it call a 'do default action' from the tab using an index into
the enumerated tab object list. It'd be nice just to be able to pass
the index w/o iterating through the whole collection to get the object
list but I've tried and couldn't get anything to work.


Thanks

wrote in message
news:b9b56299-6091-448c-8d24-ebfcf8037c58 (AT) y24g2000yqb (DOT) googlegroups.com...

What version?

Furthermore, when you say "new" report, are you talking about creating a new
report that is THEN to be used for a considerable amount of times over and
over?


Access 2010 and the new ribbon does allow VBA to set what tab is active.
(access 2007 does not have this ability)
However, I not sure why you would need to do this?

If you open a report in print preview mode (as opposed to report view), then
then you ONLY have the print preview tab anyway. I must be missing something
rather basic
as to why you would need any code to set a active tab when you ONLY should
be seeing the print preview tab in the first place?

Furthermore, if for some reason you want to open these reports in report
view mode with the print preview ribbon, then again simply build and setup a
ribbon that has all the same features as the print preview ribbon (you can
"steal" those features, you do not have to reproduce them). You then simply
that this ribbon in the reports other tab. (again this is not going to take
any code at all here).

If you want I can post a sample with such a report ribbon.

However, at the end of the day, I do not see the need for writing VBA code
when simply specifying a ribbon for the report would do the trick, and this
would work well for both 2007 or 2010.

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

On Aug 11, 6:08*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:
2007


Ah - I meant just a report that's in a list.



Oh, ok. Right now I have it showing my custom tab, then making the
print preview tab visible. I guess I could hide the custom tab and
only show the print preview tab. Why didn't that occur to me?

Thanks.

wrote in message
news:cdada423-253b-4020-869b-6765cd51562b (AT) v9g2000pri (DOT) googlegroups.com...

Unless that custom tab is a left over from custom menu bars, why even spend
money and time and resources that could be better used else where?

There's no need to write 100's + lines of code here and that is just a waste
of your precious time.

In fact, I even perplexed why you even have to have or hide some extra tab
here?

You don't have to hide anything at all if you specify a custom ribbon you
build for the report.

I have about three examples here you can download, the fourth one from the
bottom is for 2007 reports. A good chance the one for 2010 (last one) will
also work for your purposes.
http://www.kallal.ca/msaccess/DownLoad.htm

But as I stated, I'm perplexed why you have to resort to any code or do
anything here at all except use the standard built in features. All you need
to do is specify a custom ribbon for all of your reports. Also, if you set
the reports default view to print preview, then again that tab should be
defaulted anyway. I think it is best to build one custom report ribbon (or
take one from my above examples and you done for the next 10 years). You
should not need to write any code here for the ribbon switch or display
correctly.

Not only can you have the custom report ribbon always appear correctly
without you have to write code to hide things or switch things, but you can
add a couple of nifty features like a one button e-mail click, or perhaps
even a save as PDF one button click. (the above sample has these ideas).

A good rule of thumb here is if something taking too much effort and time,
then it likely the wrong path to take.

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

Hey Albert,

I already use idMso: "TabPrintPreviewAccess" for the full print
preview. It works great - I just forgot about hiding my custom tab
while showing the print preview tab.

I will check out your examples again as I already looked at one of
your tab examples before which was a big help.

I also understand about excessive code versus clever solutions - BUT -
there are many things I need to write code for that Access makes
difficult.

On this subject - I use a ribbon callback because I don't want to
embed the ribbon into each report (I didn't even know I could). Some
users will be creating their own reports and the fewer dependencies on
how they build it the better.

Another subject is the Navigation Pane. Every developer and their dog
have an embedded tree view in a sliding window to the left of their
application to navigate ie windows explorer, all web browsers, etc.
Access developers get the very limited Navigation Pane. Why?

I did implement a tree view using the setparent api to the navpane -
but you can't say there's an easier solution or a better solution
available. Granted you are right about the print preview tab - and the
tabswitch method is now implemented in A2010 (I trust what you say),
but there are many areas where Access can be improved at a fundamental
level, which makes it all the more annoying when I see how far out in
left field some of the A2010 'new features' are - new access-
webbrowser control (why?), custom sharepoint webpages (why not just
convert the forms to html??).

Top of the list last night was the continuous form again. You can't
implement cascading combo-boxes in a continuous form without clever
work-arounds.

This morning I found another situation where I'm using the Current
event to implement a feature which would have been easier if there was
an AfterDelete event (to go with the AfterUpdate event).

Sure this is a rant but I wouldn't be so annoyed if there was some
other application that I found easier to work with. Access has been
very useful to me, I've just been working with it for six years and
feel that at least two solid years have been wasted scratching my head
over simple, obvious deficiencies that really do not have 'simple
solutions' in Access.

Access was a great RAD tool, but since I have my format down the only
solution I see is reimplementing the forms as webpages. Access forms
have a height limit and subforms don't grow and shrink. Vba is an
awesome language but since Microsoft has been attempting to kill it (vb6) for
ten years, it's better for any developers future to just move into
javascript and other js target languages.

If I was to recommend a direction it would be this: attempt to move
closer to html feature set with access forms or build a access forms
to html converter. Build an access browser plug-in (using access
runtime) so we can distribute our apps w/o sharepoint.

There is little respect or money in this Access business, no matter
how awesome my applications are. The money is in web sites or SQL
Server (etc). Just tired of spending my life racing around the same
tiny rat wheel.

Regards,

Christian



On Aug 11, 9:45*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote: