acnormal problem

[mark r]

Please do not post a response if you do not have any useful guidance. It just
buries the question.


If I use Docmd.openreport Acpreview and use the where
argument I get a great preview of a single record I am
searching for.

I inserted an if-then after that AcPreview


msgbox "do you want a hard copy"
IF vbyes then
I used the same VB code and only changed to AcNormal
End if


and instead of getting one record to the printer I got 72
(all records)!

I used the exact same where clause by copy and paste. I
only changed the AcPreview to AcNormal.

1. what is happening?
2. the msgbox pops up simultaneously with the Preview
report and there for freezes out the sherlock holmes
magnifying glass until the user answers "NO" to the
message box...........so the user can't see the tiny
preview to decide if he should print to hard copy. There
is no delay between the preview and the msg box. So the
user has to click no, enlarge, think it over ...then run
it again and answer"YES" the next time. any way to delay
the msgbox?

 

[Dan Artuso]

Hi,
What is hapenning is that your code is simply executing from beginning to end.
When it hits the MsgBox line it stops because it needs a response. That's just
the way things work.

Usually you would simply open the report in preview mode and the user can then just hit the
Print icon if they want a hard copy.

 

[Mark R]

Once again, your the ace.....thanks

Why are you bothering with all this? The Preview tool bar
has a button to print the report being previewed so the

user can decide to print it wothout your prompting or
other stuff.

Marshall, I asked myself the same question and actually
wanted to ask someone to write to me on this subject, but
I thought no one would have the empathy. I know YOU do.
Here goes:

Ultimately, if I get to the point where I can compile my
application to be an executable
loadable "independent" "stand alone" module, I am
assuming the user won't know he is in ACCESS. He will
just see the application as it is.

#1 I didn't know if the little printer icon would still
be available in that "menu bar" for him to use to print
off the previewed report.

#2 If the little printer icon would be available, would I
have to "make that choice" to make it available?

#3 If I made it available or if it was available anyway,
should I assume some sort of "basic user literacy" and
expect the user to "figure out" that the way to "print a
hard copy" of a previewed report, is to utilize that icon.
I guess I should assume that, but I thought if I could
just as easily provide a MSGBOX "dialog" and ask/prompt
the user "Do you want a hard copy?" then I would not
have to worry about "user illiteracy". I just take care
of it.

So what do you think to #1, #2, #3 ? I value your opinion
immensely.

dialog window mode

OK, I will go to "HELP" and search on dialog window mode
later today, and see what that is....I hope there is info
on it.......unless you just mean control the events using
MSGBOX

MSGBOX
IF ( )
then openreport.ACpreview

MSGBOX
IF ( )
then open message

MSGBOX
IF ( )
then openreport ACnormal


If there is adequate info on HELP, 'nuf said, if not,
could you just give me a little more detail insight on
what is meant by "dialog window mode" to get me started?


-new but improving self-made "lay men" ACCESS developer

Thanks in advance

 

[mark r]

Ultimately, if I get to the point where I can compile my
application to be an executable
loadable "independent" "stand alone" module I didn't know
if the little printer icon would still be available in
that "menu bar" for him to use to print
off the previewed report.

 

[Douglas J. Steele]

Access databases cannot be compiled into executables.

The nearest you'll be able to do is to distribute the runtime version of
Access with your application, so that users who don't already have Access
installed will be able to install the runtime version of Access and use your
application. That means that you control what menu bars are visible.

See the Developer Edition FAQ Tony Toews has at
http://www.granite.ab.ca/access/developereditionfaq.htm for more information
about what you need to be able to distribute the runtime version of Access.

 

[Marshall Barton]

Once again, your the ace.....thanks
user can decide to print it wothout your prompting or
other stuff.

Marshall, I asked myself the same question and actually
wanted to ask someone to write to me on this subject, but
I thought no one would have the empathy. I know YOU do.
Here goes:

Ultimately, if I get to the point where I can compile my
application to be an executable
loadable "independent" "stand alone" module, I am
assuming the user won't know he is in ACCESS. He will
just see the application as it is.

An "independent, stand alone" Access application is still
just an Access mdb (or mde) file. If you have the
Developer's Version, then you have a license to distribute
the Access Runtime so users that don't have Office/Access
can run your application. The majordifference between full
Access and the runtime is that the users can not use the
runtime version to create new databases. From your point of
view, they are essentially the same thing (except for your
distribution procedures). I don't use the runtime version
so I can't be more specific than that.

What all that amounts to is that you can use either the
built-in or your own custom tool/menu bars.

#1 I didn't know if the little printer icon would still
be available in that "menu bar" for him to use to print
off the previewed report.
Yes


#2 If the little printer icon would be available, would I
have to "make that choice" to make it available?

It defaults to the standard tool/menu bars. Try it and see.

