grpIdMSO error message in 2010 ribbon with the print preview commands in custom ribbon

[PW]

Hi,

I have the clipboard group working but when trying to add either (or
both) print preview to the XML in the uSysRibbons table I am receiving
error messages:

The specified controltype 'group' is incompatible with the ctual
control type 'button' for ViewsADPDiagramPrintPreview and 'toggle
button' for FilePrintPreview.

I want to add the 2010 print preview group to my ribbon.

I am just starting with customizing the Access 2010 ribbon - sorry!

Ideally I would like to add the Print Preview to the Print group but
if it appears next to the clipboard group that would be okay. I'll
remove the print group.

Here is part of the XML. Any ideas what I am doing wrong?

<customUI
xmlns="http://schemas.microsoft.com/office/2009/07/customui">
<ribbon startFromScratch="true">
<tabs>
<tab id="tabHome" label="Home">
<group id="grpClients" label="Clients">
<button id="btnClientEntry" size="large" label="Client
Entry" tag="frmClientEntry" onAction="OnOpen"/>
<button id="btnSubClientEntry" size="normal" label="Sub Client
Entry"/>
</group>
<group id="grpResevations" label="Reservations">
<button id="btnReservationEntry" size="normal"
label="Reservation Entry" tag="frmReservation" onAction="OnOpen"/>
</group>
<group id="grpCalendars" label="Calendars"></group>
<group id="grpPrint" label="Print"></group>
<group idMso="ViewsAdpDiagramPrintPreview"></group>
<group idMso="GroupClipboard"></group>
</tab>
<tab id="tabClients" label="Clients">
<group id="grpTabClients" label="Clients">
<button id="btntabClientsClientEntry" size="normal"
label="Client Entry" tag="frmClientEntry" onAction="OnOpen"/>
<button id="btntabClientsSubClientEntry" size="normal"
label="Sub Client Entry"/>
</group>
</tab>

[Albert D. Kallal]

"PW" wrote in message news:j5d9g7lm5vu1q7a51...@4ax.com...

>The specified controltype 'group' is incompatible with the ctual
>control type 'button' for ViewsADPDiagramPrintPreview and 'toggle
>button' for FilePrintPreview.

>I want to add the 2010 print preview group to my ribbon.

Are you talking about a ADP project, or a standard accDB?

The above ribbon idMso looks like it is for an ADP project. I can lookup the
required ones for non local if you want.

In fact a custom ribbon I used for runtime ribbon looks like this:

<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
<ribbon startFromScratch="true">
<tabs>
<tab id="MyReport" label="Report Print and View Options">

<group idMso="GroupPrintPreviewPrintAccess" />
<group idMso="GroupPageLayoutAccess" />
<group idMso="GroupZoom" />
<group idMso="GroupPrintPreviewData"/>
<group idMso="GroupPrintPreviewClosePreview" />

</tab>
</tabs>
</ribbon>
</customUI>


However, if you using ADP, then of course I don't think above will be of
use...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenos...@msn.com

[PW]

On Thu, 5 Jan 2012 03:08:18 -0700, "Albert D. Kallal"
<PleaseNOOO...@msn.com> wrote:

>"PW" wrote in message news:j5d9g7lm5vu1q7a51...@4ax.com...
>
>
>>The specified controltype 'group' is incompatible with the ctual
>>control type 'button' for ViewsADPDiagramPrintPreview and 'toggle
>>button' for FilePrintPreview.
>
>>I want to add the 2010 print preview group to my ribbon.
>
>Are you talking about a ADP project, or a standard accDB?

I don't think I know what an ADP project is Albert! I am following
along with the ribbon exercises in chapter 16 of the "Access 2010
Programmer's reference". The author does not mention what ADP is. At
the end of the chapter he/she says how to use some of the existing
controls that are listed in the backstage options dialog box (just
hover the mouse over the control and the control ID is with the
parentheses.

I now notice the ADP in the ID (I had no idea what that meant).
However, FilePrintPreview does not and also generates a different
error message ('button' instead of 'toggle button').

>
>The above ribbon idMso looks like it is for an ADP project. I can lookup the
>required ones for non local if you want.
>
>In fact a custom ribbon I used for runtime ribbon looks like this:
>
><customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
> <ribbon startFromScratch="true">
> <tabs>
> <tab id="MyReport" label="Report Print and View Options">
>
> <group idMso="GroupPrintPreviewPrintAccess" />
> <group idMso="GroupPageLayoutAccess" />
> <group idMso="GroupZoom" />
> <group idMso="GroupPrintPreviewData"/>
> <group idMso="GroupPrintPreviewClosePreview" />
>
> </tab>
> </tabs>
> </ribbon>
></customUI>
>
>

Thanks, I will give it a try. Where did you get the "Group...." IDs
from?

>However, if you using ADP, then of course I don't think above will be of
>use...

Um, no :-)

What does http://schemas.microsoft.com/office/2006/01/customui
actually do? If I go to the website, it generates an error. Does the
user need to have an internet connection or does the 'compiler' know
what that means? Noob questions!

That is not explained in the chapter, nor is the definition of what a
schema is (I am using the Web Dev 2010 Exp that the author suggested).

Thanks again,

-paulw

[PW]

On Thu, 5 Jan 2012 03:08:18 -0700, "Albert D. Kallal" >

>In fact a custom ribbon I used for runtime ribbon looks like this:
>
><customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
> <ribbon startFromScratch="true">
> <tabs>
> <tab id="MyReport" label="Report Print and View Options">
>
> <group idMso="GroupPrintPreviewPrintAccess" />
> <group idMso="GroupPageLayoutAccess" />
> <group idMso="GroupZoom" />
> <group idMso="GroupPrintPreviewData"/>
> <group idMso="GroupPrintPreviewClosePreview" />
>
> </tab>
> </tabs>
> </ribbon>
></customUI>
>

