By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,218 Members | 1,326 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,218 IT Pros & Developers. It's quick & easy.

Using LoadCustomUI for Ribbons in 2007, but need to be able tocompile in 2003

P: n/a
KW
I have an application that runs in any of Access 2000 thru Access 2007
to accommodate my customers' various environments. I implemented code
to call a function that uses the LoadCustomUI method to load in my
custom ribbon for Access 2007. This function is called only when the
check for running Access version 12 or higher is true.

Everything works like I want in Access 2007. The problem is when I
compile it on Access 2000,2002,2003, the LoadCustomUI method causes an
error indicating method or data member not found (because it is new to
2007 obviously). I tried to define LoadCustomUI as an object, but
haven't been able to get that to work.

Is there any way to get this to compile on Access 2003 aside from
commenting out the LoadCustomUI call?

Thanks for any suggestions.
Oct 6 '08 #1
Share this Question
Share on Google+
20 Replies


P: n/a
You can use a conditional compile for Access 2000 and 2002, but if you use it
for Access 2003 you won't be able to convert it into an mde file if you have
sp1 or less. Don't know if it's fixed on later service packs. Example:

(Use a custom function to determine if it's being compiled by Access 2007.)

dim isAccess2007 as boolean

isAccess2007 = funcDBisAccess2007()

#if isAccess2007 = true then
... LoadCustomUI ...
#end if

If you need to convert to mde in Access 2003, try it with sp2 or sp3 and see
if it works. If it doesn't you need to comment out the conditional compile
instructions and the LoadCustomUI code, but only for Access 2003. The
conditional compilation code works for the earlier versions' mde conversions.

An alternative if you require mdes is to convert to Access 2000 db format and
convert that to mde in Access 2000 and run it in the other versions of Access.
Chris
Microsoft MVP
KW wrote:
>I have an application that runs in any of Access 2000 thru Access 2007
to accommodate my customers' various environments. I implemented code
to call a function that uses the LoadCustomUI method to load in my
custom ribbon for Access 2007. This function is called only when the
check for running Access version 12 or higher is true.

Everything works like I want in Access 2007. The problem is when I
compile it on Access 2000,2002,2003, the LoadCustomUI method causes an
error indicating method or data member not found (because it is new to
2007 obviously). I tried to define LoadCustomUI as an object, but
haven't been able to get that to work.

Is there any way to get this to compile on Access 2003 aside from
commenting out the LoadCustomUI call?
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 6 '08 #2

P: n/a
KW
That sounds promising, and it does compile on Access 2003 now, but
when I move the mde to Access 2007 and run it there, it does not
execute the code to call LoadCustomUI. I've never done conditional
compiles, so I may have a miunderstanding. Here are snippets of the
code:

Dim is2007 As Boolean

is2007 = IsAccess2007()

#If is2007 = True Then
......
......
Application.LoadCustomUI recSet!RibbonName, recSet!RibbonXml
......
......
#End If

Exit Function
......
......
Function IsAccess2007() As Boolean

If Left(Application.Version, 2) = "12" Then
IsAccess2007 = True
Else
IsAccess2007 = False
End If

End Function

Thanks.
KW
Oct 6 '08 #3

P: n/a
To avoid problems, you should *always* compile in the version you're running
before running any code. That doesn't apply to mde and accde files because
the code is already compiled.

Specifically, when you conditionally compile because of version limitations,
you *must* compile for *that* version.

You need to compile in Access 2007 for the apps that will run in Access 2007,
you need to compile in Access 2000 for apps that will run in Access 2000, etc.
Because of the conditional compile command that's checking for the Access
2007 version, the db compiled in Access 2000 will run in 2000, 2002 and 2003,
but not 2007 (because is2007 was false when it was compiled in Access 2000).
But like I said, you should compile the vba code for the version you're
running to avoid problems with libraries, etc.

Chris
Microsoft MVP

KW wrote:
>That sounds promising, and it does compile on Access 2003 now, but
when I move the mde to Access 2007 and run it there, it does not
execute the code to call LoadCustomUI.
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 6 '08 #4

P: n/a
KW
On Oct 6, 4:35*pm, "Chris O'C via AccessMonster.com" <u29189@uwe>
wrote:
To avoid problems, you should *always* compile in the version you're running
before running any code. *That doesn't apply to mde and accde files because
the code is already compiled.

Specifically, when you conditionally compile because of version limitations,
you *must* compile for *that* version.

You need to compile in Access 2007 for the apps that will run in Access 2007,
you need to compile in Access 2000 for apps that will run in Access 2000,etc.
Because of the conditional compile command that's checking for the Access
2007 version, the db compiled in Access 2000 will run in 2000, 2002 and 2003,
but not 2007 (because is2007 was false when it was compiled in Access 2000).
But like I said, you should compile the vba code for the version you're
running to avoid problems with libraries, etc.

Chris
Microsoft MVP

KW wrote:
That sounds promising, and it does compile on Access 2003 now, but
when I move the mde to Access 2007 and run it there, it does not
execute the code to call LoadCustomUI.

--
Message posted via AccessMonster.comhttp://www.accessmonster.com/Uwe/Forums.aspx/databases-ms-access/2008...
Sorry, I should have explained further. I am maintaining one code set
at Access 2000 to accommodate my customers who are executing the
resulting mde on either 2000, 2002, 2003 or 2007. Of course I am
pushing them all to upgrade to 2007, but its not something I can
dictate. At any rate, the mdes are compiled on 2000. Since the last
post I discovered the Application.Version statement does not compile
on 2000, so I'm not sure how to determine the version that is being
executed. And as you have probably determined, I forgot to create the
mde before trying your solution on 2007. I'll have to figure out a
way to test for the version being executed before I can test your
solution.
Oct 6 '08 #5

P: n/a
You'll be maintaining 1 code set but 2 mdes because you want to run code that
works in some but not all versions of Access. You need a 2007 mde for the
Access 2007 customers and a 2000 mde for all the other customers.

You can use SysCmd (acSysCmdAccessVer) in any version of Access to find which
version is running the code.

Chris
Microsoft MVP
KW wrote:
>Sorry, I should have explained further. I am maintaining one code set
at Access 2000 to accommodate my customers who are executing the
resulting mde on either 2000, 2002, 2003 or 2007. Of course I am
pushing them all to upgrade to 2007, but its not something I can
dictate. At any rate, the mdes are compiled on 2000. Since the last
post I discovered the Application.Version statement does not compile
on 2000, so I'm not sure how to determine the version that is being
executed. And as you have probably determined, I forgot to create the
mde before trying your solution on 2007. I'll have to figure out a
way to test for the version being executed before I can test your
solution.
--
Message posted via http://www.accessmonster.com

Oct 6 '08 #6

P: n/a
KW
That's exactly what I was trying to avoid which is why I tried
defining LoadCustomUI as an object to satisfy the unresolved method
when compiling with Access 2000.

Now I understand why the conditional compile will not work.
Thanks anyway.
Oct 6 '08 #7

P: n/a
Which do you think works better:

1 - 1 code set with conditional compile and 2 mdes, one for Access 2007 and
one for the other versions

2 - 2 code sets with commented out lines, one for Access 2007 and one for the
other versions, and 2 mdes, one for Access 2007 and one for the other
versions

Chris
Microsoft MVP
KW wrote:
>That's exactly what I was trying to avoid which is why I tried
defining LoadCustomUI as an object to satisfy the unresolved method
when compiling with Access 2000.

Now I understand why the conditional compile will not work.
Thanks anyway.
--
Message posted via http://www.accessmonster.com

Oct 6 '08 #8

P: n/a
KW
I thought you were saying that with the conditional compile, the mde
had to be created on the same access version as the version under
which the mde would be executed. If that is not the case, then the
conditional compile should work for me and I don't understand why the
#if statement is always evaluating to false.
Oct 7 '08 #9

P: n/a
Because once converted to an mde the conditional compile code doesn't get
saved in the mde as a normal if-block if the condition was false. Your code
checks if the version is 2007 and doesn't do anything with that info because
the conditional compilation code was discarded in Access 2000's mde
conversion.

If you converted the file to mde in Access 2000, there's no LoadCustomUI code
in the mde. If you converted the file to mde in Access 2007, it contains the
LoadCustomUI code, because it met this condition:

#if is2007 = true then

So you need to run the Access 2000 mde in Access 2000, 2002 or 2003, and run
the Access 2007 mde in Access 2007 because the latter mde is the one with the
LoadCustomUI code.

You said "I thought you were saying that with the conditional compile, the
mde had to be created on the same access version as the version under which
the mde would be executed."

I said "Specifically, when you conditionally compile because of version
limitations, you *must* compile for *that* version."

What I mean is that you specifically want to use code that is only available
in Access 2007, so Access 2007 needs its own separate mde. The mde created
in a conditional compile for earlier versions won't work in Access 2007
because the condition wasn't met at compile time. Access 2007 mdes don't run
on earlier versions so you have to create an mde in an earlier version. The
earlier version mde will also run in Access 2007 but they'll lack the "Access
2007 only" code because that wasn't included in the earlier version's mde as
I explained above.

Chris
Microsoft MVP
KW wrote:
>I thought you were saying that with the conditional compile, the mde
had to be created on the same access version as the version under
which the mde would be executed. If that is not the case, then the
conditional compile should work for me and I don't understand why the
#if statement is always evaluating to false.
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 7 '08 #10

P: n/a
KW
So now I'm back to where I started. With the conditional statements,
creating the mde on 2000 will never include the LoadCustomUI, but I
can't create the mde on Access 2007 because the .mdb is stored in 2000
format. So any time code is changed, I would have to copy the .mdb to
2007 (convert it to 2007 format) so that I can create the .mde in 2007.
Oct 7 '08 #11

P: n/a
That's why you don't let customers upgrade to incompatible versions with the
rest of your customers' versions.

You can still maintain the code base in Access 2000, but you have additional
steps for your Access 2007 distributions. You aren't required to keep an
Access 2007 mdb and keep updating that file. Just make your changes to the
Access 2000 mdb, convert to 2007 mdb and convert that to Access 2007 mde and
test that before distribution. You can discard the intermediary Access 2007
mdb so there's no confusion which mdb developers should be working on.

Chris
Microsoft MVP
KW wrote:
>So now I'm back to where I started. With the conditional statements,
creating the mde on 2000 will never include the LoadCustomUI, but I
can't create the mde on Access 2007 because the .mdb is stored in 2000
format. So any time code is changed, I would have to copy the .mdb to
2007 (convert it to 2007 format) so that I can create the .mde in 2007.
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 7 '08 #12

P: n/a
KW wrote:
So now I'm back to where I started. With the conditional statements,
creating the mde on 2000 will never include the LoadCustomUI, but I
can't create the mde on Access 2007 because the .mdb is stored in 2000
format. So any time code is changed, I would have to copy the .mdb to
2007 (convert it to 2007 format) so that I can create the .mde in
2007.
Why don't you just have your 2007 users run the same file as your other
users? I create MDEs in 2000 and people can run them just fine in 2007. Of
course they get standard menus and toolbars, not ribbons, but why would that
be a problem?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Oct 7 '08 #13

P: n/a
KW
Why don't you just have your 2007 users run the same file as your other
users? *I create MDEs in 2000 and people can run them just fine in 2007.. *Of
course they get standard menus and toolbars, not ribbons, but why would that
be a problem?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt * at * Hunter * dot * com
Because I don't want them to have access to the standard ribbon and
Access Options where they would have complete control including
getting to the tables directly versus only through the application
forms and reports. And I want to be able to automatically load the
ribbon I have defined whenever a new version is released.
Oct 8 '08 #14

P: n/a
KW
On Oct 7, 12:22*pm, "Chris O'C via AccessMonster.com" <u29189@uwe>
wrote:
That's why you don't let customers upgrade to incompatible versions with the
rest of your customers' versions.

You can still maintain the code base in Access 2000, but you have additional
steps for your Access 2007 distributions. *You aren't required to keep an
Access 2007 mdb and keep updating that file. *Just make your changes tothe
Access 2000 mdb, convert to 2007 mdb and convert that to Access 2007 mde and
test that before distribution. *You can discard the intermediary Access2007
mdb so there's no confusion which mdb developers should be working on.

Chris
Microsoft MVP

KW wrote:
So now I'm back to where I started. *With the conditional statements,
creating the mde on 2000 will never include the LoadCustomUI, but I
can't create the mde on Access 2007 because the .mdb is stored in 2000
format. *So any time code is changed, I would have to copy the .mdb to
2007 (convert it to 2007 format) so that I can create the .mde in 2007.

--
Message posted via AccessMonster.comhttp://www.accessmonster.com/Uwe/Forums.aspx/databases-ms-access/2008...
The customers comprise completely different companies. You can't just
dictate whole companies to be at the same level you want them to be;
easier said than done.
Thanks for your input regarding version control.
Oct 8 '08 #15

P: n/a
When you tell them "all our other customers are on Access 2000 thru 2003 so
it will cost you an extra $XXXX per year if you want us to support Access
2007, too" it's very effective in defining which version of your app they use.
Chris
Microsoft MVP
KW wrote:
>You can't just
dictate whole companies to be at the same level you want them to be;
easier said than done.
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 8 '08 #16

P: n/a
KW
On Oct 8, 11:29*am, "Chris O'C via AccessMonster.com" <u29189@uwe>
wrote:
When you tell them "all our other customers are on Access 2000 thru 2003 so
it will cost you an extra $XXXX per year if you want us to support Access
2007, too" it's very effective in defining which version of your app theyuse.

Chris
Microsoft MVP

KW wrote:
You can't just
dictate whole companies to be at the same level you want them to be;
easier said than done.

--
Message posted via AccessMonster.comhttp://www.accessmonster.com/Uwe/Forums.aspx/databases-ms-access/2008...
Actually I have already done that and they are paying the extra; one
of the companies will even be paying that until their Office 2007
upgrade scheduled for 2010 !!
Oct 8 '08 #17

P: n/a
You're already getting paid for the extra work (and some would argue getting
paid for work you're not doing for the company who's paying but hasn't
upgraded yet) the - and you're complaining about a few extra steps at mde
creation time?

