Re: References for VBA
- From: "Jean-Guy Marcil" <NoSpam@LeaveMeAlone>
- Date: Tue, 18 Oct 2005 14:05:54 -0400
Amy Blankenship was telling us:
Amy Blankenship nous racontait que :
> "Tony Jollans" <No Mail> wrote in message
> news:uai6ld70FHA.2064@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi Amy,
>>
>> You seem to be suggesting that because you've found one anomaly in
>> Access where the help file wasn't entirely accurate that there is
>> some kind of Office-wide implication. Don't you think that maybe
>> that's jumping to conclusions?
>>
>> Help is not entirely accurate all over the place in all of Office and
>> elsewhere and, in general, Office help (pre-2003 anyway) is better
>> than average. One can argue that it shouldn't be the case but the
>> reality of the
>> world is that documentation always comes second to functionality. One
>> hopes
>> that errors are corrected but the chances of that are higher if the
>> failings
>> are pointed out and a failing in Access help (and, even more so, a
>> failing in Access itself) should surely be pointed out in an Access
>> forum. For what it's worth, it seems to me that it is probably Access,
>> rather than
>> the help, which is at fault. Office is gradually moving towards
>> being a fully integrated suite rather than a collection of disparate
>> programs and this seems to me to be a point where Access has yet to
>> be fully brought into
>> line.
>>
>> For the record, it's not actually the FileDialog which doesn't work
>> in Access, it's the mso constants that aren't defined, so ...
>>
>> Set dlg = Application.FileDialog(3)
>>
>> .. would have worked. That kind of thing is always worth checking
>> when you have an error and, in this case it gives a good indication
>> of the reference
>> that might be missing.
>
> Why would that give a good indication of the reference that was
> missing? Where would I find that the mso constants are defined within
> a specific reference (which goes back to the origninal question). I
> never intended to suggest that the Help should be perfect or should
> be viewed without doing your own research. What I asked originally,
> and am STILL asking, is how to figure out what references are needed
> for a particular piece of code to work. That's GOT to be listed
> somewhere. Obviously YOU learned from somewhere that the mso
> constants are defined in the Office reference, so that information
> has to exist somewhere. That's all I'm asking, really...is where to
> get that information.
What version of Access are you using? Did you type the code or did you cut
and paste it?
In Access 2003, when I type the following:
Application.FileDialog(
then as soon as I type that "(" I get the IntelliSense dropdown list
offering me to choose between 4 constants (the mso constants you used in
your code). As soon as I pick one, Access warns me that a reference library
is missing and offers me to add it to the list of active references. If I
choose "Yes", the Office Object Library is automatically loaded. So, it
seems to me that it works OK, as long as you type the code yourself. But, I
am no expert with Access, so, maybe you should post about that particular
point in an Access group.
The difference with Word, Excel and PowerPoint is that when you create an
Access project, Access does not load the Office Object Library. As Tony
mentioned, as soon as you see "mso", this tells you that it comes from the
Office library and if it is not loaded, you probably will get some problems.
Once it is loaded, do F2, and in the Object browser, find
"msoFileDialogType" in the classes (the column on the left). Then, on the
right, in the "Members" pane, you will see all four constants, click on one
and look at the bottom. You will see the numerical value of the constant you
have selected.
Again, as Tony mentioned, this is more of an annoyance than a bug because
the Office Object Library is automatically loaded with most Office
applications, but not Access. Remember that all Office applications have
very different origins and creators, they have been put under one big
umbrella and ever since Microsoft tries to standardize them as much as
possible without having to rewrite each application to bring them in line
(which would make older documents incompatible).
--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
jmarcilREMOVE@xxxxxxxxxxxxxxxxxxxxxxx
Word MVP site: http://www.word.mvps.org
.
- Follow-Ups:
- Re: References for VBA
- From: Amy Blankenship
- Re: References for VBA
- From: Tony Jollans
- Re: References for VBA
- References:
- References for VBA
- From: Amy Blankenship
- Re: References for VBA
- From: Jonathan West
- Re: References for VBA
- From: Jonathan West
- Re: References for VBA
- From: Amy Blankenship
- Re: References for VBA
- From: Jonathan West
- Re: References for VBA
- From: Amy Blankenship
- Re: References for VBA
- From: Jonathan West
- Re: References for VBA
- From: Amy Blankenship
- Re: References for VBA
- From: Tony Jollans
- Re: References for VBA
- From: Amy Blankenship
- Re: References for VBA
- From: Tony Jollans
- Re: References for VBA
- From: Amy Blankenship
- References for VBA
- Prev by Date: Re: References for VBA
- Next by Date: Re: References for VBA
- Previous by thread: Re: References for VBA
- Next by thread: Re: References for VBA
- Index(es):
Relevant Pages
|