That is amazing! It just made my wife more excited that I've seen her
in years <G>. We ran a report from our reservation form and it went
to preview. Using the ribbon, I was able to switch from portrait to
landscape, email the report as a PDF. The recipient is blank so I
need to figure out how to use the email address in the email text box
for the current record on the open reservation form

And how to disable the buttons on the ribbon that are open once the
print preview window is closed. The options are all still enabled
with just the form open which I don't want (and generates "garbage"
when the Excel, Word,etc.. buttons are pressed).

So cool!

Thanks,

-paulw

[PW]

>
>However, if you using ADP, then of course I don't think above will be of
>use...

It's got to be my newbie code. I am also getting the error "The
secified control type 'group' is incompatible with the actual control
type 'togglebutton' ID: SortUp" with the following:

<tabs>
<tab id="tabHome" label="Home">
<group id="grpClients" label="Clients">

<button id="btnClientEntry" size="normal" label="Client
Entry" onAction="OnOpenForm" tag="frmClientEntry"/>
<!-- <button id="btnSubClientEntry" size="normal"
label="Sub Client Entry"/> -->

</group>
<group id="grpResevations" label="Reservations">

<button id="btnRezEntry" size="normal" label="Reservation
Entry" onAction="OnOpenForm" tag="frmReservationEntry"/>

</group>
<group id="grpCalendars" label="Calendars"></group>
<group id="grpPrint" label="Print"></group>

<group idMso="GroupClipboard"></group>
<group idMso="SortUp"/>
<group idMso="SortDown"/>
<group idMso="SortRemoveAllSorts"/>
</tab>

If I add </group> at the end of any of the Sort idMso's, I get
"expected </tab> in the editor. But I don't get that with the
"GroupClipboard" line.

-paulw

[PW]

>Thanks, I will give it a try. Where did you get the "Group...." IDs
>from?
>

I found them:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6627

-paulw

[PW]

On Thu, 05 Jan 2012 11:46:57 -0700, PW
<emailad...@ifIremember.com> wrote:

>
>It's got to be my newbie code. I am also getting the error "The
>secified control type 'group' is incompatible with the actual control
>type 'togglebutton' ID: SortUp" with the following:

I'm learning. The error says exactly what the error is. How about
that? ;-)

The control id SortUp is a togglebutton not a group. I think that
what it means. But why I am getting an error with:

<tab id="tabSort" label="Sort Order">
<group id="grpSort" label="Sort Order">
<togglebutton idMso="SortUp"/>
<togglebutton idMso="SortDown"/>
<togglebutton idMso="SortRemoveAllSorts"/>
</group>
</tab>

is beyond me!

The error is 'The element 'group' in namespace..... has invalid child
element 'togglebutton' namespace .....List of possible elements
expected: 'control, labelControl, button, toggleButton, checkBox,
...." when I hover the mouse over the first togglebutton (which is
underlined as an error).

togglebutton is one of the expected elements listed in the error
message. Is it not in
http://schemas.microsoft.com/office/2009/07/customui ?? That is what
the book I mentioned is using.

How is my code different than:

<tab id="rxtabcustom" label="my tools" insertbeforemso="tabhome">
<groupid="rxgrpformats" label="formatting">
<togglebutton idmso="bold"/>
<togglebutton idmso="italic"/>
</group>
<tab>

?? I took that from a book ("Ribbon X: Customizing the Office 2007
Ribbon").

Any ideas?

-paulw

[PW]

My (newbie) bad! I got it working. It's "toggleButton" with a
capital B. I had to step away for a bit before I realized it. And I
had to remove SortRemoveAllSorts because, even though it appears in
the Customize Ribbon section, it is not supported.

-paulw

[Albert D. Kallal]

"PW" wrote in message news:ndobg7t3iem3qr821...@4ax.com...

>>Are you talking about a ADP project, or a standard accDB?

>I don't think I know what an ADP project is Albert!

You don't have to worry then! An ADP is a special type of Access application
that works "only" with SQL server. So there is quite a few menus etc. that
ONLY work when you working with SQL server.

So just advoid anything ADP, and you should be fine.

>Where did you get the "Group...." IDs
>from?
>

>I found them:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6627

Great link, thanks for sharing.

>And how to disable the buttons on the ribbon that are open once the
>print preview window is closed.

I suggest that you build a ribbon ONLY for reports. Then specify the ribbon
in the "other" tab of the reports property sheet. That way when report
launches, report ribbon will automatic show. When you close it, the ribbon
is also closed and you back to the previous ribbon. This approach is ALSO
recommended for forms. Specify the ribbon you need/want. Then Access will
take care when you switch between forms or reports (the ribbon will switch
for you without code).

So don't create one big ribbon with a bunch of tabs, but create a given
ribbon for the given task or form or in this case report.

I take a look at you toggle button later, but I have to run....

As to how to enable, or disable individual controls from code? I have a
example here that may be of help:

http://www.kallal.ca/Ribbon/ribbon.htm

[PW]

>>And how to disable the buttons on the ribbon that are open once the
>>print preview window is closed.
>
>I suggest that you build a ribbon ONLY for reports. Then specify the ribbon
>in the "other" tab of the reports property sheet. That way when report
>launches, report ribbon will automatic show. When you close it, the ribbon
>is also closed and you back to the previous ribbon. This approach is ALSO
>recommended for forms. Specify the ribbon you need/want. Then Access will
>take care when you switch between forms or reports (the ribbon will switch
>for you without code).
>

Can I do this for all the reports and forms, or do I have to assign
the report ribbon to each report and form?

>So don't create one big ribbon with a bunch of tabs, but create a given
>ribbon for the given task or form or in this case report.

Thanks for straightening me out! Totally makes sense.

>
>I take a look at you toggle button later, but I have to run....
>
>As to how to enable, or disable individual controls from code? I have a
>example here that may be of help:
>
>http://www.kallal.ca/Ribbon/ribbon.htm

I've already downloaded and installed your ribbon class, and printed
out the documentation and studied it. Not sure how to get started
with it yet though.

I figure I will do things the hard way first, and then later on switch
to your ribbon class :-)