#3 If I made it available or if it was available anyway,
should I assume some sort of "basic user literacy" and
expect the user to "figure out" that the way to "print a
hard copy" of a previewed report, is to utilize that icon.
I guess I should assume that, but I thought if I could
just as easily provide a MSGBOX "dialog" and ask/prompt
the user "Do you want a hard copy?" then I would not
have to worry about "user illiteracy". I just take care
of it.

Since your users are using Windows, I think it's safe to
assume a basic level of "literacy". If not, a user training
session should take care of it.

So what do you think to #1, #2, #3 ? I value your opinion
immensely.

Do it the standard way, users will be more confused by your
"odd and unusual" way.

OK, I will go to "HELP" and search on dialog window mode
later today, and see what that is....I hope there is info
on it.......unless you just mean control the events using

WindowMode is an argument of the OpenForm and OpenReport
methods. Using a value of acDialog forces the user to close
the form/report before other activities can proceed. I
don't recommend this in common situations.

 

[mark r]

right o! your the man. thanks

-----Original Message-----


An "independent, stand alone" Access application is still
just an Access mdb (or mde) file. If you have the
Developer's Version, then you have a license to distribute
the Access Runtime so users that don't have Office/Access
can run your application. The majordifference between full
Access and the runtime is that the users can not use the
runtime version to create new databases. From your point of
view, they are essentially the same thing (except for your
distribution procedures). I don't use the runtime version
so I can't be more specific than that.

What all that amounts to is that you can use either the
built-in or your own custom tool/menu bars.



It defaults to the standard tool/menu bars. Try it and see.

Since your users are using Windows, I think it's safe to
assume a basic level of "literacy". If not, a user training
session should take care of it.



Do it the standard way, users will be more confused by your
"odd and unusual" way.

using

WindowMode is an argument of the OpenForm and OpenReport
methods. Using a value of acDialog forces the user to close
the form/report before other activities can proceed. I
don't recommend this in common situations.

 

[mark r]

Thanks Doug,

I don't know how I got misinformed on that. Originally I
asked microsoft if I could sell the application I
developed and I got a "Yes" answer as long as I purchase
the runtime version , which I did.

I thought I skimmed what I thought were the "compiling"
instructions, where ACCESS modules are "compiled along "
with your application for other non-ACCESS users to
utilize. I assumed that would be a loadable module. Like
I would give a user a CD with the application and they
would put it in their drive and follow the install
instructions.

Your answer makes it sound more like they load up ACCESS
from my CD onto their windows desktop and then open ACCESS
and select my application from the file menu. It looks
like ACCESS and it says ACCESS , they just cannot create
THEIR own tables or applications, nor modify mine if I
make sure that the menu bars for design view are
unavailable.


I have been developing and only skimmed the

 

[Guest]

I checked out that web site.
.. See Convert Access to Visual Basic, Delphi, Java, ASP
or ASP.NET

so my lay men thinking is that if I create an .EXE out of
MDB/MDE via one of these products above, then the code is
more "encrypted", takes more of a professional to pirate
it, atleast a hack like me would not know that it could
all be done in ACCESS since they would have no clue that
it was in ACCESS.

1. What do you think are the advantages and DIS advantages
to getting one of these otehr products and converting my
final project to an .EXE ?

2. Is the conversion plug in and menu driven, or is it
involved, more involved than the learning it took for me
to understand and code ACCESS itself? can things go
miserably wrong and require an IT professional to get the
conversion and loadable .EXE to work?


thanks

 

[mark r]

I checked out the wbesite:
.. See Convert Access to Visual Basic, Delphi, Java, ASP
or ASP.NET

In your mind, What are the advantegs and disadvatages to
creting a loadable .EXE ?

Is it plug and got follow the menu to convert ACCESS using
these products? or will it very involved, require more
learning than even what it took to learn ACCESS and VB
code builder? Will it require an IT professinal to get
the conversion and .EXE to actually work?

thanx

 

[Douglas J. Steele]

Several things here.

First, ASP and ASP.Net mean that you must have IIS running: in other words,
it's a web application.

The form controls in Access are intended to be used with databases: that's
definitely not the case with VB, nor (I don't think) with Delphi. I don't
believe Java even has forms in the same context as the other languages.

Finally, the conversion tools do an incomplete job at best. In many cases,
it's easier just to start over, rather than hoping that your code from one
technology can be mechanically translated to another technology. You'll
definitely need to learn the new technology, though.

 

[Douglas J. Steele]

Your second interpretation ("they load up ACCESS from my CD onto their
windows desktop and then open ACCESS and select my application from the file
menu. It looks like ACCESS and it says ACCESS, they just cannot create THEIR
own tables or applications, nor modify mine.") is essentially correct,
although you can create a shortcut so that they just click on the shortcut
and it opens your application in the Access runtime, rather than having to
go through the 2-step you describe. As well, they won't be able to modify
any tables, whether or not you fuss with the menu bars. The run-time doesn't
allow any design functionality.