"PW" wrote in message news:a70lg7dri2vbh79vhdimmi6meih5escuan (AT) 4ax (DOT) com...

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.

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

On Thu, 12 Jan 2012 01:26:43 -0700, "Albert D. Kallal"
<PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote:

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



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?

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

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

"PW" wrote in message news:cngug71srak6q4chg8usq69dkigq5gdlr7 (AT) 4ax (DOT) com...


<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:

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

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!).

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/speci...rs-entries.png

Or this one:

http://fairsoftware.com/images/speci...mizelayout.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.

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
kallal (AT) msn (DOT) com

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

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

"PW" wrote in message news:fo46h7lrdcjg4f1o8q64d31u99sr2qn5uk (AT) 4ax (DOT) com...

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
Pleasenospam_kallal (AT) msn (DOT) com

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

"PW" wrote in message news:56gpi75djgde6j1qnm9mqg92qs1sfmp9ar (AT) 4ax (DOT) com...


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/473...45e01ac3c6c1d5

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
Pleasenospam_kallal (AT) msn (DOT) com

On Sun, 5 Feb 2012 22:59:50 -0700, "Albert D. Kallal"
<PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote:


I don't like it! :-)

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