Thanks Albert.

Did you write the ribbon chapter in the 2010 Programmer's Reference
book? This book is a MUST have for every Access 2010 developer (IMHO,
of course :-)

-paul
-paul

[PW]

One ribbon for reports, one for forms, a third one for "main"? What
would you put in that one or would you make the ribbon form the main
form?

-paul

[Albert D. Kallal]

"PW" wrote in message news:uekhg7h28ajj9m6uj...@4ax.com...

>>recommended for forms. Specify the ribbon you need/want. Then Access will
>>take care when you switch between forms or reports (the ribbon will switch
>>for you without code).
>>
>
>Can I do this for all the reports and forms, or do I have to assign
>the report ribbon to each report and form?

Well, yes, when you create a new report, I then just go to the other tab and
set the ribbon. I have one called MyReport that I use for all ribbons.
(it as email as PDF, save as PDF, print, print to default and a few of the
export to Excel, word etc.). I mean you build this once and you done
for the next 10 years.

Having to set the ribbon used for the report one time during creating of the
report is no different then having to set
the boarder or dialog mode of a form. It is a simple one time setting and
you done.

>>So don't create one big ribbon with a bunch of tabs, but create a given
>>ribbon for the given task or form or in this case report.

>Thanks for straightening me out! Totally makes sense.

And another tip is while menus bars often group by type of feature with
ribbons you now are suggested to group ribbons options by "task".

>I've already downloaded and installed your ribbon class, and printed
>out the documentation and studied it. Not sure how to get started
>with it yet though.

I need more write-up and examples - just not time to do this as of yet.

>
>Did you write the ribbon chapter in the 2010 Programmer's Reference
>book? This book is a MUST have for every Access 2010 developer (IMHO,
>of course :-)

Thanks for the kind words. No, I did not write that content but I was one of
several technical editors on that book.

[Albert D. Kallal]

"PW" wrote in message news:afmhg71u2lcsc5825...@4ax.com...

>>So don't create one big ribbon with a bunch of tabs, but create a given
>>ribbon for the given task or form or in this case report.

>One ribbon for reports, one for forms, a third one for "main"? What
>would you put in that one or would you make the ribbon form the main
>form?

Yes, the above is right on the money.
If an application has 15 forms, probably most can use a standard and same
ribbon (so the clip board, perhaps a close form, and perhaps basic record
filtering).
You then have the one for all reports. And often the application "wide" or
main one can be that default ribbon you want for everything anyway.

However for those forms that have code and a bunch of buttons that you
perhaps moved up from the form to de-clutter it and now are buttons on a
ribbon? In this case then yes you create a new ribbon and in this case you
can and WANT to keep all code in the form. I STRONGLY recommend you do NOT
use callbacks, but use function expressions. This way the custom ribbon for
the given form can run VBA code direct from the ribbon buttons just like a
button on a form usually runs code inside of that forms code module. So no
macro and no callbacks are used, but those buttons run code direct from that
form.

[PW]

On Sat, 7 Jan 2012 22:58:54 -0700, "Albert D. Kallal"
<PleaseNOOO...@msn.com> wrote:

>"PW" wrote in message news:uekhg7h28ajj9m6uj...@4ax.com...
>
>
>>>recommended for forms. Specify the ribbon you need/want. Then Access will
>>>take care when you switch between forms or reports (the ribbon will switch
>>>for you without code).
>>>
>>
>>Can I do this for all the reports and forms, or do I have to assign
>>the report ribbon to each report and form?
>
>Well, yes, when you create a new report, I then just go to the other tab and
>set the ribbon. I have one called MyReport that I use for all ribbons.
>(it as email as PDF, save as PDF, print, print to default and a few of the
>export to Excel, word etc.). I mean you build this once and you done
>for the next 10 years.
>
>Having to set the ribbon used for the report one time during creating of the
>report is no different then having to set
>the boarder or dialog mode of a form. It is a simple one time setting and
>you done.

About 130 reports and about that many forms in our base version. Each
version is customized. If a client wants to upgrade to the 2010
version I will have to manually populate the ribbon property for
almost 300 forms and reports. That will be for one client. I see no
other way around it.

Ick. Not looking forward to that. I guess I could figure out how to
write code to loop through a collection of the reports and forms, but
how would the Ribbon Name value get saved? I really don't want to
have to do this everytime someone opens the application.

Maybe I am spacing out on this.

-paulw

[PW]

>
>And another tip is while menus bars often group by type of feature with
>ribbons you now are suggested to group ribbons options by "task".
>

I don't know what you mean Albert. At least not yet :-)

-paulw

[PW]

What is a function expression? I have started to write some
modules/classes to do some things in that great book.

-paulw

[Albert D. Kallal]

"PW" wrote in message news:vtvjg71mo57hfmgmo...@4ax.com...

>>Having to set the ribbon used for the report one time during creating of
>>the
>>report is no different then having to set
>>the boarder or dialog mode of a form. It is a simple one time setting and
>>you done.

