Creating an ESTIMATE or INVOICE where to start?

[damasterjo]

How would I create an estimate that could look similar to the one attached?

[DataMiser]

You could use a report or you could use the printer object and print everything through code.
I would use a report, actually I have did it a few times from scratch using a report and directly through code using pre-printed forms

[damasterjo]

Data come from the program not a data base. From what I read I can't use report. Print straight from code?
Can I just print to form then save it as a PDF?

[LaVolpe]

Print straight from code? Can I just print to form then save it as a PDF?

Print to form, i.e., saving as an image, then that to pdf? Might as well just save it as a PNG. As an image, you lose text-capabilities of pdf unless OCR is also used.

Data come from the program not a data base. From what I read I can't use report.

Don't quite understand? Data must be cached somewhere correct? If not, how could you possibly go back and modify estimates? How would you be able to compile statistics, search for previous estimates, and other data-related tasks?

Another option you might have is to build a RTF document.

Whichever option you use, you should be able to convert to pdf assuming you have the appropriate/legal software installed

[damasterjo]

Print to form, i.e., saving as an image, then that to pdf? Might as well just save it as a PNG. As an image, you lose text-capabilities of pdf unless OCR is also used.

I do not need any text-capabilities outside the generated invoice. If anything needs to be adjusted, i will just run program again.

So I can turn form into PNG with VB?

I need an outside program to take my FORM and or PNG to make a PDF?

[DataMiser]

To print directly through code you use the printer object and the .print method. There is also a currentx and currenty that allows you to position the print, methods to print pictures and scale them if needed, change fonts and such. See the printer object in your online help for details and samples.

Something like what you are mentioning should probably be using a database but no matter if it is or not you could use a report to display and print the estimate.

There are a few different options for creating PDF as well, a search should turn up a few things.

Personally I would create a report using Active Reports and then export that to PDF using the PDF export dll provided by Active Reports.

[Elroy]

If it were me, I'd totally use Microsoft Word Automation through VB6. I could have this up and running in 2 hours max using Word Automation.

I've attached an example of a recent report I did using a combination of Word and Excel Automation, all done from within VB6. Every single number on this form was filled in from a database that was also accessed via VB6.

As a tip, I often use the "Record Macro" functions in the VBA of Word and Excel, and that recorded code will almost directly paste into your VB6 application. You may need to patch up the "Document" object a bit, but the rest of it'll go straight in. For security reasons, I tend to not have any macros in my actual Word and Excel documents.

Also, I make extensive use of the "Template" (.DOT, .DOTX, .XLT, & .XLTX) files of Word and Excel. That way, the user is much less likely to mess up your report templates.

Sample.pdf

Good luck.

p.s. In the past, I've extensively messed around with Crystal Reports, and also tried to build a VB6 interface between VB6 and the Microsoft Access Report engine. However, after learning the Word and Excel object structure, I've found that Word and Excel automation is TOTALLY the way to go regarding report generation via VB6.

[DataMiser]

I do not use the Word nor Excel for such things as that requires the user have MS Office installed on the system and of course is slower and uses more resources than just doing it in VB.
Also with a good report tool the job is both faster and easier than it would be to use Excel or Word automation while not requiring any other software installed on the users PC.

I never liked Crystal and automating the Access report tool is not very good either and of course requires Access on the users system.

Using Active Reports I can build a self contained program that requires no other software to be installed and generating the report is easier than any of those other methods while giving greater control.

Of course to each his own and which method is best for a given project depends on the knowledge of the programmer and who the intended users will be. I just find it very UN-appealing to require my customers buy MS Office to run my software and as such do not use it unless it is asked for by the customer.

[Elroy]

Hey DataMiser,

In my defense, I don't find MS Office automation slow at all. Also, just to say a bit more about how I do it, I don't actually make the reference in VB6. Rather, I use late binding for all the Office objects. That way, it doesn't matter which version of Office they have. One of my primary packages works just fine with anything from Office 2003 (XP) to Office 2013. I'm far from a Microsoft fanboy, and actually have Libre Office installed on my computers, but it's been quite sometime since I've run into a client machine that didn't have a fairly late version of Office on it.

Regarding the MS Access reporting tool, the client would only need the Access Runtime engine installed (which is free) to produce reports. As a developer of the reports, you'd certainly need a full-blown version of Access, but it's certainly cheaper than the $2,000 being asked for Active Reports. IDK, just through the years, I've had such awful luck with third party ActiveX controls that I now stay away from all but the standard ones that come with VB6. Your excitement over Active Reports has me possibly wanting to take a look at it though.

Heck, even just using the internal VB6 printing routines is certainly an option. I used to have an extensive library of routines for printing (that did such things as justify, figure out proportionally spaced word lengths, format wrapped paragraphs, etc.). However, these days, that library is routines for automating Word or Excel. I've developed a standard for myself whereby I create a .DOT (or .DOTX) template with things like [field1], [certaininfo3], etc. (with the brackets) in a Word document. Then, in VB6, I have a search-and-replace routine for once, all in document, in this shape, in the header, in the footer, etc. to replace these fields with my data. I suppose everyone finds the way that works best for them, but this works quite well for me. And I just love how the later versions of Word can do rotated text, fancy Art text, and so many other things that just become part of my report. Here, I'll attach a PDF of the template of that earlier attached report (before its filled in with data and actual images). I actually use automation to edit the embedded Excel graphs on this particular template. In my opinion, Excel is a second-to-none graphing tool. And just as an FYI, those "place holder" pictures get replaced by VB6, with the client never actually seeing this template version.

Ahhh, and also, I put the templates in a .RES file, unpacking them from the .EXE in a temp folder and use them only when I need them. This keeps a wily client from messing up my templates and then calling me to tell me they no longer work.

Regards,
Elroy
Sample2.pdf

p.s. If asked specific questions about automation, I'd be delighted to share code snippets and ideas on how to get certain things done.

pps. Ahhh, and another nice thing about doing it this way is that the client can edit and tweak the reports to their liking before finalizing them, as they have a .DOC or .DOCX file that they can do with what they like. In VB6, one of my standard Office routines is to (Print, Save, Save & Print) the report. They often Save and then tweak before printing final version.

ppps. You know. It actually does dawn on me that there are certain tricks to make sure that automation runs quickly. The most important one is to make sure the Word or Excel application is invisible when using it for automation. Regarding Excel, you do want to make sure that "ScreenUpdating" is turned off when you're patching in new numbers from VB6. And, if you're doing a lot, it's good to turn xls.Calculation = xlCalculationManual and then turn it back to xls.Calculation = xlCalculationAutomatic when you're done. You're right, if you don't do those things, it can be quite slow. But I always do those.

[DataMiser]

I may be spoiled with Active Reports

It is so much quicker and easier than using any other method I have tried. It integrates with the IDE and allows you to write code for your report just like you would write for a VB form. It is so simple and powerful, includes export features that allow the creation of Excel files [without needing Excel installed] PDF and other formats. You can even include a report designer directly in your program. No need to launch any other programs nor any need to have any other programs installed on the target PC, just a dll or two as part of your installer.

[Elroy]

It does sound rather cool, DataMiser. I may have to download the demo and take a look at it. And I'll admit that there are times when I'd just like to knock out a quick report wholly within VB without the need for invoking Word or Excel or any other application. I've gotten rather insistent that everything I do run in a SxS mode with a .manifest file. (Which means I no longer require any "installer" as part of my program distributions.) Can you tell me if they have all the .manifest stuff worked out for the DLL's and/or OCX controls?