G
Guy
Hi All,
Sorry if my previous posting's sounded like a reason to vent my frustration,
but to put things straight I like the Ribbon concept and as a person that
likes to talk to other knowlegable people including Access MVP's with which
I believe I have complimentary experience (29 years in software development
of all types from Assembler to Cobol to Fortran to Pascal on various O/S's
and Windows C, C++, SQL Windows, Borland Delphi & C++, all Oracle products
before 2000, all Microsoft Office products since 1990 including Access since
1.00 both mdb's and adp's, and RDBM's SQL Server, Oracle, Ingres even the
Poet ODBMS).
It is just that I feel the implementation of Ribbon management in A2007,
whilst in itself clever, is half baked, and in order to overcome the issues
we are forced to write less than robust code.
Imagine what my users are going to think when after a application error they
click on a Ribbon button and get the message "Object not initialized (or
something similar)".
Here are some of the other issues that I would like to highlight:
1) You change the XML for a Ribbon, and if it is already loaded, you
can't just reload it be recalling the Application.LoadCustomUI method, it
fails with a Ribbon already loaded error, so you have to exit the
application and start again.
2) Debugging the Ribbon using the Access Debug utility, which isn't as
smart as the .NET version, is a pain. Your stepping through some code
wondering why your button hasn't been disabled as intended and all the
callbacks fail meaning, you guessed it, all your variables, collections and
classes have been re-initialised. So you have to exit the application and
start again.
Ok so we have to use a non-invasive debugging technique such as
Debug.Print. Do Microsoft realise what the implications of this are? You
can nolonger properly debug a form or report that involves a Ribbon callback
unless you use Debug.Print, comment out all actions that may call a Ribbon
callback, or are confident that an Access error will not affect the code
that you are debugging.
3) The timing of callbacks in relation to the active Access object that
triggered them is also problematic. I've tried disabling a Ribbon button in
the Load/Open/Activate and Current form events using the screen.activeform
or report property and sometimes it works and sometimes it doesn't due to
the fact that the active property is often still pointing at the previously
active Access object, therefore you are forced to use a global variable set
when you first open the object so that the callback knows which Access
object to call back into. You then must maintain this object reference in
every form/report and reset it when that becomes the active object.
4) I would like to use less Ribbons by sharing them amongst like
functionality within forms/reports but again then you have the problem of
maintaining Ribbon state and resetting the state when each form/report
becomes active.
This may be acceptable if you only have one or two Ribbons, but when you
have lots of Ribbons it means I am going to spend an inordinate amount of
time cutting code for every form/report just to manage the Ribbon.
Frankly I just think there must be a better way.
Anyway just my 2 cents worth of frustration.
Kind Regards,
Guy
Sorry if my previous posting's sounded like a reason to vent my frustration,
but to put things straight I like the Ribbon concept and as a person that
likes to talk to other knowlegable people including Access MVP's with which
I believe I have complimentary experience (29 years in software development
of all types from Assembler to Cobol to Fortran to Pascal on various O/S's
and Windows C, C++, SQL Windows, Borland Delphi & C++, all Oracle products
before 2000, all Microsoft Office products since 1990 including Access since
1.00 both mdb's and adp's, and RDBM's SQL Server, Oracle, Ingres even the
Poet ODBMS).
It is just that I feel the implementation of Ribbon management in A2007,
whilst in itself clever, is half baked, and in order to overcome the issues
we are forced to write less than robust code.
Imagine what my users are going to think when after a application error they
click on a Ribbon button and get the message "Object not initialized (or
something similar)".
Here are some of the other issues that I would like to highlight:
1) You change the XML for a Ribbon, and if it is already loaded, you
can't just reload it be recalling the Application.LoadCustomUI method, it
fails with a Ribbon already loaded error, so you have to exit the
application and start again.
2) Debugging the Ribbon using the Access Debug utility, which isn't as
smart as the .NET version, is a pain. Your stepping through some code
wondering why your button hasn't been disabled as intended and all the
callbacks fail meaning, you guessed it, all your variables, collections and
classes have been re-initialised. So you have to exit the application and
start again.
Ok so we have to use a non-invasive debugging technique such as
Debug.Print. Do Microsoft realise what the implications of this are? You
can nolonger properly debug a form or report that involves a Ribbon callback
unless you use Debug.Print, comment out all actions that may call a Ribbon
callback, or are confident that an Access error will not affect the code
that you are debugging.
3) The timing of callbacks in relation to the active Access object that
triggered them is also problematic. I've tried disabling a Ribbon button in
the Load/Open/Activate and Current form events using the screen.activeform
or report property and sometimes it works and sometimes it doesn't due to
the fact that the active property is often still pointing at the previously
active Access object, therefore you are forced to use a global variable set
when you first open the object so that the callback knows which Access
object to call back into. You then must maintain this object reference in
every form/report and reset it when that becomes the active object.
4) I would like to use less Ribbons by sharing them amongst like
functionality within forms/reports but again then you have the problem of
maintaining Ribbon state and resetting the state when each form/report
becomes active.
This may be acceptable if you only have one or two Ribbons, but when you
have lots of Ribbons it means I am going to spend an inordinate amount of
time cutting code for every form/report just to manage the Ribbon.
Frankly I just think there must be a better way.
Anyway just my 2 cents worth of frustration.
Kind Regards,
Guy