>About 130 reports and about that many forms in our base version. Each
>version is customized. If a client wants to upgrade to the 2010
>version I will have to manually populate the ribbon property for
>almost 300 forms and reports. That will be for one client. I see no
>other way around it.

Try:
Sub SetReportRibbon()

Dim r As Variant

For Each r In CurrentProject.AllReports
Debug.Print "working on " & r.Name

DoCmd.OpenReport r.Name, acViewDesign
Reports(r.Name).RibbonName = "MyReport"
DoCmd.Close acReport, r.Name, acSaveYes

Next

End Sub

[Albert D. Kallal]

"PW" wrote in message news:ki2kg751lumdo6c5u...@4ax.com...

>>And another tip is while menus bars often group by type of feature with
>>ribbons you now are suggested to group ribbons options by "task".

>>?

>I don't know what you mean Albert. At least not yet :-)
>
>-paulw

This is not always cut and dry, and I cannot find a great video link on this
subject (darn!). The basic idea here is if you are working on a form that
does invoicing, then you might frequent use a button to "check" invoice
balance, and if 75% right after the user checks the balance, then they
print. Then if the next step in that process is save as PDF, then you could
place the check invoice, the print and the save as PDF buttions right beside
each other (in fact this is much how access developers have placed buttons
on forms for years).

In a older menu system, you probably would have users go file->print, or
file->save as PDF, and the button for "checking" the invoice balance might
be on the form or on a custom menu.

So the idea behind the ribbon is to make your software "task" orientated,
and group by how the users are supposed to get the task done, not group
buttons necessary by some category such as "file" operations in which you
save, or export a file.

This is not a hard and fast rule but does suggest that some change in
approach in thinking needs to be done if you developed lots of menu bars in
the past.

Also, I going to cut + paste a post of mine the concept of what/why we mean
by "backstage" since that concept is often used in regards to office 2010.

Backstage is what you see when you go file-> in office 2010.
==========================

What is Back stage?

If you are wondering what the conceptual idea behind backstage is, well it's
really just a separation of the type of task or work you're doing in the
particular application.

The problem is over the years each of the applications like word and excel
and even Access continues to absolutely have HUGE growth in the amount of
features. The problem is there's a whole class or set of features in
applications that are not used while you're actually editing data. So in
Word, Excel, Access etc. you might be editing Word document or entering data
into a Access form.

The other area of the application is a set of options to "setup" the options
in the application.

So for display of options like who edited the document last, default page
layout, even the startup options in Access, all of these things are tasks
that you don't generally use DURING regular running of the application when
you're manipulating and editing data. You do not have to "see" the data when
using these setup type of options.

So what Microsoft did is they took all this mass of huge amount of options
that displays who edited the document last, the ODBC options, and moved all
of this stuff OUT OF the standard UI area. In other words all of the
options in your application that are not used for actual editing of data
should be placed in backstage.

It makes no sense to see the Word document or even an Access form when you
using a set of options that has little to do with actual editing of data.
Thus we can now use the WHOLE computer screen to layout these options on one
nice big easy to read page. And it means that the user will not be
attempting to edit data when you use such options. So there are many setup
options in Power Point that have nothing to do WHEN editing a slide. Or
editing Word, or editing Excel data. And with SharePoint and other systems,
the number of options and things you do that are NOT directly editing the
data in the document is increasing all the time.

So backstage would NEVER be used for cut and paste options because you
actually can't see the document in question anyway! However backstage would
certainly be used in your application where you want to set up the sales tax
rate. You also might have screen for setup of default city and setup of
default area code. Perhaps setting for a special invoice printer etc..

From software organizational point of view backstage is thus a great concept
and it's simply moves tons of junk and clutter out of the main application.
This moving out of tons of features that are not really required during
regular editing means that the "regular" part of the application ALSO has
FAR less clutter and options in your way.

In fact this design concept is what contributes to the overall clean look
and de-clutter we see in office 2010.

It is a win win since a user does not now have to look through "tons and
tons" of editing data menus to find some setup option since once you go to
backstage, then all of the "main" editing options are now unavailable and
un-seen.

If you look at competing products to office they continue to clutter up
their main part of the application with ever more and more options. So the
engineering and design concept of the backstage is really something that
been long overdue in the software industry and something that competition to
office likely will have to adopt once they grasp and understand what
backstage is all about.

When word came out it had under 100 options, I think today it up around
3000+ menu options. Something had to be done here from a software design
point of view.

This simple idea of separating menu options for editing vs. that of setup
type options is a simple but fantastic design addition to office 2010.

So when someone mentions backstage, they mean the new file-> option area in
Office. So this is where you will most of the options that you have in an
application that are not needed DURING running and editing of the particular
data that the program in question is designed to work with.

In access there are thus a lot of options not used during design mode, or
editing of data in forms mode, so this is where these options will now be
found in Access 2010.

[PW]

Hi Albert,

Thanks for the info on the BackStage stuff. I really haven't messed
with it much and have no idea why I would want to customize it since I
don't work for a "shop" (I deliver our product as an MDE).

Good to know. Thanks!

-paulw

[PW]

