Print Preview - user controlled

[Ron McCormack]

Is there any way i can let a user preview a report or letter but keep control of the print function within this preview?

The reason for asking is that i wnat to set a flag when a report/letter is printed but have no way of doing so if the report is printed through a preview screen.

I assume that the preview is just another form, is it possible to have a preview report/form control on the toolbar?

[Steve Buckler]

RE: Print Preview - user controlled

Ron,

Yes you can put a button on a toolbar and attach
some xbasic to it.

ReportPrinted=.t.

:report.preview("Your report name")
or
:report.print("Your report name")



steve

[Ron McCormack]

RE: Print Preview - user controlled

Thanks Steve,
The problem is that I only want to set the flag if they print the form, if they only preview it I am not intersted.
As the date of printing is used as the date of invoice.
..

[tlyon]

RE: Print Preview - user controlled

If you are printing one record at a time, let them preview the form if they desire, but have a button on your form for that. Same with print. Once they press the print button, flag your variable, insert the date into the form, and then execute the print form function.

Tom Lyon

[Elliott Lester]

RE: Print Preview - user controlled

Tom:

Sometimes these are issues of operations, not programming.

The key questions to ask, just to start are:

1. Why do you need to Preview an invoice before printing?
2. How often do you Preview it rather than just print it?
3. How many (total number in a day) invoices are previewed?

Then the programmer can determine if one button, or two
should be used, or a multistate button or other method.
Multiply the number of buttons that must be clicked by the
number of items being processed and then calculate the manpower necessary to accomplish this task. If you can
automate--reduce or eliminate a preview--reduce a button click from two to one, or eliminate it altogether--invoice processing you will have value add to the program.

Good luck

[smtobias]

RE: Print Preview - user controlled

This is slightly off subject, but why wouldn't you use the date it was created instead of the print date for the invoice date? Generally the user would print it right after it was created. I always have the current date default into the invoice date field. I also have a button on the invoice to print it or one on a menu to print a batch according to some appropriate criteria. It's most logical to print it immediately (point of sale) or in a batch once all data entry is complete (mail/ecommerce sales). Having the date set to the date it was printed seems overly complicated.

Sylvia

[tlyon]

RE: Print Preview - user controlled

Don't forget the real beauty of Alpha Five, however, Elliott. If you want every instance of the word potato to be 'pototo' and I prefer 'potato', Alpha will accommodate our varied tastes and preferences. There are many ways to achieve goals, none of which are good or bad, just different.

Ron likes to preview for whatever reason. After he learns more XBasic, he may discover he has no need for preview. I know we could shift the focus from the questions asked but we also take the risk of creating confusion.

Tom Lyon

[Ron McCormack]

RE: Print Preview - user controlled

A valid observation and thanks but the record is created, then after some length of time maybe a week or so the client then prints an invoice, after details have been amended, new charges added etc..

[Ron McCormack]

RE: Print Preview - user controlled

Thanks for the comments, but the question IS more fundamental than just procedural issues.

1) I am supporting an Alpha 5 Application that is run by our clients not me - therefore procedureal control is different from client to client. They explicitly request/expect the ability to preview a layout before printing it a a check that they have completed it properly.

2) It was more a request to find out how Alpha5 produces a layout preview form, or how can i get control of the print icon on that form.

