A minor point re Access 2007 and ZoomControl

ZoomControl is a hidden property of reports. Setting it to zero, makes
the report fit the window.

The default view of a report created in Access 2007 seems to be Report
View rather than the default in previous Access versions which was, I
think, Print Preview. This may have something to do with Report Viiew
not existing previously.

Reports opened in Report View do not have the property "ZoomControl",
or the property cannot be referenced.
So code such as
Report_SchoolOrganizationandStaff.Visible = True
DoCmd.Maximize
Report_SchoolOrganizationandStaff.ZoomControl = 0
fails with error message 2455
"You entered an expression that has an invalid reference to the
Property ZoomControl"

If we set the default view of the report to Print Preview the code
runs without error.

Yes I know that it's likely that very few use this method of
optimizing how a report appears on the screen.

And yes, I know that some will think I am asking a question and make
some irrelevant suggestion.

I've not spent much time in seeing if I can set the View dynamically.
While CurrentView is designated as read-write in the help file, code
trying to set it returns a read-only error.

Lyle, I'm sure you realize that if you use an undocumeneted property like
ZoomControl, there's a risk it will break.

It's probably a simple thing to modify any existing code.
Perhaps something like this:

With Reports(0)
If .CurrentView = acCurViewPreview Then
.ZoomControl = 0
End If
End With

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"lyle fairfield" wrote in message
news:248f47a3-fbfa-4674-8d47-dff7ed7a4d86-at-d45g2000hsc.googlegroups.com...
> ZoomControl is a hidden property of reports. Setting it to zero, makes
> the report fit the window.
>
> The default view of a report created in Access 2007 seems to be Report
> View rather than the default in previous Access versions which was, I
> think, Print Preview. This may have something to do with Report Viiew
> not existing previously.
>
> Reports opened in Report View do not have the property "ZoomControl",
> or the property cannot be referenced.
> So code such as
> Report_SchoolOrganizationandStaff.Visible = True
> DoCmd.Maximize
> Report_SchoolOrganizationandStaff.ZoomControl = 0
> fails with error message 2455
> "You entered an expression that has an invalid reference to the
> Property ZoomControl"
>
> If we set the default view of the report to Print Preview the code
> runs without error.
>
> Yes I know that it's likely that very few use this method of
> optimizing how a report appears on the screen.
>
> And yes, I know that some will think I am asking a question and make
> some irrelevant suggestion.
>
> I've not spent much time in seeing if I can set the View dynamically.
> While CurrentView is designated as read-write in the help file, code
> trying to set it returns a read-only error.

Yep! In that way undocumented properties are just like documented
properties; they may break.

On Aug 27, 10:08*am, "Allen Browne"
wrote:
> Lyle, I'm sure you realize that if you use an undocumeneted property like
> ZoomControl, there's a risk it will break.

"lyle fairfield" wrote

> 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

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" wrote:
> "lyle fairfield" wrote
>
> *> 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

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" wrote in message
news:1c96c84b-d5ed-4b27-9e84-2edd3d10253e-at-k30g2000hse.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" wrote:
> "lyle fairfield" wrote
>
> > 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

"lyle fairfield" wrote in message
news:248f47a3-fbfa-4674-8d47-dff7ed7a4d86-at-d45g2000hsc.googlegroups.com...
> ZoomControl is a hidden property of reports. Setting it to zero, makes
> the report fit the window.
>
> The default view of a report created in Access 2007 seems to be Report
> View rather than the default in previous Access versions which was, I
> think, Print Preview. This may have something to do with Report Viiew
> not existing previously.
>
> Reports opened in Report View do not have the property "ZoomControl",
> or the property cannot be referenced.

Thanks for documenting this change in behavior, so everyone else can fix
their code before it happens.

- Steve