 | |
Ping Tony Toews - AutoFe question
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Ping Tony Toews - AutoFe question -
12-17-2009
, 08:07 PM
#2
| |||
| |||
|
|
Let's say all users have A2003 and A2007. I guess by using the following it should always start A2003 for the app. ;this is the expected default directory Shell="C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" StartMethod=FIlePath But what does one use if MSAccess.EXE is stored in Shell="C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" or Shell="C:\OFFICE\MSACCESS.EXE" or Shell="C:\Program Files\Office\MSACCESS.EXE" Does one have 3 INI files? Is there a better way of doing this so A2003 fires each time? |
haven't had too many questions on this so I've let is slide. But now seems like a
good as time as any to discuss.
The closest I've come to so far is using the StartMethod=FileExtension which uses
the version of Access that is associated with the MDB/ACCDE/etc file extension.
This,of course, doesn't answer your problem directly.
So I should add some kind of line that states what version of Access it should run.
Which I can determine from registry keys. (See HKLM\software\microsoft\office\
Although the runtime could cause a few quirks there. Any suggestions on what I
should I use for the keyword? PreferredVersion=?
Options would be 97, 2000, 2002, 2003, 2007, 2010 or 8,9,10,11,12 or 14? Do Access
folks, even those with no VBA skills understand that version 12 is really 2007? No,
I should allow for either of those to exist.
Or should I put the version number in the StartMethod line?
Now the problem is what happens if
- some of the workstations have only the preferred version - which is fine
- others have two versions - which is fine
- but others have a different version - ????
How do I resolve this?
BTW I'm working on wizard functionality and hope to have that on my website in a few
days. So I'm quite willing to discuss this with you and see what we can come up with
and see if I can implement it for you easily and quickly.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
#3
| |||
| |||
|
#4
| ||||
| ||||
|
|
Salad <salad (AT) oilandvinegar (DOT) com> wrote: Let's say all users have A2003 and A2007. I guess by using the following it should always start A2003 for the app. ;this is the expected default directory Shell="C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" StartMethod=FIlePath But what does one use if MSAccess.EXE is stored in Shell="C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" or Shell="C:\OFFICE\MSACCESS.EXE" or Shell="C:\Program Files\Office\MSACCESS.EXE" Does one have 3 INI files? Is there a better way of doing this so A2003 fires each time? This is something I haven't yet addressed in a proper fashion and I should. I also haven't had too many questions on this so I've let is slide. But now seems like a good as time as any to discuss. The closest I've come to so far is using the StartMethod=FileExtension which uses the version of Access that is associated with the MDB/ACCDE/etc file extension. This,of course, doesn't answer your problem directly. So I should add some kind of line that states what version of Access it should run. Which I can determine from registry keys. (See HKLM\software\microsoft\office\ Although the runtime could cause a few quirks there. Any suggestions on what I should I use for the keyword? PreferredVersion=? Options would be 97, 2000, 2002, 2003, 2007, 2010 or 8,9,10,11,12 or 14? Do Access folks, even those with no VBA skills understand that version 12 is really 2007? No, I should allow for either of those to exist. Or should I put the version number in the StartMethod line? |
perhaps check for the length of the year and allow the user to enter 00,
02, 03, etc. This would maintain consistency.
Personally, I would not use the 8, 9, 10...it isn't as "verbose" or
description as the other method of noting the version. It's more of a
"Microsoft developer at Microsoft" naming scheme, not a typical user's
or developers way of descibing the Office version. If I want to buy
Office, I might look for Office 2010, not Office 14.
Quote:
|
Now the problem is what happens if - some of the workstations have only the preferred version - which is fine - others have two versions - which is fine - but others have a different version - ???? |
entered 2003, then check for Office 2003. If that isn't avalble, check
for Office 2007. If not available, then Office 2010. If no vernsion is
matched, inform operator they need verson 2003 or greater. Does that
make sense? IOW, if the user has a previous version to the one
specified, it isn't allowed and that the expected version to use is 2003
or that one can attempt to use but there might be errors. But if user
has a version greater than the version specified in the INI file, then
try that. I think that way, a newer version will be able to handle the
features of the older version. But an older version might not.
Quote:
|
How do I resolve this? BTW I'm working on wizard functionality and hope to have that on my website in a few days. So I'm quite willing to discuss this with you and see what we can come up with and see if I can implement it for you easily and quickly. |
will be going to 2007. So I, and a couple of other people, will have
multiple versions. Preferably I'd like the people to open it up in
2003, even if they have 2007. Once blessing has been given to the app
for 2007, then I can change it so that it opens with 2007...or above.
BTW, that problem I had earlier where I could not execute the
StartMDB.Exe was a network security problem and now works.
I am curious how you are able to copy the files over so fast if
required. They really zip along.
Quote:
| Tony |
#5
| |||
| |||
|
|
BTW, that problem I had earlier where I could not execute the StartMDB.Exe was a network security problem and now works. |
Quote:
|
I am curious how you are able to copy the files over so fast if required. They really zip along. |
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
#6
| |||
| |||
|
|
Options would be 97, 2000, 2002, 2003, 2007, 2010 or 8,9,10,11,12 or 14? Do Access folks, even those with no VBA skills understand that version 12 is really 2007? No, I should allow for either of those to exist. Or should I put the version number in the StartMethod line? I think, if you are using 2000, 2002, etc, then 97 should be 1997 or perhaps check for the length of the year and allow the user to enter 00, 02, 03, etc. This would maintain consistency. Personally, I would not use the 8, 9, 10...it isn't as "verbose" or description as the other method of noting the version. It's more of a "Microsoft developer at Microsoft" naming scheme, not a typical user's or developers way of descibing the Office version. If I want to buy Office, I might look for Office 2010, not Office 14. |
we do use 97 all by itself. So I think I'm going to stick with 97, 2000, 2002, 2003,
2007, 2010, etc.
Now I'm also thinking I should allow this to be a table in the AutoFEUPdater.INI
file. As I do some registry lookups with the 10.0, 11.0, 12.0, etc. This way you
could continue to use the AutoFEUpdater long after my death. Which is highly
unlikely at this poimt and I do have a succession plan anyhow as docmented on my
website. But I'm being somewhat silly on this one and am not going to implement this
one too soon.
Quote:
|
Now the problem is what happens if - some of the workstations have only the preferred version - which is fine - others have two versions - which is fine - but others have a different version - ???? I might have a table or array of the versions in your code. If I entered 2003, then check for Office 2003. If that isn't avalble, check for Office 2007. If not available, then Office 2010. If no vernsion is matched, inform operator they need verson 2003 or greater. Does that make sense? IOW, if the user has a previous version to the one specified, it isn't allowed and that the expected version to use is 2003 or that one can attempt to use but there might be errors. But if user has a version greater than the version specified in the INI file, then try that. I think that way, a newer version will be able to handle the features of the older version. But an older version might not. |
Now I could actually use that table or Enum as I'm starting to have some long Select
Case statements on the various versions when I need to do some registry keep lookups.
Seems that the Access product group didn't become real consistent in their registry
key naming standards until about 2000 or so. But they've become quite consistent
since then.
Quote:
|
BTW I'm working on wizard functionality |
with it. Not yet code complete but just to get folks fo give me some feedback.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
#7
| |||
| |||
|
|
I might have a table or array of the versions in your code. If I entered 2003, then check for Office 2003. If that isn't avalble, check for Office 2007. If not available, then Office 2010. If no vernsion is matched, inform operator they need verson 2003 or greater. Does that make sense? |
StartMethod=PreferrredVersion-2003. So the program will start with A2003 and look
for Access 2003 or newer.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
#8
| |||
| |||
|
|
Salad <salad (AT) oilandvinegar (DOT) com> wrote: I might have a table or array of the versions in your code. If I entered 2003, then check for Office 2003. If that isn't avalble, check for Office 2007. If not available, then Office 2010. If no vernsion is matched, inform operator they need verson 2003 or greater. Does that make sense? Almost got it done. I'm going to use the following syntax: StartMethod=PreferrredVersion-2003. So the program will start with A2003 and look for Access 2003 or newer. Tony |
#9
| |||
| |||
|
|
So Cool. |
BTW email me so I can promptly email you when the hot fix is ready.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
#10
| |||
| |||
|
|
Almost got it done. I'm going to use the following syntax: StartMethod=PreferrredVersion-2003. So the program will start with A2003 and look for Access 2003 or newer. |
Also to anyone else who is reading this please download it and play with the new
wizard logic and give me some feedback.
Thanks, Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.