Documentation

[Alan Gillott]

Once upon a time in a VB living in sixteenbit land the documentation (was
free, but that's not my immediate point) at the front of the book was a
table of language elements grouped by function. Also of properties by
control etc. at those moments when suffering from brain freeze, a quick scan
of that table would set me on the path to the command I was looking for.
Example: if my brain is fixated on Remainder, it doesn't always leap to Mod.
Move and Name don't exactly gel and when VB6 was new Split & Join took a
while to wire themselves into my brain, not to mention the kluge of
functions around dates & times.
Even with online MSDN, a keyword search is only useful if you have all the
keywords.

Please Mr. Microsoft Documentation Product Manager reinstitute the Tables
last seen in the VB3 documentation that helped us navigate to the right set
of properties and methods. The current list keyed on Alpha within Type are
very time consuming.

When looking for a language construct: it isn't always obvious whether one
is looking for a command or method and it's **** frustrating to click
through 26 letters only to find it's the other or something else. With the
tables grouping commands, properties & Methods by functional area you have a
much better chance of building your routine using the best rather than the
first located function. PS. Don't assume See Also solves this: it doesn't;
those lists are inaccurate, incomplete and on occasion point to all sorts of
wierd rubbish.

[RJolt]

"Alan Gillott" <agillott@tact.com> wrote in message
news:38e39026$1@news.devx.com...
> Once upon a time in a VB living in sixteenbit land the documentation (was
> free, but that's not my immediate point) at the front of the book was a
> table of language elements grouped by function. Also of properties by
> control etc. at those moments when suffering from brain freeze, a quick
scan
> of that table would set me on the path to the command I was looking for.
> Example: if my brain is fixated on Remainder, it doesn't always leap to
Mod.
> Move and Name don't exactly gel and when VB6 was new Split & Join took a
> while to wire themselves into my brain, not to mention the kluge of
> functions around dates & times.
> Even with online MSDN, a keyword search is only useful if you have all the
> keywords.
>
> Please Mr. Microsoft Documentation Product Manager reinstitute the Tables
> last seen in the VB3 documentation that helped us navigate to the right
set
> of properties and methods. The current list keyed on Alpha within Type are
> very time consuming.
>
> When looking for a language construct: it isn't always obvious whether one
> is looking for a command or method and it's **** frustrating to click
> through 26 letters only to find it's the other or something else. With the
> tables grouping commands, properties & Methods by functional area you have
a
> much better chance of building your routine using the best rather than the
> first located function. PS. Don't assume See Also solves this: it doesn't;
> those lists are inaccurate, incomplete and on occasion point to all sorts
of
> wierd rubbish.

Got that now. 'F2' then select VBA library. It's all there at a glance.

[Mark Alexander Bertenshaw]

Hear, hear!!

--

---------------------------------------
Mark Alexander Bertenshaw
Programmer/Analyst
Prime Response
Brentford
UK

[Alan Gillott]

True
But it isn't broken down enough and it isn't on paper. It takes 4 or 5 times
longer to use the object browser than flip 3 or 4 sheets of paper, it takes
up screen real estate, and I can't use it when coding offline. I write a lot
of code on paper and type it in later.

RJolt <rjolt@iname.com> wrote in message news:38e3d5b3@news.devx.com...
> "Alan Gillott" <agillott@tact.com> wrote in message
> news:38e39026$1@news.devx.com...
> > Once upon a time in a VB living in sixteenbit land the documentation
(was
> > free, but that's not my immediate point) at the front of the book was a
> > table of language elements grouped by function. Also of properties by
> > control etc. at those moments when suffering from brain freeze, a quick
> scan
> > of that table would set me on the path to the command I was looking for.
> > Example: if my brain is fixated on Remainder, it doesn't always leap to
> Mod.
> > Move and Name don't exactly gel and when VB6 was new Split & Join took a
> > while to wire themselves into my brain, not to mention the kluge of
> > functions around dates & times.
> > Even with online MSDN, a keyword search is only useful if you have all
the
> > keywords.
> >
> > Please Mr. Microsoft Documentation Product Manager reinstitute the
Tables
> > last seen in the VB3 documentation that helped us navigate to the right
> set
> > of properties and methods. The current list keyed on Alpha within Type
are
> > very time consuming.
> >
> > When looking for a language construct: it isn't always obvious whether
one
> > is looking for a command or method and it's **** frustrating to click
> > through 26 letters only to find it's the other or something else. With
the
> > tables grouping commands, properties & Methods by functional area you
have
> a
> > much better chance of building your routine using the best rather than
the
> > first located function. PS. Don't assume See Also solves this: it
doesn't;
> > those lists are inaccurate, incomplete and on occasion point to all
sorts
> of
> > wierd rubbish.
>
> Got that now. 'F2' then select VBA library. It's all there at a glance.
>
>