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.
20  5144 
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
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
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
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.
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
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.
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
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.
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
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.
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
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
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.
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.
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
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 !!
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
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
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Wayne |
last post by:
I've been clicking around Access 2007 Beta 2 and can't see the custom
menu bar designer. Is it in the beta? Maybe I'm blind. The question
that comes to mind is: Will custom menu bars be the same...
|
by: bobdydd |
last post by:
Hi All
I am currently rebuilding one of my Access 2000 applications in Access
2007.
On the Access 2000 application I had 2 Tool bars and a shortcut menu
on most of the forms/reports
1. A...
|
by: Jeff |
last post by:
This is something I can't test (don't have 2007) and found no definitive
answer, but a few conflicting ones.
Will a 2003 database work correctly in Access 2007?
Don't want to do any design...
|
by: ppardi |
last post by:
I'm developing an addin for Word 2007 and I need to determine whether a user
saves a Word 2007 document in an older format (97-2003) after a save as is
done. The scenario is that the user starts...
|
by: Kiers |
last post by:
Hi,
i have a application database written in A2K3 that i have converted to
A2K7 and i am looking to create an application ribbon that i can ship
with the runtime. It would be fair to say that i...
|
by: Brian Nelson |
last post by:
Sorry for the long post, I've tried so hard to solve this one but I'm
just stuck!
We've had a multiuser .mdb file on a network share for years. I know
it's not ideal, but it's worked well from...
|
by: Tony |
last post by:
I am continuing to develop an Access 2007 application which was
originally converted from Access 2003. In Access 2003 I was able to
disable the Access Close button in the top righthand corner of...
|
by: ARC |
last post by:
Hello all,
In Access 2007, is there a way to determine if a user has their ribbons
minimized? If they do, I'd like to put up a warning.
Many thanks,
Andy
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