If the above is not possible, then is it possible to create a preview form of my own, i.e convert a layout into a rich text field (if that's what it is) and put that on a form with my own toolbar controls?

[Elliott Lester]

RE: Print Preview - user controlled

Tom:

I understand what you are saying, and appreciate it. It is true that one function of the board is to try to help solve the specific issue at hand. It is an important function for the individual that has the specific problem, I know in that we have been there. There are many competent and skillful A5 software engineers, like yourself that respond to issues in direct, concise and helpful ways with specific code snippets offered in their responses. I always commend you and them for it, and realize that you and their time is valuable.

I like many others, typically do not review the board each day to solve specific problems�many of which because of experience or skill level, or different tasks that our software is required to effectuate do not encounter. Instead I review the board and look at each and every question and answer posted, not just for the issue, but rather to glean experience from the questioners and answerers for how they formulate goals, why they use one method over another and most importantly which method best achieves cost effective efficiency. I for one, have found and learned a great deal from this review not only by the way,from experienced programmers, but by novice as well.

I have learned in my many years of helping to produce high volume customer service operations software that while there are many methods to achieve goals; there is are indeed right and wrong ways. And good and bad ways. And ways that enables a company to grow by doing more with less�especially less operations staff.

These ways must be taught or gleaned from failure or by the gradual process of actually creating software that does not just work, but accomplishes what software should accomplish.

I have also learned that often times operations staff request certain functions because they do not have well
designed programs and screen layouts that let them accomplish their tasks in a competent and quick manner with a minimal degree of failure. Failure both from the prospective of the software, and of the human operator. More times than not, I think you will agree human mistakes can readily been prevented by capable software. I have seen
software engineers present what they consider fully completed programs only to be laughed at by operations staff.

In the instant case, it is obvious from the Ron�s last response that his task operators for whatever reason require a preview of the invoice/form to assure that it was done competently. I have found that often times operations staff tell the programmer one thing�I need this�and the programmer just hears that the operations staff needs that. I have learned and continue to learn from this board to successfully translate operational needs to programming excellence. I say translate because there are many reasons WHY operations staff need certain abilities and it is up to the programmer to not just accept at face value the need, but to determine the whys and wherefores. In our system, while we can preview an invoice it is normally only done to look at it on the screen if a customer calls with a question. The software itself prevents almost all mistakes in the invoice creation, with very little actual human decision making involved in the process. And on its final creation screen, all information necessary to finalize and Quality Control the invoice are present without the need to send it to preview. And like Ron, we identify the date that the invoice is actually printed although we date the invoice at the partial creation date which is the date
we are notified of task completion and before receipt of our vendor�s invoice. I attach one of our similar invoice screens as a simple example.

My attempt to answer Ron tried to provide insight for him--without knowing his experience or skills and others as to some of the questions that should be asked even before time is spent in programming what the programmer believes is the solution to the problem. Determining why the operator truly needs a function is sometimes the most difficult job that a programmer will face. Excuse me for being so presumptuous as to present my experience in these matters.

If you have followed my responses and issues on the board, you will know that I have a certain philosophy in both programming, hardware and in operational systems. I rarely give specific code advice but rather theory and analysis advice. There are others far more skilled able to provide
code. But there is a great deal more to software than mere code. And please don�t take my responses personally, they are not meant to criticize in any manner whatsoever. The answer to a specific question might enable my team to rethink how we do something, learning not only about the solution but the process. Hopefully others out there that read each question with like hopes.

Good luck

[Elliott Lester]

RE: Print Preview - user controlled

Tom:

I understand what you are saying, and appreciate it. It is true that one function of the board is to try to help solve the specific issue at hand. It is an important function for the individual that has the specific problem, I know in that we have been there. There are many competent and skillful A5 software engineers, like yourself that respond to issues in direct, concise and helpful ways with specific code snippets offered in their responses. I always commend you and them for it, and realize that you and their time is valuable.

I like many others, typically do not review the board each day to solve specific problems�many of which because of experience or skill level, or different tasks that our software is required to effectuate do not encounter. Instead I review the board and look at each and every question and answer posted, not just for the issue, but rather to glean experience from the questioners and answerers for how they formulate goals, why they use one method over another and most importantly which method best achieves cost effective efficiency. I for one, have found and learned a great deal from this review not only by the way,from experienced programmers, but by novice as well.

I have learned in my many years of helping to produce high volume customer service operations software that while there are many methods to achieve goals; there is are indeed right and wrong ways. And good and bad ways. And ways that enables a company to grow by doing more with less�especially less operations staff.

These ways must be taught or gleaned from failure or by the gradual process of actually creating software that does not just work, but accomplishes what software should accomplish.

I have also learned that often times operations staff request certain functions because they do not have well
designed programs and screen layouts that let them accomplish their tasks in a competent and quick manner with a minimal degree of failure. Failure both from the prospective of the software, and of the human operator. More times than not, I think you will agree human mistakes can readily been prevented by capable software. I have seen
software engineers present what they consider fully completed programs only to be laughed at by operations staff.

In the instant case, it is obvious from the Ron�s last response that his task operators for whatever reason require a preview of the invoice/form to assure that it was done competently. I have found that often times operations staff tell the programmer one thing�I need this�and the programmer just hears that the operations staff needs that. I have learned and continue to learn from this board to successfully translate operational needs to programming excellence. I say translate because there are many reasons WHY operations staff need certain abilities and it is up to the programmer to not just accept at face value the need, but to determine the whys and wherefores. In our system, while we can preview an invoice it is normally only done to look at it on the screen if a customer calls with a question. The software itself prevents almost all mistakes in the invoice creation, with very little actual human decision making involved in the process. And on its final creation screen, all information necessary to finalize and Quality Control the invoice are present without the need to send it to preview. And like Ron, we identify the date that the invoice is actually printed although we date the invoice at the partial creation date which is the date
we are notified of task completion and before receipt of our vendor�s invoice. I attach one of our similar invoice screens as a simple example.

My attempt to answer Ron tried to provide insight for him--without knowing his experience or skills and others as to some of the questions that should be asked even before time is spent in programming what the programmer believes is the solution to the problem. Determining why the operator truly needs a function is sometimes the most difficult job that a programmer will face. Excuse me for being so presumptuous as to present my experience in these matters.

If you have followed my responses and issues on the board, you will know that I have a certain philosophy in both programming, hardware and in operational systems. I rarely give specific code advice but rather theory and analysis advice. There are others far more skilled able to provide
code. But there is a great deal more to software than mere code. And please don�t take my responses personally, they are not meant to criticize in any manner whatsoever. The answer to a specific question might enable my team to rethink how we do something, learning not only about the solution but the process. Hopefully others out there that read each question with like hopes. I for one thank you
for your time.

Good luck

[tlyon]

RE: Print Preview - user controlled

You said that twice twice :)

Sorry, couldn't resist

Good discussion!

Tom Lyon