PlanetSquires Forums

Support Forums => Other Software and Code => Topic started by: John Montenigro on February 07, 2014, 03:20:08 PM

Title: Document generation - design approach needed
Post by: John Montenigro on February 07, 2014, 03:20:08 PM
Here's a task that I've never even come close to having to do:

Using PBWin and FireFly (and if necessary, SQLTools Pro), I need to generate a business "form letter" that will:
1. go to different companies (therefore different names and addresses, etc.).
2. display the sender's letterhead and logo.
3. display different product information, obtained from a lookup table.

The text of the letter will require some formatting (tabbed indents, various fonts and font sizes).

I intend to build the program in FireFly, and have two forms:
- one for the user to enter the values for the required fields
- one for display of the "Print Preview" of the letter before: saving, printing, and/or emailing. 

Given these requirements, I am asking for help to determine the best strategy.

I know how to do the data lookups, and I think I know how to print/email the finished document, but I'm not sure about which controls to use in FireFly that would make all of this manageable...

- What's the best way to do a "Print Preview" in FireFly?
- Should the Preview form contain Rich Text control? How would I insert the logo file into RTF control?
- Instead, should I use a Graphic Window?
- Are there other tools or APIs or COM objects that I should be using?
- What's the best way to save the completed document? Any RTF formats? (I could print to CutePDF...)

I'm open to any and all ideas, thoughts, suggestions.

Thanks!
-John

Title: Re: Document generation - design approach needed
Post by: David Kenny on February 07, 2014, 04:29:00 PM
John,

Why wouldn't that be done in something that is built for it, like MS Word?  It has mail merge, print preview, can handle the logo's, has its own document format... etc. Just doesn't seem to need custom program with the criteria you mentioned.
Do you have more criteria?

David
Title: Re: Document generation - design approach needed
Post by: Israel Vega Alvarez on February 07, 2014, 05:58:23 PM
For print preview I am using DDOC and is working fine...and you can insert image into document.

http://www.greatwebdivide.com/software.htm (http://www.greatwebdivide.com/software.htm)

Also you can print to a html file and display with any browser or use code of Jose Roca with PDF using HARU
http://www.jose.it-berater.org/smfforum/index.php?topic=4710.msg18372#msg18372 (http://www.jose.it-berater.org/smfforum/index.php?topic=4710.msg18372#msg18372)

Israel
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 07, 2014, 07:04:01 PM
Gary Beene has a print preview on the PB site that is very good.
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 07, 2014, 07:16:40 PM
Just noticed that you posted in the gbPrintPreview thread.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 07, 2014, 10:18:31 PM
Paul,
Yes, I'm looking at all options...
I didn't want to go too far on the PB website, but I did want to ask you about the DLL version of Gary's Print Preview: I don't know how to create the DLL from the code in his .zip file; all I saw was the .INC and the .BAS for a demo... AND, how would I incorporate it into my FF program? (I hate to admit it, but I have never created a DLL. My programs are small utilities, and I have no experience with DLLs...)

David,
I'm open to learning how to do that in MS Word. Years ago, I wrote some extensive macros for similar things, but I don't know how to achieve that through PB. Could you point me to some code that I could study? I'm happy to learn new techniques.
But for this project, I cannot rely on MS Word; I have to provide a self-contained program.

Israel,
Thanks for the links - I'll study and experiment over the weekend.

Thanks for the feedback!
-John

Title: Re: Document generation - design approach needed
Post by: James Klutho on February 07, 2014, 11:46:56 PM
Attached is an old version of gbPrintPreview (3.44) that I used as a starting point to the printing engine of MLG.  Gary has the code set up to make the print preview into a DLL.  I will warn you up front that DDT has a bad leak in making the toolbar imagelist out of ICONs and a few other leaks also, which if the DLL is called repeatedly tends to add up.  Should be straight forward making the DLL.  I am sure Gary wouldn't mind me posting his files here because it is released to the public domain. 
Title: Re: Document generation - design approach needed
Post by: José Roca on February 08, 2014, 12:01:01 AM
You know what I do i my CSED editor? I build the pages using HTML and then I display them in the print preview of the Browser Control.

