How to bring window to top

[Gord]

How do I bring a window (in this case a report) within Access to the top
using code? i.e. make the report viewable (this is after it has already
been opened of course)

Thanks,

Gord

[Chris O'C via AccessMonster.com]

DoCmd.OpenReport "nameofreport", acViewPreview

Chris
Microsoft MVP
Gord wrote:

>How do I bring a window (in this case a report) within Access to the top
using code? i.e. make the report viewable (this is after it has already
been opened of course)

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200808/1

[Gord]

Thanks Chris

I had already used this line (using 'acViewReport' instead) previously but
had "assumed" that I couldn't use the 'OpenReport' command a second time
after a report was already open.

Works just fine though.

I have another question that just came to mind (since you're on-line at the
moment) if you have a minute.

In using VB with Access, does one always have to set the focus on a control
on a form before referring to it in code? Using regular VB6, you don't have
to and it's quite intuitive. I get an error with VB in Access that I can't
refer to a control that doesn't have the focus. If true, is there a better,
more accepted way of referring to controls on a form rather than having to
always set the focus first?

Thanks again.

Gord

"Chris O'C via AccessMonster.com" <u29189@uwewrote in message
news:89821b8199a8b@uwe...

DoCmd.OpenReport "nameofreport", acViewPreview

Chris
Microsoft MVP
Gord wrote:

>>How do I bring a window (in this case a report) within Access to the top
using code? i.e. make the report viewable (this is after it has already
been opened of course)

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200808/1

[Chris O'C via AccessMonster.com]

If you use the text property of a control in code, you have to set focus to
it first before reading it. If you use the value property (the default), you
don't have to set focus to it first.

if (me.textboxname.value = "east") then
'do something
else
'do something else
end if

or

if (me.textboxname = "east") then
'do something
else
'do something else
end if
Chris
Microsoft MVP
Gord wrote:

>Thanks Chris

I had already used this line (using 'acViewReport' instead) previously but
had "assumed" that I couldn't use the 'OpenReport' command a second time
after a report was already open.

Works just fine though.

I have another question that just came to mind (since you're on-line at the
moment) if you have a minute.

In using VB with Access, does one always have to set the focus on a control
on a form before referring to it in code? Using regular VB6, you don't have
to and it's quite intuitive. I get an error with VB in Access that I can't
refer to a control that doesn't have the focus. If true, is there a better,
more accepted way of referring to controls on a form rather than having to
always set the focus first?

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200808/1

[Chris O'C via AccessMonster.com]

Most people use the second example. Less typing.

Chris
Microsoft MVP
Chris O'C wrote:

>If you use the text property of a control in code, you have to set focus to
it first before reading it. If you use the value property (the default), you
don't have to set focus to it first.

if (me.textboxname.value = "east") then
'do something
else
'do something else
end if

or

if (me.textboxname = "east") then
'do something
else
'do something else
end if

Chris
Microsoft MVP

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200808/1

[Gord]

Thanks Chris.

A little odd but at least if the default is accessible without having to
always setfocus, then that will be a big help.

I'll leave you alone now.

Gord
"Chris O'C via AccessMonster.com" <u29189@uwewrote in message
news:89825a58e79a9@uwe...

If you use the text property of a control in code, you have to set focus
to
it first before reading it. If you use the value property (the default),
you
don't have to set focus to it first.

if (me.textboxname.value = "east") then
'do something
else
'do something else
end if

or

if (me.textboxname = "east") then
'do something
else
'do something else
end if
Chris
Microsoft MVP
Gord wrote:

>>Thanks Chris

I had already used this line (using 'acViewReport' instead) previously but
had "assumed" that I couldn't use the 'OpenReport' command a second time
after a report was already open.

Works just fine though.

I have another question that just came to mind (since you're on-line at
the
moment) if you have a minute.

In using VB with Access, does one always have to set the focus on a
control
on a form before referring to it in code? Using regular VB6, you don't
have
to and it's quite intuitive. I get an error with VB in Access that I
can't
refer to a control that doesn't have the focus. If true, is there a
better,
more accepted way of referring to controls on a form rather than having to
always set the focus first?

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200808/1

[Linq Adams via AccessMonster.com]

Not really odd. Value and Text for a given control can be totally different.

If a textbox has, for instance, had ***gold*** entered into it and the user
moves to another control or saves the record, ***gold*** is now the control's
***Value***. If, at a later point in time, you re-enter the textbox and type
in ***silver*** but don't exit the control, that control's ***Value*** is
***gold*** but it's ***Text*** is ***silver*** which, under some
circumstances, could be useful to know.

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200808/1

[Bob Quintal]

"Linq Adams via AccessMonster.com" <u28780@uwewrote in
news:89831f54037a3@uwe:

Not really odd. Value and Text for a given control can be totally
different.

If a textbox has, for instance, had ***gold*** entered into it and
the user moves to another control or saves the record, ***gold***
is now the control's ***Value***. If, at a later point in time,
you re-enter the textbox and type in ***silver*** but don't exit
the control, that control's ***Value*** is ***gold*** but it's
***Text*** is ***silver*** which, under some circumstances, could
be useful to know.

That explanation deserves the Bronze Star for Valor. :-)
--
Bob Quintal

PA is y I've altered my email address.
** Posted from http://www.teranews.com **

[CDMAPoster]

On Aug 31, 4:55*pm, "Chris O'C via AccessMonster.com" <u29189@uwe>
wrote:

Most people use the second example. *Less typing.

Chris
Microsoft MVP

IIRC (I don't have the reference anymore so don't ask), Microsoft
advocated using .Value instead of relying on the default property of
the control based on the fact that they do not guarantee that the
current default property in a given version will be the same as the
default property in a future version. I think they even gave an
example where the default property changed from .Value to something
else from one version to another. Something like the second example
could fail, or worse assign a completely wrong value without giving
you any indication that something is wrong. Subsequently, I try to
include the .Value where appropriate. A bonus is that if IntelliSense
picks up the .Value in the list, you likely didn't spell the name of
the control incorrectly. Of course some people rely on the compiler
to discover that :-).

James A. Fortune
CD********@FortuneJames.com

[CDMAPoster]

On Aug 31, 9:26*pm, [e-mail] wrote:

IIRC (I don't have the reference anymore so don't ask), Microsoft
advocated using .Value instead of relying on the default property of
the control based on the fact that they do not guarantee that the
current default property in a given version will be the same as the
default property in a future version. *I think they even gave an
example where the default property changed from .Value to something
else from one version to another.

Microsoft seems to have no KB articles extant advocating including the
default property of a control; actually they seem to endorse quite the
opposite. However,

http://groups.google.com/group/comp....ce6b6625508013

under 'Access Tip:' I include an example from the book "DAO Object
Model: The Definitive Reference" by Helen Feddema. I still think the
original idea was from Microsoft or from a Microsoft Press book, but
may have been from another author. I don't think I would have noticed
something like that by myself :-).

James A. Fortune
CD********@FortuneJames.com