Re: References for VBA


"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.

> Finally, I've not been here long and haven't been on any Access newsgroups
> so can't comment on the comparison but I'm happy that you find the people
> here knowledgeable and helpful; I do too.
>
Thanks for bearing with me.

-Amy


.

Relevant Pages

  • Re: References for VBA
    ... > Amy Blankenship nous racontait que: ... >>> in Access, it's the mso constants that aren't defined, so ... ... >>> that might be missing. ... >> Why would that give a good indication of the reference that was ...
    (microsoft.public.word.vba.userforms)
  • Re: macros using 2 open documents.
    ... We seem to be failing to communicate. ... relevant to the technical solution you are asking for. ... You previously used Windowsand Windowsto reference two documents. ... >> Windows.Activate and the macro worked fine flipping back and forth. ...
    (microsoft.public.word.vba.general)
  • Re: References for VBA
    ... > for yourself and when you do, it's a failing in the product and/or ... >>> Hi Amy, ... >>> Access, it's the mso constants that aren't defined, so ... ... >> Why would that give a good indication of the reference that was missing? ...
    (microsoft.public.word.vba.userforms)
  • Re: Problems with Runtime 2007
    ... Thanks for responding...i think it's the FileSystemObject that is failing as ... Is FileSystemObject or the kill command failing? ... works fine and i have used late binding to avoid outlook reference problems. ... Set objmail = olapp.CreateItem ...
    (microsoft.public.access.modulesdaovba)
  • Re: [patch 16/17] Immediate Values - Documentation
    ... On Thursday 10 April 2008 01:08:45 Mathieu Desnoyers wrote: ... Failing to do so will leave a reference to ... the __init section after it is freed (it would generate a modpost ...
    (Linux-Kernel)