> I'm in the process of migrating my VB 6.0 app from the older OCX
technology
> to the RDC.  In most situations, it does not matter if the user only views
> reports and does not print them out, but I need to enable/disable a
posting
> command button based upon whether or not the user has printed a hard-copy
of
> a particular report.  In the OCX, this was not a problem, as I could force
> the output to the printer, but I can't seem to locate anything in the RDC
> that allows me to do this.  I've read the (very thin) developer manual
that
> comes with the 8.5 developer edition, and scanned/searched through the
> on-line help, but can't find much of anything there.

> Is there some kind of event, perhaps, where I could set a local form-level
> property when the user selects to print the report, so that the calling
form
> could then check to enable the posting command button?

> --
> Bill Hileman, MCP, CPP, BCIP
> Programmer/Analyst, DASI

> PROGRAM n. A magic spell cast over a computer allowing it to turn one's
> input into error messages. tr.v. To engage in a pastime similar to banging
> one's head against a wall, but with fewer opportunities for reward.

> BTW, enabling posting to GL accounts (from your description - I am
guessing
> here) based on whether a hard copy is printed, is pretty unusual, and
> unreliable to say the least - what happens if there is a printer jam?

> > BTW, enabling posting to GL accounts (from your description - I am
> guessing
> > here) based on whether a hard copy is printed, is pretty unusual, and
> > unreliable to say the least - what happens if there is a printer jam?

> You're right on the nose, it is for posting to the G/L Chart of Accounts.
> In our DOS based app (still in use) when a user selects to post, it prints
> the report, and then asks "Another hard-copy?" for situations like you
> stated above - out of paper, paper jam, etc.  Of course, most users have
> their printers spooled, and won't wait to see if the report came out okay
or
> not, and just answer No to that question anyway, and then when the report
> has jammed or otherwise failed, it's too late.  We have journal reports,
of
> course, but it's not the exact same format as a posting report, which
> users -should- be filing for paper backup purposes.

> I'm not sure what the best solution would be here.  What we want to
> accomplish is to not enable posting until we are (fairly) certain that the
> user has a hard-copy of the transactions in-hand, so ideally, it would be
> best to at least wait until the entire report is at least spooled (another
> event in the viewer - report complete?) before enabling the post button.

> I know no system is fool-proof, but since all other reports are view and
> only print if they want to, and they can always call those other reports
up
> again should they want a hard copy, I don't want to rely on them viewing
the
> posting report, but forgetting to print a hard copy.  Even if the print
job
> fails, at least I can know that they did -try- to print the report, and
then
> enable the post button.  If there is some way to know that at least
Crystal
> itself has sent the entire report to the spooler, it would be better, as
> they could at least then pause/resume the spooler to correct most kinds of
> problems that would happen with the printer at that point.

> --
> Bill Hileman, MCP, CPP, BCIP
> Programmer/Analyst, DASI

> Yahoo! Club (now Group)  for Certaholics
> http://groups.yahoo.com/group/certaholics

> Computer Language Comparison
> http://www.boneville.net/programming/default.htm