Well ain't that ****** slick! I just ran the Sub from the immediate
window (didn't know I could do that) and VOILA!!

So COOL Albert!! Thanks so much!

I had no idea we had this many reports and forms! Fifteen years
working on a product will do that!

I am going to try it with forms next!

-paul

[Albert D. Kallal]

"PW" wrote in message news:a70lg7dri2vbh79vh...@4ax.com...

>What is a function expression? I have started to write some
>modules/classes to do some things in that great book.
>
>-paulw

By function expression I mean standard Access functions.

In the sql builder, or even for properties sheets in Access, or even with a
text box control on a form, you can use a function name.

=TodayTimeAndDate()

So the above is a function expression you could place in a text box. So the
above would display the results of the function. Access has what is called a
"expression" service.

So in a standard code module:

Public Function TodayTimeAndDate() as string

TodayTimeAndDate = "The current date and time time is " & Now()

End function.

When you build the XML if you specify the call back the standard way, it
will look like this:


<button id="Tab1" label="TestButton"
imageMso="ViewsFormView" size="large"
onAction="PrintInvoice"
/>

In the above, PrintInvoice MUST be a Sub defined in a standard code module.
It cannot be code in your current form.

However, if I use a expression, then we get this:

<button id="Test1" label="TestButton"
imageMso="ViewsFormView" size="large"
onAction="=PrintInvoice()"
/>

Note the use of = and (). Now just like any expression in Access, the
function will be called.

This allows and means the public function can be placed in your form where
it often belongs. So for things like a button that prints a report or even
EXISTING button code on your form, you can have both buttons and ribbon code
call/use the same code (very handy as you migrate buttons from a form up to
a ribbon).

And you can also pass parameters in the above. So 3 ribbon buttons to print
3 reports could use this:

<button id="report1" label="Customer Report"
imageMso="ViewsFormView" size="large"
onAction="=MyReport('rptCustomers')"
/>

<button id="report2" label="Sales Report"
imageMso="ViewsFormView" size="large"
onAction="=MyReport('rptSales')"
/>

<button id="report3" label="Phone listing"
imageMso="ViewsFormView" size="large"
onAction="=MyReport('rptPhonelist')"
/>

Now in that form code module, you simple write this code:

Public Function MyReport(strReport as string)

docmd.OpenForm strReport, acviewPreview

End function


So this is not a call back, but an expression. I mean you could even call a
msgbox like this:

<button id="report3" label="msgbox test"
imageMso="ViewsFormView" size="large"
onAction="=msgbox('hello world')"
/>

The above would thus use the msgbox box function direct in the ribbon xml.
So for most cases, I VERY much recommend you use a function expression and
NOT use callbacks. I have no idea why books, or this idea not been more wide
shared in public - I just lack the time to write up and post an article on
this issue.

As noted, this also allows with great ease to use the same ribbon for more
then on form. What ever form has the FOCUS is where the public functions
will be run FROM that current forms code module. So you can create a public
function called "myDelete" for all your forms that assumes and has the VBA
delete code (same code you might have on a delete button on that particular
form). Now the one ribbon will work for all those forms no matter what
since the custom MyDelete() function in the given form that has focus is the
code that will run when you click on the ribbon button.

I consider the above tip a near breakthrough in terms of ease and time it
saves in regards to writing ribbon code.

[PW]

I don't think I get why doing it this way is any different than what I
am already doing to run a form:

<group id="grpResevations" label="Reservations">

<button id="btnRezEntry" size="normal" label="Reservation
Entry" onAction="OnOpenFormNewRec" tag="frmReservationEntry"/>
</group>

Yes, in a module. This will open any form passed in Add mode:

Public Sub OnOpenFormNewRec(ctl As IRibbonControl)

DoCmd.OpenForm ctl.Tag, acNormal, , , acFormAdd

End Sub

>
>This allows and means the public function can be placed in your form where
>it often belongs. So for things like a button that prints a report or even
>EXISTING button code on your form, you can have both buttons and ribbon code
>call/use the same code (very handy as you migrate buttons from a form up to
>a ribbon).

Sounds like I will have to duplicate code in each form, or have to
find out where the function is located if I want to change it. I
don't know why I would want to take buttons from a form and put them
on a ribbon (at least not yet).

If Access was object orientated, then that would be no biggie because
it would be in the class that all the forms are based upon. Make a
change to the parent class and it would be passed on to the child
forms.

That is not what I am already doing?

> What ever form has the FOCUS is where the public functions
>will be run FROM that current forms code module. So you can create a public
>function called "myDelete" for all your forms that assumes and has the VBA
>delete code (same code you might have on a delete button on that particular
>form). Now the one ribbon will work for all those forms no matter what
>since the custom MyDelete() function in the given form that has focus is the
>code that will run when you click on the ribbon button.
>

I think I see where you are going with this, but all our forms already
have a "delete" button (for example) with code.

[PW]

>
>If Access was object orientated,

*oriented"!! Yeah, I really meant "oirentatertoted!" ;-)

[Albert D. Kallal]

"PW" wrote in message news:cngug71srak6q4chg...@4ax.com...

>>Note the use of = and (). Now just like any expression in Access, the
>>function will be called.

>I don't think I get why doing it this way is any different than what I
>am already doing to run a form:

<group id="grpResevations" label="Reservations">
<button id="btnRezEntry" size="normal" label="Reservation
Entry" onAction="OnOpenFormNewRec" tag="frmReservationEntry"/>
</group>

>

There a good many differences.

The first point I made is you don't have a choice as to where you can place
the above code. In the above example you MUST place the code you want to run
in a global procedure and global module. To be fair, the above example is
CLEARLY a global procedure in nature and thus it makes sense to have the
above routine as global.

However, what happens if that code belongs in a form's code module? So now
let's assume some custom delete code for a given form. I have lots of forms
that do code something like this:

Eg:
Public Function MyDelete()


' only delete if no payments.

If Me.Payments1.Form.RecordsetClone.RecordCount > 0 Then
Beep
MsgBox "You cannot delete a booking with payment information",
vbInformation, AppName
Exit Function
End If

I think it quite clear that above code belongs the forms code and is NOT
global code.

So if you build a custom ribbon and want a delete record button on that
ribbon, then what?

How are you going to call the above delete routine in that form?
Furthermore how now are you going to use the SAME ribbon for MORE than one
form but have separate custom delete code? And worse if you use a call back,
you going to have to use/hunt down some global code for the code that
naturally belongs in the form.

Thus:
At the end of the day if you are a competent developer and the code DOES
belong in a form then I'm going to assume that you will intelligently make
that correct decision.

Thus:
At the end of the day if you are a competent developer and the code does NOT
belong in a form then I'm going to assume that you will intelligently make
that correct decision.

So with a callback, the developer does not have a choice (the ribbon call
code must be public in a standard code module).
You cannot have your ribbon call code directly in the forms code module.

So just keep in mind the issue was NEVER that you're going to adopt poor
programming practices and start duplication of code.

So the basic issue here is we need to make proper choice as to where to
place that code.

Sometimes it belongs in a global code module, but sometimes it does not.

This why I said the following:

>>This allows and means the public function can be placed in your form where

>>it OFTEN belongs.

In the above I've highlighted to word "OFTEN" to caps. I did not say
"always".

>Sounds like I will have to duplicate code in each form

No, you will only do the above if the code in question needs to be
duplicated and is different for each scenario.

In other words if it makes sense to do so, then you will. However if it does
not, then we not suggesting to do something stupid.

So if code belongs in a form, then you can assume the developer made a great
choice. If fact if the developer makes a poor choice and places code
"outside" of the form then this would in fact force you to go on a wild
goose chase to find code that the developer failed to place correctly.

So if code belongs in the form, then place it in the form and you'll not
have to go running around looking for where that code is, because it belongs
where it been placed.

And the reverse is also true. Assuming good developers, then if such code
does not belong in the form, then you can competently assume that you've not
be looking for that code in the form
(unless you've hired really poor developers!).

>Idon't know why I would want to take buttons from a form and put them

>on a ribbon (at least not yet).

Hum, I much thought the whole idea here of learning and adopting the ribbon
was to "provide" a ribbon interface in your application. I much thought the
whole idea and motivation here is if you using ribbons, then why not adopt
the ribbon interface for your users then?

The idea and point here is you cannot just keep dropping buttons on to a
form for each new feature and option you build into your application.
Moving buttons off your form means you now free up all of the space on the
form. It means you remove the clutter of buttons on that form.

With too many buttons on a form, it becomes not only messy, but you ALSO now
have the cost of the ribbon chewing up screen real estate.

I have to assume that over time an application will reach a point where TOO
MANY options and buttons have to be placed on the form. You then start
building custom menus (or ribbons) to move those features out of the form to
make MORE room. The idea that you just keep dropping more and more buttons
and options by placing buttons on a form makes no sense.

Take a look at this screen shot:
http://www.kallal.ca/Rides/menubook.gif

That above menu shows ONLY 9 options on one menu! There are of course more
menus! It just means after a certain point your application cannot just rely
on more and more buttons just being dropped on a form with more and more
clutter. You cannot really place 15 buttons on a form. In above ONE menu
has ONLY 9 options.
So that custom menu gives the user 9 choices (so that would = 9 LESS buttons
I had to place on the form).

By the way, I don't have a ribbon version of that application screen shot,
but I can't wait till I convert over to the ribbon.

Also keep in mind that the vast majority of your users will have worked with
or have been exposed to applications with ribbons.
So we can reduce clutter and provide a similar interface and user experience
like other software. This can reduce learning curve for users.
So I think it is a great idea to consider moving buttons up to the ribbon.
This is even in the case where you don't have too many buttons.

Take a look at this Access screen shot to see what I mean:

http://fairsoftware.com/images/specific/screenshots/exhibitors-entries.png

Or this one:

http://fairsoftware.com/images/specific/screenshots/customizelayout.png

In fact take a look at these Access screens here:

http://fairsoftware.com/screenshots.aspx

In all of the above cases, you can see the buttons have been removed from
the forms and placed in the ribbon.
The above are Access forms and they look rather nice.

As noted, at the end of the day this is not a huge deal. I would have
thought that a major goal here is to start moving buttons from your form up
into that ribbon since you going to the trouble and efforts to use the
ribbon.

Remember, so much of office (even AutoCAD has a ribbon) and other developers
are creating software around this new interface. Offering this type of
interface to your users not only makes your software seem up to date, but it
also a VERY nice user interface system and when done right, users will
"enjoy" using your software more.

I am thus assuming as an long term future goal you probably want to emulate
this setup in your software.

However, often you cannot do this all at once. So over time there's a great
possibility that you'll start moving "some" buttons from your form up into a
custom ribbon to reduce clutter and increase ease of use. In fact it might
be just a case where you just run out of room for options and buttons on
your form, so you start a ribbon.

So we're talking about an progression of your software and overtime how your
applications tend to get more and more complex. This means more and more
features added. Since everyone is quite aware of this natural progression
of software and complexity, then this suggests in some cases you might even
duplicate some of the buttons in the ribbon that do the SAME thing as some
of the buttons on the form to ease you users transition from the older
version of your software to the newer version.

After your "user base" gets used to new ribbon interface, then new staff
hires and staff turnover means the user base will likely use the ribbon for
most of the functionality, and it'll only be your older and longer legacy
users that continue to use the buttons on the form. This opens the door and
paves the way for in even removing more buttons off your form and up into
the ribbon. You can thus eventually reach a point where you have no buttons
left on your form.

Ok, lets point out some more issues that are solved by my suggestion:

<group id="grpResevations" label="Reservations">
<button id="btnRezEntry" size="normal" label="Reservation
Entry" onAction="OnOpenFormNewRec" tag="frmReservationEntry"/>
</group>

The next problem in the above is that you're using the tag command to pass a
value. There are many examples that do this, but this is really approaching
somewhat of a kludge. It means the code you call will THEN have to take the
tag command and then stuff it into a variable, or use the tag command
direct. So you now have extra code.

Worse is other code and other routines (NOT from ribbon) cannot call this
same code routine. You are FORCED to pass that routine a ribbon object. I
would rather just call some regular code that accepts regular parameters
like we always done from day one.

And speaking of parameters, what happens if you need to pass and use more
than one parameter to that routine?

Using an function expression means you can pass MORE than one parameter.

Eg:
button id="MyDelete" label="Delete Record"
imageMso="Delete" size="large"
onAction="=MyDelete('Staff','tblStaff')"
supertip="Delete this record"

And the routine is:

Public Function MyDelete(strPrompt As String, strTable As String)
Dim strSql As String
Dim f As Form
Set f = Screen.ActiveForm

If MsgBox("Delete this " & strPrompt & " record?", _
vbQuestion + vbYesNoCancel, "Delete?") = vbYes Then


The above may, or may not be a global routine. (the above code snip quite
much suggests this is a global function in standard code module).

The point again is we are calling regular code right from the ribbon, and
not having to jump to a call back routine that is passed some ribbon control
and some tag value.

I mean at the end of the day I think every access developer for the vast
majority of their programming careers will NOT be surprised that when they
call some code it makes sense that those routines will accept parameters. My
tip of using Access "expression service" simply allows one to use and call
that code directly.

With callback, you having to pass ribbon control, and a tag and thus not
following simple programming conventions like calling a routine and passing
it some values. So above code snip can be called from a button on your
form, some code in a standard code module AND ALSO that of from a ribbon as
the above xml shows!

You not writing some "custom" code that can ONLY be called from the ribbon.
(so we talking about improving code re-use here).

As I pointed out the other really big bonus here is that the form with the
current focus will be searched first for the public function.
So as noted, you can build one ribbon that works for many forms. You not
have a whole whack of "case" and else statements like you do with a global
call back.

In fact, no extra case statements or coding is required. This means if you
have 14 forms, they can all call a global custom delete record routine.
However one of the forms MAY need a special custom delete routine. You
simply place the public function in that one form, and when it has the
focus, then the code in that form will run as opposed to the global code
function. Again, this kind of setup with a call back is messy and difficult.

>I think I see where you are going with this, but all our forms already
>have a "delete" button (for example) with code.

Right, and how would you move that button up to the ribbon and not have to
modify that delete code?
A call back can NOT call code in a form. You would have to call a global
routine and THEN have it call code in a form.
Using the approach I suggested the ribbon button will call + run the code
in your form directly and not have to call or run any global callback
routines in-between.

I can write on for many more pages here, but at the end of the day I suppose
this much centers around how much of your interface you want to move up to
the ribbon.

I think those ShowWorks screen shots are just great and shows great use of
the ribbon in some Access forms as opposed to buttons on a form.
And as noted, that application is written in Access.

As always there no one way or the other that is best, but only what you feel
will work for your users.
Your goals and users are going to be different then mine.

However, I hope the above gives you my "thinking process" on the ribbon.

We are not just building a ribbon, we adopting a UI system to make the
software experience better for your users.

I would not use the ribbon just to have a "ribbon" show

If one cannot improve the user experience by using a ribbon then I don't
think it is worth the efforts.

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

kal...@msn.com

[PW]

Oh boy Albert! Don't be looking for a response from me today <g>

Thanks for all the work you just did for me. I need to get this
ribbon done for a "trade" convention next week (the original
"Dudes":-) and it doesn't have to be perfect for that. I hope our
clients (and potential ones) don't mind the new ribbon thing. It
doesn't take much to confuse them!

I printed out your last post and will study it while watching football
tomorrow.

-paul

[PW]

Maybe too late for me to ask a silly question Albert (or anyone), but
all this ribbon stuff that I have been doing will work with a runtime
version, correct? The print ribbon etc... right?

Code like this:

<tab id="tabReportOptions" label="Report Print and View

Options">
<group idMso="GroupPrintPreviewPrintAccess" />
<group idMso="GroupPageLayoutAccess" />
<group idMso="GroupZoom" />
<group idMso="GroupPrintPreviewData"/>
<group idMso="GroupPrintPreviewClosePreview" />
</tab>

-paul

[Albert D. Kallal]

"PW" wrote in message news:fo46h7lrdcjg4f1o8...@4ax.com...

>Maybe too late for me to ask a silly question Albert (or anyone), but
>all this ribbon stuff that I have been doing will work with a runtime
>version, correct? The print ribbon etc... right?

>Code like this:

Yes, it should work just fine. The only issue is a few places where runtime
does not have the same as full, but that is not really a ribbon issue, but
runtime.

The PDF options for example do work in runtime, but a did find a few idMso
buttons I placed on the ribbon did not, but for the most part you be fine.


--

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

Pleasenos...@msn.com

[PW]

>Take a look at this Access screen shot to see what I mean:
>
>http://fairsoftware.com/images/specific/screenshots/exhibitors-entries.png
>
>Or this one:
>
>http://fairsoftware.com/images/specific/screenshots/customizelayout.png
>
>In fact take a look at these Access screens here:
>
>http://fairsoftware.com/screenshots.aspx
>
>In all of the above cases, you can see the buttons have been removed from
>the forms and placed in the ribbon.
>The above are Access forms and they look rather nice.

Albert, why do you think this is a good user interface???? I find it
awkward and a challenge to use (from looking at the screenshot). Sure,
it's "pretty". If I find it a burden to use, then our clients most
doubt will!!

I am not just referring to the ribbon, but the diagram form and the
rest of it on the right. Why are both there????

-paulw

[Albert D. Kallal]

"PW" wrote in message news:56gpi75djgde6j1qn...@4ax.com...

>>In fact take a look at these Access screens here:
>>
>>http://fairsoftware.com/screenshots.aspx
>>
>>In all of the above cases, you can see the buttons have been removed from
>>the forms and placed in the ribbon.
>>The above are Access forms and they look rather nice.

>Albert, why do you think this is a good user interface???? I find it
>awkward and a challenge to use (from looking at the screenshot). Sure,
>it's "pretty". If I find it a burden to use, then our clients most
>doubt will!!

>I am not just referring to the ribbon, but the diagram form and the
>rest of it on the right. Why are both there????

First, I think the forms are rather nice to look at.

But, I am not sure which one you refer to when you say "diagram" form?

I mean, no doubt that lots of UI going to be preferences etc, and some is
going to be just downright usability (or lack of), but I dare say that
software, even from great companies like Acronis disk tools again shows this
trend:

http://bilder.egmont.se/cache/47/4733/47338373c08b97be9724bfc79445e01ac3c6c1d5

So, I just pointing out we see a trend towards more web like and also that
of more "touch" friendly UI.

In fact we seeing the ribbon lends VERY well to tablet and touch based UI
where as cascading menu bars work VERY poorly on tablets.

--

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

Pleasenos...@msn.com

[PW]

On Sun, 5 Feb 2012 22:59:50 -0700, "Albert D. Kallal"
<PleaseNOOO...@msn.com> wrote:

>"PW" wrote in message news:56gpi75djgde6j1qn...@4ax.com...
>
>
>>>In fact take a look at these Access screens here:
>>>
>>>http://fairsoftware.com/screenshots.aspx
>>>
>>>In all of the above cases, you can see the buttons have been removed from
>>>the forms and placed in the ribbon.
>>>The above are Access forms and they look rather nice.
>
>>Albert, why do you think this is a good user interface???? I find it
>>awkward and a challenge to use (from looking at the screenshot). Sure,
>>it's "pretty". If I find it a burden to use, then our clients most
>>doubt will!!
>
>>I am not just referring to the ribbon, but the diagram form and the
>>rest of it on the right. Why are both there????
>
>First, I think the forms are rather nice to look at.
>
>But, I am not sure which one you refer to when you say "diagram" form?
>
>I mean, no doubt that lots of UI going to be preferences etc, and some is
>going to be just downright usability (or lack of), but I dare say that
>software, even from great companies like Acronis disk tools again shows this
>trend:
>
>http://bilder.egmont.se/cache/47/4733/47338373c08b97be9724bfc79445e01ac3c6c1d5
>

I don't like it! :-)

>So, I just pointing out we see a trend towards more web like and also that
>of more "touch" friendly UI.
>
>In fact we seeing the ribbon lends VERY well to tablet and touch based UI
>where as cascading menu bars work VERY poorly on tablets.

That's nice, but what database software for tablets is being written
with MS Access? And/Or what "real" software is run on a tablet?

Thanks again Albert!

-paul

[Albert D. Kallal]

"PW" wrote in message news:9ms0j7phl8v9dpcb5...@4ax.com...

>>So, I just pointing out we see a trend towards more web like and also that
>>of more "touch" friendly UI.
>>
>>In fact we seeing the ribbon lends VERY well to tablet and touch based UI
>>where as cascading menu bars work VERY poorly on tablets.

>That's nice, but what database software for tablets is being written
>with MS Access? And/Or what "real" software is run on a tablet?
>
>Thanks again Albert!
>
>-paul

This is becoming a common request from many of my clients.
And I am currently running some Access forms on my SmartPhone.

And FileMaker now has the ability to create apple iPad software.

And if you been reading news, certainly windows 8 is going to allow one to
work using a UI with more touch features.

And while I am under NDA, I can safely say that future trends for most
software we use will include some improved ability for working with tablets.

[PW]

On Wed, 8 Feb 2012 19:08:50 -0700, "Albert D. Kallal"
<PleaseNOOO...@msn.com> wrote:

>"PW" wrote in message news:9ms0j7phl8v9dpcb5...@4ax.com...
>
>>>So, I just pointing out we see a trend towards more web like and also that
>>>of more "touch" friendly UI.
>>>
>>>In fact we seeing the ribbon lends VERY well to tablet and touch based UI
>>>where as cascading menu bars work VERY poorly on tablets.
>

What about the "submenus"? Or does every object have to launch from
the main ribbon?

>>That's nice, but what database software for tablets is being written
>>with MS Access? And/Or what "real" software is run on a tablet?
>>
>>Thanks again Albert!
>>
>>-paul
>
>This is becoming a common request from many of my clients.
>And I am currently running some Access forms on my SmartPhone.

I remember the video that you showed me.

>
>And FileMaker now has the ability to create apple iPad software.

I believe Alpha5 may too, but perhaps not Apple Devices. We have a
client running our app via GoToMyPC and he's very happy with it.
Granted it isn't running on his iPad.

Filemaker can do what Access and Alpha 5 can do? Doesn't it just have
a scripting language? From what I have seen of it, it's pretty
limited. We would need a very "light" dumbed down version of our
software. Not sure that would work/sell.

Is there software that will back up application data on the iPad? If
so, where to?

>
>And if you been reading news, certainly windows 8 is going to allow one to
>work using a UI with more touch features.

But there is still a Windows 7 mode I think.

>
>And while I am under NDA, I can safely say that future trends for most
>software we use will include some improved ability for working with tablets.

Yep. I don't want to get lost by not keeping our application up to
speed with that technology. Not sure if we have the potential client
base to support the expenditure.