You're not gaining any sympathy from this group.

Chris
Microsoft MVP
KW wrote:
>On Oct 8, 11:29*am, "Chris O'C via AccessMonster.com" <u29189@uwe>
wrote:
>When you tell them "all our other customers are on Access 2000 thru 2003 so
it will cost you an extra $XXXX per year if you want us to support Access
>Actually I have already done that and they are paying the extra; one
of the companies will even be paying that until their Office 2007
upgrade scheduled for 2010 !!
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200810/1

Oct 8 '08 #18

P: n/a
KW wrote:
>Why don't you just have your 2007 users run the same file as your
other users? I create MDEs in 2000 and people can run them just fine
in 2007. Of course they get standard menus and toolbars, not
ribbons, but why would that be a problem?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Because I don't want them to have access to the standard ribbon and
Access Options where they would have complete control including
getting to the tables directly versus only through the application
forms and reports. And I want to be able to automatically load the
ribbon I have defined whenever a new version is released.
If you disable the built in menus and toolbars and provide custom ones for
your users with 2000 to 2003 then those settings will still work in 2007.
There is no reason to do anything extra for 2007 users.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Oct 8 '08 #19

P: n/a
KW
I found what I needed at
http://geeks.ms/blogs/access/archive...bonandvba.aspx

Using the following statement instead of LoadCustomUI works just fine
and does not cause any compile errors on Access 2000/2002/2003.

CurrentDb.Properties.Append CurrentDb.CreateProperty("CustomRibbonID",
dbText, "MyRibbon")

This of course requires that the ribbon, MyRibbon, is already defined
in the USysRibbons table.
Oct 8 '08 #20

P: n/a
Good job, thanks for sharing the info! Here's the English translation:

http://translate.google.com/translat...-8&sl=es&tl=en
Chris
Microsoft MVP
KW wrote:
>I found what I needed at
http://geeks.ms/blogs/access/archive...bonandvba.aspx

Using the following statement instead of LoadCustomUI works just fine
and does not cause any compile errors on Access 2000/2002/2003.

CurrentDb.Properties.Append CurrentDb.CreateProperty("CustomRibbonID",
dbText, "MyRibbon")

This of course requires that the ribbon, MyRibbon, is already defined
in the USysRibbons table.
--
Message posted via http://www.accessmonster.com

Oct 8 '08 #21

This discussion thread is closed

Replies have been disabled for this discussion.