There are other reasons besides "not completely tested" for functions being
undocumented.
One might be "Oh, my, just think what fun Lyle could have with this
function. He might get carried away and do something rash. We'd better not
document it."
Seriously, there are functions left undocumented so they won't have to be
supported and so there's no implication that they will be in some future
version.
[Some | a few | many] are things that the Access team uses in development
and testing, so they are left in, but leaving them in for the Access team
does not obligate Microsoft, as noted above. Then, sooner or later, someone
finds them, the word gets out, and Microsoft (although they could do so)
won't take them away because doing so could cause a storm of resentment.
Larry
"lyle fairfield" <ly************@gmail.comwrote in message
news:1c**********************************@k30g2000 hse.googlegroups.com...
I can't think of an undocumented feature that has broken. I have
used .Collect innumerable times over many years. I have used the
Wizhook functions less extensivley but they have never hiccoughed.
And Goto ...
And ....
ZoomControl did not break. It was a property of a report opened in
Print Preview. It still is.
But it was not extended to Report View. I'm not familiar enough with
Report View to venture an opinion as to whether or not the existence
of the ZoomControl property makes no sense in ReportView, whether it
might have been left out indavertantly or whether it might have been
left out as an initial step in terminating the property altogether.
I intended to alert anyone else who might have experienced the error
that puzzled me for a few minutes as to its cause.
As to its solution, Alan's code is not sufficient for me. For using it
will not ZoomControl to zero if the default view of the report is
Report View. It will just pass over setting this property.
As I do want to set the ZoomControl to zero, I will set my default
view too Print Preview.
Documented Properties have broken.
http://groups.google.com/group/comp....240252032dc60#
may show that a documented procedure, reading a value from a control,
worked until 2003, but not in 2007. This may not have been a huge
break, but it is at least a tiny crack.
On Aug 27, 1:27 pm, "Larry Linson" <boun...@localhost.notwrote:
"lyle fairfield" <lyle.fairfi...@gmail.comwrote
Yep! In that way undocumented properties are just
like documented properties; they may break.
But because the particular property is prone to breakage may well be the
reason _why_ it is undocumented. Based on "a few years in a corporate
environment (not Microsoft)", I might speculate that if testing shows up
problems in a feature/function, it may be much simpler to just leave it in
the product and not publicize it than to extract it from the product and
retest to assure that extracting it didn't cause worse problems -- and,
perhaps, someone has hopes that a little testing and a small hotfix will
allow it to be documented/publicized in the future.
Larry