No problems about working in some printers and not in others, it is localized, etc.
Title: Re: Document generation - design approach needed
Post by: David Kenny on February 08, 2014, 03:55:39 AM
Yea, I meant doing the whole thing in Word (or some other word processor for that matter).  I didn't mean controlling Word with PB. :P
So, an important criterion is that it must be a "self-contained program".
Title: Re: Document generation - design approach needed
Post by: Knuth Konrad on February 08, 2014, 12:32:40 PM
A reporting component I use, which has a free "Community Edition" so that you can try it out, is Virtual Print Engine (http://www.idealsoftware.com/en/pdf-library/report-engine.html).
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 08, 2014, 12:37:41 PM
I used to use VPE way back in my VisualBasic days! Loved it.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 11, 2014, 01:01:36 AM
Thanks for all the suggestions! They are now on my ToDo List, and I will tackle them one at a time in due course...

Meanwhile over the weekend, I experimented at length, but seem to have missed something...

I can XPRINT ATTACH to a printer, and all my text comes out as it should, but I just cannot seem to get a PREVIEW to work.

In frmMain, there's a Preview button, in which I set up the XPRINT statements, and there's a frmPreview on which I've tried a variety of controls, trying to find one that will display the preview.

I think I'm doing something wrong with the ATTACH statement. So here's what I'm doing in frmMain:

      XPrint Attach Default       
      'XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_RICHEDIT1       
      XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_Picture1       
      'XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_GraphicControl1

      XPRINT "text"


Anyone see what I'm missing?

Thanks,
-John



Title: Re: Document generation - design approach needed
Post by: Nathan Durland on February 11, 2014, 06:22:20 PM
Quote from: Knuth Konrad on February 08, 2014, 12:32:40 PM
A reporting component I use, which has a free "Community Edition" so that you can try it out, is Virtual Print Engine (http://www.idealsoftware.com/en/pdf-library/report-engine.html).

We use VPE (pro edition) on a daily basis.  We got it mostly for it's ability to natively save PDF files without CutePDF or the equivalent, but we also do graphing, emailing and all the fun stuff.
Title: Re: Document generation - design approach needed
Post by: Petrus Vorster on February 12, 2014, 11:54:20 AM
VPE looks great. ANy examples anyone on how its used from Firefly ?
Title: Re: Document generation - design approach needed
Post by: Haakon Birkeland on February 12, 2014, 12:55:33 PM
Seems interesting, but after checking it out I feel good about staying with quickPDF for my programming meets designer cases. I use it in stand-alone applications for merchandise labels and on-line for datasheet generation with CMYK pictures and the lot.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 12, 2014, 05:06:31 PM
I'm checking back to see if I've strayed off course...

In FF, I've got two forms:
- frmMAIN contains textboxes, ListView, etc. to accept user inputs/selections of variable data,
   and a command button called "PREVIEW" that:
       - invokes my PrintPage() function, then
       - shows the second form:
- frmPREVIEW contains the control/container to receive the XPRINT PREVIEW results,
   and a command button called "SAVE AND PRINT" that writes data values to a file and
   sends XPRINT statements to an actual printer.

- the PrintPage() function accepts a parameter (ToPreview, ToPrinter, ToPDF) 
   (At this time I'm using the PDFCreator printer driver to generate a PDF)
   If the param is ToPreview:
      XPrint Attach Default       
      XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_GraphicControl1
      'XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_RICHEDIT1       
      'XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_Picture1       
      'I'm not sure which type of control to use, so I'm experimenting...)

   If the param is anything else:
      XPrint Attach SelectedPrinter, JobName       

   Then all the XPRINT statements that generate the text with the user's data embedded...
   and ending with the proper type of XPRINT {PREVIEW} CLOSE

- the SaveAndPrint button just writes the user data to a file, then invokes
   the PrintPage() function with the ToPrinter parameter...
   
When I run the program, I am able to successfully:
- enter the data
- invoke the PREVIEW form           '  <--- but it's BLANK, and THAT's the problem
- click the SaveAndPrint button
The result: the printed page on the proper printer; everything looks perfect!

BUT, the control on the PREVIEW form that was supposed to receive the XPRINT statements,
is BLANK. As far as I can tell, nothing displays.
(It could be that everything is there, but too tiny to see, but I just can't tell, and besides,
it shows up on the printer at the proper size; why would there be such a dramatic difference?)

So, the question is: What am I doing wrong with the XPRINT ATTACH PREVIEW statements in the PrintPage() function, or with the controls on the PREVIEW form? Why am I not seeing the XPRINT PREVIEW results????

Thinking that maybe the PREVIEW form doesn't exist until AFTER the PREVIEW button on frmMAIN has been clicked (Paul, is that correct?), I even tried to open and hide that form first, but that didn't help either...

Can anyone identify what I'm doing wrong?

Thanks for your help,
-John
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 12, 2014, 05:44:03 PM
The preview must be sent to a PB Graphic Control or a PB Graphic Window. FF does not have those as controls that you can add to a Form. FF's Graphic Control is not the same as PB's Graphic Control. I am pretty sure then is code on this site that shows using those PB's controls in FF. Maybe even the \Examples\GraphicDDT could help.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 12, 2014, 07:14:37 PM
I'm so sorry to be so dense, I feel I'm nibbling this to death...

I added a CustomControl to the second form (frmPREVIEW), cloned the code from the GraphicDDT example (yes, I know I'll eventually remove some of it, but I copied it "as is" just to learn how it works...), and in frmMain, under the PrintPage() function, for the ToPreview parameter, I replaced the experimental statements from the earlier post to these:
      XPrint Attach Default       
      XPrint Preview HWND_FRMPREVIEW, HWND_FRMPREVIEW_CustomControl1 


Now when I click the PREVIEW button on the first form (date entry), the second form comes up, and the blue square shows nicely, but I still don't see any of my XPRINT text...

I'm still confused about this. How do the XPRINT PREVIEW statements interface to the CustomControl???

Is it unworkable to do the data entry on one form, the XPRINTs in a function, and the preview on a second form? Is that the problem? If so, what's a better way to organize this?

-John
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 12, 2014, 08:37:51 PM
Hi John, I don't use XPRINT PREVIEW. Let me convert Gary's gbPrintPreview to a DLL for you. I will post that code in a few minutes.
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 12, 2014, 08:39:57 PM
gbPrintPreview as a DLL with a sample EXE to call the DLL.
http://www.planetsquires.com/files/gbPrintPreview.rar
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 12, 2014, 09:42:50 PM
Holy smokes, Bullwinkle!

Took me 3 minutes to create a tiny include for the primary TYPE and the DLL's DECLARE, and it compiled first shot!

Now to head home, have a bite to eat, then get back in and connect the dots!

Thanks, Paul for the boost, and Gary for the useful code!

Chat later,
-John

P.S. Paul, I hadn't realized that you didn't use the XPRINT PREVIEW. Besides Gary's code, is there a technical reason?

Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 12, 2014, 10:03:07 PM
Hey John, no big reason other than I haven't had any need to implement a print preview in my PowerBASIC apps. I have used XPRINT to print to printers.
Title: Re: Document generation - design approach needed
Post by: James Klutho on February 13, 2014, 12:11:12 AM
Just a note.  The gbPrintPreview has some bad memory leaks.  The main one being the use of ICONs in the imagelist of the toolbar-change the images to bitmaps.  It is bug in DDT.  There are others also which are mostly DDT bugs (in my opinion).  They are talked about in the gbPrintPreview thread on the PB forum.  If the DLL is called a lot it could add up.
Title: Re: Document generation - design approach needed
Post by: Knuth Konrad on February 13, 2014, 08:06:36 AM
Quote from: Nathan Durland on February 11, 2014, 06:22:20 PM
Quote from: Knuth Konrad on February 08, 2014, 12:32:40 PM
A reporting component I use, which has a free "Community Edition" so that you can try it out, is Virtual Print Engine (http://www.idealsoftware.com/en/pdf-library/report-engine.html).

We use VPE (pro edition) on a daily basis.  We got it mostly for it's ability to natively save PDF files without CutePDF or the equivalent, but we also do graphing, emailing and all the fun stuff.

Same here (daily usage), that's why I mentioned it.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 14, 2014, 12:15:41 AM
I get such a kick out of the amount of homework you guys dish out!

So, having read above about possible problems due to DDT leaks in the gbPrintPreview INC, I'm now reading the manuals for the VPE.

I searched for code examples using Virtual Print Engine with FF and/or PB, and did find a posting of an .INC  from Apr 13th, 2010, by Antonello Ventullo, and some sample code. So I'll be experimenting with that tomorrow. (Snow shoveling has been a priority today - 14 inches of the stuff and I'm running out of places to put it)

Thanks, all, for the guidance!
-John

P.S. There are some ideas that I am not quite ready to explore - like the HTML into browser... that will take me many more hours to study, so I've put it on my To Do list for summer vacation. (and thanks for the suggestion of that technique!)
Title: Re: Document generation - design approach needed
Post by: Petrus Vorster on February 14, 2014, 11:58:46 AM
John, if you get an .inc for VPE and you can make this work, PLEASE post some examples for me!
Are you using the FREE version of VPE with the NAG screen or did you buy it?
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 14, 2014, 12:18:25 PM
I'd be happy to share code when I get it working! (Got hit with more snow last night, so it looks like my coding gets put off till tomorrow and Sunday)

It looked to me as if there's one VPE download that lets you select which version during installation.
I need email capability and to rotate BMPs, so was thinking of getting the Enhanced version. But the difference between free and $498 makes me wonder if I can handle those things myself cheaper. Not sure yet.

I think I'll start with the Community version and see how far I can go with it. Their documentation indicates there are no incompatibility issues changing to another (upwards) version.

I will keep you posted of progress, but you should expect me to be asking more questions, too!
-John
Title: Re: Document generation - design approach needed
Post by: Paul Squires on February 14, 2014, 01:00:30 PM
It might be easier and cheaper to simply fix the memory leaks in gbPrintPreview that James has indicated. Basically, switch from using the DDT syntax to WinAPI.
Title: Re: Document generation - design approach needed
Post by: Petrus Vorster on February 15, 2014, 02:33:41 AM
John & Paul

I hope I dont understand this post of John wrong, but my need is not for preview, therefore the Xprint preview or the GB one really doesnt help.
The need is to be able to create a professional form on the fly with images, words, backgrounds, tables and so forth, and then sends it out via PFD or a printer.
VPE seems to have the answer to this, an easy form/report creator. Making such a form in PB is very difficult (for me).

But then I cannot see on their site any PB support. Just C headers, which i dont have the skills to translate. And then there's the price....
Title: Re: Document generation - design approach needed
Post by: Petrus Vorster on February 15, 2014, 02:35:26 AM
John
;D
Dont complain about the snow!!! We are hitting summer temperatures around 40 degrees celsius!!!! We would LOVE that snow you have!!!!

;D
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 20, 2014, 08:24:25 PM
OK Petrus,
Here's what I know so far:

From the VPE website http://www.idealsoftware.com/en/pdf-library/report-engine.html (http://www.idealsoftware.com/en/pdf-library/report-engine.html)
I downloaded the Enhanced version (code letter = X), and installed it to its own folder.

I'm using the X version, so filenames are: vpeX...


The .INC is by Antonello Ventullo. I got it from message 1 of the PB Third Party Forum:
http://www.powerbasic.com/support/pbforums/showthread.php?t=43337 (http://www.powerbasic.com/support/pbforums/showthread.php?t=43337)



1. To avoid conflict with variable "rect", I added one compiler test to the .INC:

#IF NOT %DEF(%USE_JOSE_INCLUDES)    'jhm added this line (we KNOW this is defined by FF; refer to CODEGEN files)
   #IF NOT %DEF(%WINAPI)
      ' Private Window Messages Start Here:
      %WM_USER = &H400

      TYPE RECT
         nLeft AS LONG
         nTop AS LONG
         nRight AS LONG
         nBottom AS LONG
      END TYPE

      TYPE POINTAPI
         x AS LONG
         y AS LONG
      END TYPE
   #ENDIF
#ENDIF                                ' jhm: added


2. In the file "vpeX3260.INC", I changed all uses of "vpeX3260.dll" to "vpex3261.dll",
then saved it as "vpeX3261.INC"


3. In FF_AppStart, I added:
#INCLUDE "VpeX3261.inc"       ' VPE - Virtual Print Engine


4. In the FF form's CREATE code, I added:
   Local lRet As Long
   lRet = MakeVPEDoc(hWndForm)


5. And then I modified the VPE example (from the Programmer's Reference Manual) for PB/FF:

Function MakeVPEDoc(ByVal hWndParent As Dword) As Long

   Local hDoc As Dword
   
   hDoc = VpeOpenDoc(hWndParent, "Test", 0)
   VpeWriteBox(hDoc, 1, 1, 5, 1.5, "Hello World!")
   VpeLine(hDoc, 1.5, 3, 5, 6.5)
   VpeWriteDoc(hDoc, "hello world.pdf")
   VpePreviewDoc(hDoc, "", %VPE_SHOW_NORMAL)
   
   SetFocus hDoc     
   Function = 1       'someday, a real return value...

End Function


6. I put a copy of the vpex3261.DLL into my FF project's "\release" folder.

7. I found the ".CHM" help files and created desktop shortcuts, then also
  added them to the FF Help Tools menu.

8. Compiled and ran. When the VPE window is displayed, it is minimized and in the upper-left corner
of the screen. Easy to open and view, and in a few clicks to print and email! 

I think that should get you going.

Next, I'm going to read up on all the other commands, and how to place text, etc. Very exciting!

I have not attempted to do any other coding yet; I'm heading home now and will experiment some more tonight. I'll let you know if I have any major breakthroughs or insights.

-John


Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 20, 2014, 10:06:27 PM
Correction!!!

I mistakenly converted the "NULL" in their sample code to ""

Actually, that parameter refers to a RECT, so...

   Local r As Rect
   r.nLeft     = 5
   r.nTop      = 5
   r.nRight    = 800
   r.nBottom   = 600
       
   ...

   VpePreviewDoc(hDoc, r, %VPE_SHOW_NORMAL)
 


...more later...

-John
Title: Re: Document generation - design approach needed
Post by: Petrus Vorster on February 24, 2014, 02:32:31 PM
Hey John

Good to see you are making progress.
Tell me, in this case does the receiver pc also need VPE to be installed?

Jose had a sample here somewhere where he creates documents on the fly with HTML and then creates a PDF.
Post us a few pics of documents you made with this please.

In the meantime i will try to get some samples of creating nice documents with HTML from FF/pb. Perhaps Jose can help out here.
(darn i dont have time. Work at day, study at night!)
Title: Re: Document generation - design approach needed
Post by: Knuth Konrad on February 25, 2014, 02:02:38 PM
Quote
Tell me, in this case does the receiver pc also need VPE to be installed?

If you create documents (files) in a standard format (i.e. PDF, HTML) through VPE, of course not. If you're developing an application which uses VPE: yes. Standard Win32 API DLLs.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 25, 2014, 11:05:26 PM
With regard to needing VPE on the "receiver" PC... I believe they provide a free, distributable viewer for their .VPE files.

Status update: I'm on a business project that has me very busy: work at day, AND work at night! So I'm only doing the VPE coding "when I can". My earlier attempt using Paul's suggestion of a GRAPHIC control with XPRINT is working satisfactorily for my immediate need, so my work with VPE is going to advance as is convenient to my schedule. Don't worry, I promise to return with code. In fact, here's some code that shows how I've been testing and experimenting.

   Local hDoc As Dword, r As Rect
   'Local VPE As otype

   'try setting a different opening position/size; remember them as "LTRB"
   r.nLeft     = 5       ' x1
   r.nTop      = 5       ' y1
   r.nRight    = 850     ' x2
   r.nBottom   = 500     ' y2
                     
   '!!!!!  from the sample program  !!!!!
   'VpeHandle hDoc = VpeOpenDoc(hWndParent, "Test", 0)
   hDoc = VpeOpenDoc(hWndParent, "CoC Creator - Preview, eMail, Print", 0)   'ok during development   
'hDoc = VpeOpenDoc(hWndParent, "CoC Creator - Preview, eMail, Print", %VPE_NO_RULERS)  ' rulers off , or on with 0

'set theme to Whidbey

   VPESetUnitTransformation (hDoc, %VUNIT_FACTOR_INCH)   'not originally in sample code; but I need to work in inches
   VpeSetRulersMeasure(hDoc, 1) ' sets rulers to INCHES with 1; to CM with 0
   
   VpeSetPenSize(hDoc, 0)      ' no frame drawn around the picture
   'place the logo
   VpePicture(hDoc, 1, 0.2, %VFREE, %VFREE, "D:\ProjFF\CoC_Creator\images\letterhead and logo.bmp") 'it's got a lot of space around it.   
'
'   'now try to center the logo
'   VpeRenderPicture(hDoc, %VFREE, %VFREE, MClogo & Chr$(0))
'   'VpeNoPen(hDoc)
''   VpePicture(hDoc, (VpeGetPageWidth(hDoc) - %VRenderWidth) / 2, (VpeGetPageHeight(hDoc) - %VRenderHeight) / 2, %VFREE, %VFREE, MClogo & Chr$(0))
'   VpePicture(hDoc, (VpeGetPageWidth(hDoc) - %VRenderWidth) / 2, %VFREE, %VFREE, %VFREE, MClogo & Chr$(0))
'this kinda works, but puts the logo way the heck out to the right, beyond the pages! zoom WAY out to see it!
                       
   'save the relative positions
   VpeStorePos(hDoc)
   
'SetFontControl()   
'SetFontSubstitution()
   VpeSetFontName(hDoc, "Times") ' & Chr$(0))
   VpeSetFontSize(hDoc, 18)
   VpeSetFontAttr(hDoc, %ALIGN_JUSTIFIED, %TRUE, %TRUE, %FALSE, %FALSE)

   'VpeWriteBox(hDoc, 4, 5, -10, -12, "Certificate of Conformance")
   'in line below, I tried using %VBOTTOM + 1 instead of absolute 5, but it displayed above the logo... (as if VBOTTOM was = 0)
   '  needed to StorePos() first!
   '
   'now to center the text...                                                                   
   VpeRenderWriteBox(hDoc, %VLEFTMARGIN, %VTOPMARGIN, %VRIGHTMARGIN, %VFREE, "Certificate of Conformance" )  '& Chr$(0))
   VpeNoPen(hDoc)
   'VpeWriteBox(hDoc, 5.5, %VBOTTOM, -20, -4, "Certificate of Conformance")      'still not aligning the way I want; use absolute values for now
   'VpeWriteBox(hDoc, 5.5, 5, -20, -4, "C e r t i f i c a t e   o f   C o n f o r m a n c e")  ' interesting effect, but not quite what I want...
   'VpeWriteBox(hDoc, 3, 5, -20, -4, "C e r t i f i c a t e   o f   C o n f o r m a n c e")
   VpeWriteBox(hDoc, 2, 1.8, -20, -4, "CERTIFICATE  OF  CONFORMANCE")
     
   'change to normal font:
   VpeSetFontAttr(hDoc, %ALIGN_LEFT, %False, %False, %False, %False)   
   VpeSetFontName(hDoc, "Arial" & Chr$(0))   'not sure if the zero termination is needed
   VpeSetFontSize(hDoc, 11)
   
   'set date         
   VpeWriteBox(hDoc, 6, 2.2, -2, -0.5, "Date: " & Date$)
   
   VpeWriteBox(hDoc, 2, 2.4, -4, -4, Repeat$(30, "whatever comes next "))
   
   VpeLine(hDoc, 1, 6, 7.5, 6)      ' horizontal line at 6" down...           
   
   'VpeWriteDoc(hDoc, "hello world.pdf")            ' VpePrintDoc() to printer
   'gCOC_SaveName = Exe.path$ & "CoC_" & Trim$(gCOC_values.OurInvoiceNumber) & ".pdf" ' change from exe.path to Std folder...PDFCreator uses MyDocuments
   gCOC_SaveName = "CoC_" & Trim$(gCOC_values.OurInvoiceNumber) & ".pdf" ' change from exe.path to Std folder...PDFCreator uses MyDocuments
   'VpeWriteDoc(hDoc, gCOC_SaveName)
   If Isfile(gCOC_SaveName) Then Kill gCOC_SaveName
   VpeWriteDoc(hDoc, "CoC_" & Trim$(gCOC_values.OurInvoiceNumber) & ".pdf")
   If Isfile(gCOC_SaveName) Then
'      ? gCOC_SaveName,,"Saved as PDF file"
   End If
   
   'VpePreviewDoc(hDoc, Null, %VPE_SHOW_NORMAL)
   'VpePreviewDoc(hDoc, $Nul, %VPE_SHOW_NORMAL)
'   VpePreviewDoc(hDoc, "", %VPE_SHOW_NORMAL)
   VpePreviewDoc(hDoc, r, %VPE_SHOW_NORMAL)
   '!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

   'added by me for PB/FF functions
   SetFocus hDoc     
   Function = 1



I'm finding the VPE command set very powerful and easy to use, but I'm having some trouble understanding how to make all the relative positioning commands do what I want... So although I hate to use them, I'm testing with literal numbers. What I really want to do is create a system of variables that will make it easier to manage and maintain. I have a lot of thinking and design work to do...

BUT, back to my "real" work now.

-John
Title: Re: Document generation - design approach needed
Post by: Knuth Konrad on February 26, 2014, 08:16:57 AM
Quote from: John Montenigro on February 25, 2014, 11:05:26 PM
[...] but I'm having some trouble understanding how to make all the relative positioning commands do what I want... So although I hate to use them, I'm testing with literal numbers. What I really want to do is create a system of variables that will make it easier to manage and maintain.

Make use of the functions return values (i.e. VpePicture returns the bottom right of the box) and or use VpeGet/VpeSet to keep track where the current "cursor position" is.
Title: Re: Document generation - design approach needed
Post by: John Montenigro on February 26, 2014, 08:02:58 PM
Thanks, Knuth! I'll try that out in my next VPE coding session, probably over the weekend.
-John