Announcement

Collapse
No announcement yet.

DDOC page limit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    I'm pretty sure ....
    LOCAL szFile AS ASCIIZ * %MAX_PATH
    and
    szFile$

    ...results in two different variables... but that may be PB-version dependent.

    In any event I never ever do that. I always use "LOCAL|STATIC|GLOBAL varname AS whatever" and never use type specifiers.

    Or maybe it depends on your "#DIM ALL|NONE|ARRAY" compiler directive. Maybe you could toggle whatever you are using and see if the behavior differs.

    Leave a comment:


  • BOB MECHLER
    replied
    The following code has been working just fine with no GPF's for at least 4 years. It's part of a general routine that takes a plain text file report and creates a ddoc report. Every report we produce that isn't started and ended within the BAS is run through this routine.

    Code:
        dpGetFileName hfile%, zFileName,%MAX_PATH
         dpEndDoc hfile%, %DDOC_END_CLOSE
        IF NOPREVIEW THEN
          SHELL "ddoc.exe /PA " + zFileName$
        ELSE
          SHELL "ddoc.exe " + zFileName$
        END IF
    Does the addition of a '$' to zFileName (an ASCIIZ * %MAX_PATH variable) cast it into a normal string?

    Bob Mechler

    Leave a comment:


  • Michael Mattias
    replied
    zFileName (no trailing dollar sign) is LOCAL/DIM AS STRING, then it has no value because dpGetFileName wants an ASCIIZ string for parameter two.
    BTW... this is a good way to corrupt the stack and get one of those 'mystery GPFs' that seems 'impossible' at the point in your code where the protection fault is detected and reported ("appname must close...")

    Leave a comment:


  • Michael Mattias
    replied
    >When I was having the error the code looked like this:
    Code:
              dpGetFileName hfile%, zFilename, %MAX_PATH
             dpEndDoc hFile%, %DDOC_END_CLOSE
              IF zFilename$ > "" THEN
    From context it appears your problem here was far simpler.

    If zFileName (no trailing dollar sign) is LOCAL/DIM as ASCIIZ, then your SHELL is executing with the wrong value following the comma.

    If zFileName (no trailing dollar sign) is LOCAL/DIM AS STRING, then it has no value because dpGetFileName wants an ASCIIZ string for parameter two.

    MCM

    Leave a comment:


  • BOB MECHLER
    replied
    Yeah, I'd noticed the other switches in the code but assumed they weren't implemented. I'm glad you mentioned it because it proved to be the key in fixing another ddoc related problem that just came up this week with another customer.

    They have a user website we built that has a custom feature of allowing the logged in user to download statement PDF's for the past year. They were just now getting up to speed when they started getting out of memory errors from PDFCreator when they created hundreds of pdfs for the first time.

    We changed the code to use the /S flag and instead of the out of memory error we got blank pdfs.

    When I was having the error the code looked like this:

    Code:
              dpGetFileName hfile%, zFilename, %MAX_PATH
              dpEndDoc hFile%, %DDOC_END_CLOSE
              IF zFilename$ > "" THEN            
                SHELL "ddoc.exe /SPDFCreator," + zFilename$
              END IF
    All the pdf's were created but were empty.

    I got a hint from your code that some waiting for a process to complete was probably needed and I had found and used code that did just that only for an entirely different purpose.

    When the additional code below was added, it took a little longer but all the pdf's had content. We sent it on to the customer this afternoon.

    Forgive me if I don't give credit where credit is due for the code. I just don't remember where the technique came from but it was from the forum.

    The SLEEP 1000 may not be necessary but I had to add it at some point in other programs where intermittent problems were occurring.

    Code:
              dpGetFileName hfile%, zFilename, %MAX_PATH
              dpEndDoc hFile%, %DDOC_END_CLOSE
              IF zFilename$ > "" THEN            
                sFilename$ = TRIM$(zFilename$)
                SLEEP 1000
                Yinstance& = SHELL("ddoc.exe /SPDFCreator," + sFilename$)
                Zprocessid& = OpenProcess(%PROCESS_QUERY_INFORMATION + %PROCESS_TERMINATE,%False,Yinstance&)
                DO
                  DIALOG DOEVENTS
                  I& = GetExitCodeProcess(BYVAL Zprocessid&,lpExitCode&)
                LOOP WHILE lpExitCode& = %STILL_ACTIVE
              END IF

    Leave a comment:


  • Michael Mattias
    replied
    It's unclear if the /S is an undocumented feature or you are giving me the code for it.
    It never made it into the help file, but it is a supported feature and in any event you can find it in the source code where ddoc.exe parses the command line.

    It just might be a timing thing, since the normal "dpEndDoc" with "print" or "view" options does a SHELL to ddoc.exe anyway... ie the print or preview runs in another process anyway.

    I had to use it this way because the way the PPPS was designed, the user could change the printer name or change from "print" to "preview" after the report has been generated. That is, he can have an 'inventory' of "*.ddc" files and select which one to print, where and how.


    (At least that was the plan, I still have not added the feature to the software. Thanks for reminding me... I was running low on New Feature Suggestions).

    MCM

    Leave a comment:


  • BOB MECHLER
    replied
    Today was eye doctor day, just recovering from dilated eyes.

    It's unclear if the /S is an undocumented feature or you are giving me the code for it.

    This is the only job where we don't grab the filename, do a dpEndDoc and then shell to ddoc.exe /PA to print in a separate process. I thought if the SpecifyPrinter option was used that it had to be just before dpEndDoc to allow the system to switch to the desired PDF printer and then switch back to the normally default printer right away. I'll study the example however I did try the method where we didn't specify a printer at all and just closed the file(%DDOC_END_CLOSE), which we found under Document and Setting/Local Setting/Temp with no problem(dpGetFileName). Normally after the shelled Ddoc started, we then just deleted the .ddc later

    ddoc.exe /Sprintername,ddcname would be a welcome enhancement and allow a lot of other programs that work just fine with ddoc to get a PDF option since they will be less that 1000 pages at all times.

    I will study this carefully.

    Just as a sidenote, I thought the dpEndDoc was probably releasing the handle but PDFCreator was simply not picking it up in time to return a pointer to the data.

    Thanks,

    Bob Mechler
    Last edited by BOB MECHLER; 10 Jan 2008, 10:13 PM. Reason: Correction

    Leave a comment:


  • Michael Mattias
    replied
    I think you have one thig left to try with ddoc P&P so you don't have to rewrite...

    Do not try to use dpEndDoc with immediate print. Instead, dpEndDoc SAVING the "DDC" file wihtout printing.

    Then SHELL or CreateProcess ddoc.exe with the /Sprintername,ddcfilename command-line option. This will farm out the printing to a separate process.

    It's worth a try, since it's only about three lines of code. Here's how I do it..
    Code:
    ' end the document and set the delete option
           dpEndDoc  grpp.hdoc, %DDOC_END_CLOSE   ' cannot set delete flag here.. it does immediate delete
           ' set the delete flag so the view or print will do that and delete the ddc file when done:
           dpSetDocDeleteFlag grpp.szDDCFileName, %TRUE
    then later after I check if the user wants his reports to go to a printer directly or to preview (toolbar option)...

    Code:
    ...
    '--------------------------------------------------------------------------------------------
              ' Launch ddoc.exe with correct options based on print destination and wait for it to finish
              ' writing to spooler (if send to printer) or enter idle state (if sent to previewer).
              ' ddoc.exe /S wants printername, filename COMMA-SEPARATED
              '--------------------------------------------------------------------------------------------
    
    
              ' 5/26/05 I cannot use simply "ddoc.exe" here because this is not SHELLed.. it results in failure
              ' unless ddoc.exe is on the path
              'CALL          PPP_ProgramPath(lpfile)  ' returns with trailing slash
    
              'lpfile     = lpFile & "ddoc.exe"
              lpfile     = ""
    
              LOCAL szDdoc AS ASCIIZ * 16, szFilePart AS ASCIIZ * 16
              szDdoc= "ddoc.exe"
    
              i          =  searchPath(BYVAL %NULL,        szDdoc,    BYVAL %NULL,      SIZEOF(lpFile), lpFile,   szFilePart)
              '                        path, null=default  filename   extension if not  destination for fully-   filename only
              '                        Windows path        to file    part of filename  qualified filename found
              IF ISTRUE i THEN
                    '  MSGBOX "SearchPath found ddoc.exe as ==>" & lpFile ' OK '5/26/05
                 lpVerb                = "open"
                 IF @pPCJ.Destination.iType = %UO_PRINT_OPTION_PREVIEW THEN
                         lpParameters  =  grpp.szDdcFileName
                 ELSEIF @pPCJ.Destination.iType = %UO_PRINT_OPTION_PRINTER THEN
                         lpParameters  =  "/S" & @pPCJ.Destination.szName & "," & Grpp.szDDCFileName
                 ELSE
                         MSGBOX "invalid @ppCJ.Destination.itype"
                 END IF
                 iTimeout      = %INFINITE
    
                 SEI.cbSize       = SIZEOF(SEI)
                 SEI.fmask        = %SEE_MASK_NOCLOSEPROCESS  ' we need the returned process handle
                 SEI.hWnd         = @pPCJ.hWndCaller
                 SEI.lpVerb       = VARPTR(lpVerb)
                 SEI.LpFile       = VARPTR(lpFile)
                 SEI.lpParameters = IIF& (lstrLen(lpParameters), VARPTR(lpParameters), %NULL)
                 SEI.lpDirectory  = %NULL
                 SEI.nShow        = %SW_SHOW      ' should be zero for a document file PER MSDN DOC.
                                                  ' MSDN DOC IS WRONG, use SW_SHOW!
                 SEI.hInstApp     = 0             ' updated by function
                 SEI.lpIdList     = %NULL         ' here down to hprocess ignored unless appropriate mask included in fmask
                 SEI.lpClass      = %NULL
                 SEI.hkeyClass    = %NULL
                 SEI.dwHotKey     = %NULL
                 SEI.item         = %NULL
                 SEI.hProcess     = 0             ' will be updated by ShellExecuteEx
    
                 IF ISTRUE ShellExecuteEx(SEI) THEN       ' function succeeded and returned
                   IF @pPCJ.Destination.iType = %UO_PRINT_OPTION_PRINTER THEN
                         iWaitStat      = WaitForSingleObjectEx (SEI.hProcess, iTimeout, 0)
                   ELSEIF @pPCJ.Destination.iType = %UO_PRINT_OPTION_PREVIEW THEN
                         iWaitStat      = WaitForInputIdle ( SEI.hProcess, iTimeOut)
                   END IF
    
                   SELECT CASE AS LONG iWaitStat
                     CASE -1&
                          E = GetLastError
                          'MSGBOX "Wait Failed:" & SystemErrorMessageText (E)
                          fv =  E
                     CASE %WAIT_OBJECT_0
                         ' this is good, we can post a success code
                           fv = 0   ' success
                   END SELECT
                   CloseHandle SEI.hProcess
                ELSE
                    fv = -1&  ' non-zero, error could not launch ddoc.exe
                    MSGBOX "Could not launch previewer"
                END IF    ' fi shellexecuteEx succeeded
    
             ELSE    ' searchpath failed to find ddoc.exe
    
               PPPS_ERRORMSGBOX ("Can't find Print Library 'ddoc.exe installed" & $CRLF & "Cannot Print.")
             END IF  ' if we found ddoc.exe using searchpath
    To set the delete flag you have to modify the file header of the DDC file...
    Code:
        
    'TYPE I can use without divulging any proprietary info
    
    TYPE DDHTYPE
        Fill0      AS STRING * 114
    END TYPE
    
    
    FUNCTION dpSetDocDeleteFlag (szDdcFile AS ASCIIZ, FlagValue AS LONG) AS LONG
    
        LOCAL hFile AS LONG, ddh AS DDHTYPE, iFlag AS INTEGER
        iFlag   = ISTRUE (FlagValue)          ' convert to integer
        hFile   = FREEFILE
        OPEN      szddcFile FOR BINARY ACCESS READ WRITE LOCK SHARED AS hFile BASE=0
        IF ISFALSE ERR THEN
           SEEK      hFile, SIZEOF(ddh.Fill0)
           PUT       hFile, , iFlag
           CLOSE     hFile
        END IF
    END FUNCTION
    Well, it's maybe ten lines of code instead of three once you extract what you need, but it's still not a lot to try to avoid the preview and I think it's worth a try.

    (Much of code above you don't need but I left it in to make sure everything is there).
    Last edited by Michael Mattias; 10 Jan 2008, 08:59 AM. Reason: corrected ddoc command line text to add comma, ddcfilename

    Leave a comment:


  • BOB MECHLER
    replied
    As far as the Ddoc is concerned. Here are the steps we used.

    We tried to use SpecifyPrinter and then dpenddoc %ddoc_specifyprinter which works at 24,000 and prints real info through PDFCreator to a specified PDF file.
    We tried with %ddoc_viewbuild which allows you to view the pages as they are being created. I put a msgbox just before the dpEndDoc and all data was there in the preview. Went to page 1 and various pages and the last page of 44,328 or so pages. As soon as I dismissed the messagebox and executed dpEndDoc the data disappeared while the print preview was still on screen but now with no data.

    I tried with no msgbox and no specify printer, just a %ddoc_end_close. All with the same result. A 65 megabyte file with 44,328 empty pages.

    These were annual statements representing about 10 billion under trust. The customer produced 24,000 pages just fine and sent to their third party mailer who normally takes care of turning the single pdf into a mailout. The customer had to printout and hand stuff 6300 themselves by printing to the their local printer.

    We only have one option at this point and that is to have the customer break it into two print jobs. In GUI mode PDFCreator will allow two .ddc files to be loaded into the queqe while the auto-printing is turned off. Once there, you can combine the two documents, turn printing on and get one pdf. I've tested this with some small files. We don't know if this will actually work though with the large ones. I've already spent 12 hrs testing ddoc with different configurations.

    I tried XPRINT simulating the same thing. It attaches to the printer and feeds PDFCreator from statement one. It didn't have a problem working this way and was really fast. We are currently waiting to see if Don can figure it out. If not, we'll re-write this program in PB ver 8 using XPRINT. XPRINT has all the functions we need. There is too much stake here.

    I'll let you know how it comes out. Personally we never thought to check this size of a job.

    We actually have two other customers whose PDF output will be larger than this coming up.

    Bob Mechler
    Last edited by BOB MECHLER; 9 Jan 2008, 08:29 PM. Reason: Corrections

    Leave a comment:


  • Michael Mattias
    replied
    The problem comes when loading it into print preview. We normally do that and then send it on to PDFCreator or someother pdf printer.
    If those applications are just printers on the system, why not select that printer and print directly, skipping the preview? You can do that with ddoc P&P. (besides, do users really view 24,000 page reports?)

    If you want, I know there is a way to turn off the automatic printing when spooling and leave the finished document spooler file in the print queue, from where you can do all kinds of stuff.

    MCM

    Leave a comment:


  • DonDickinson
    replied
    ya, but i do use inclean from borje on everything else i do .. except i started ddoc in 1997, before inclean. i tried to inclean the ddoc files one day; that's what started my cleaning up the code. big chore the old winsock includes are the biggest mess. i took some declares out of them and moved others around and mucked things up good.

    Leave a comment:


  • Michael Mattias
    replied
    Can't blame you for the multiple #INCLUDE files, can we?

    ddoc P&P was originally created with PB 6.0 (or maybe even 5.0), which had a serious limitation on the size of any one physical file used during compilation.

    e.g., until I ported it to PB/7, the PPPS "GUI Module only" consisted of some 24 physical files.

    MCM

    Leave a comment:


  • BOB MECHLER
    replied
    I'll have to produce one with sample data since the specific .ddc contains live data on customer statements for a Trust Company. Just will take a little longer to reproduce. We've reproduced in several environment. Sometimes it messes up after 24,000 pages and on our equipment here using a different data set it messed up after 34768 pages.

    The problem comes when loading it into print preview. We normally do that and then send it on to PDFCreator or someother pdf printer. The customer requires it all to be in one PDF. We thought about breaking the job into two .ddc's since PDFCreator will allow .ddc's to be loaded into it's print cache with the 'output job' setting turned off. From there it will allow a combine operation to produce a single PDF. Since PDFCreator has a COM interface, I was going to play around with that to see if it could be done automatically inside the program.

    Bob Mechler

    Leave a comment:


  • BOB MECHLER
    replied
    I'm creating one as I'm writing this. Thanks, Don.

    Bob Mechler

    Leave a comment:


  • DonDickinson
    replied
    just when you may have thought i went the way of Dave Navarro or Lance Edmonds, i poke my head back in anyone hear from those guys anymore?

    well, to point ... ddoc's page limit is the limit of a 4 byte signed integer. so, a little over 2 billion. if you're seeing pages come up blank that usually means the file is corrupted or invalid in some way .. using a feature available in ddoc32.dll but not in ddoc.exe. if you can send me the .ddc file:

    g r e a t w e b d i v i d e _AT g m a i l _DOT c o m

    i'd be happy to have a look. for the curious ... i haven't given up on ddoc programming, but i did put the project in a holding pattern for a few years. i'm back at it now. and, yes, mcm, i'm cleaning up my stupid headers and the code in general. it is quite a chore unfortunately.

    -don

    Leave a comment:


  • BOB MECHLER
    replied
    PDFCreator has a COM interface that exposes all the functionality. It's a sourceforge project.

    You can load it as a GUI app or run it on the command line.

    I was able to load the program, tell the printer to wait and load several .ddc's into a grid. Then it provided an option, if I selected all the ones I loaded, to combine them. It seems to take the ones selected, run them through the associated print engine and combine them into one PDF. Then by un-Stopping the printer it puts it to a PDF file. Trouble is, I don't know COM well enough yet. I did manage to produce the dispatch include file. There is a sub that does the combining.

    There are also examples in VB.NET 2003,2005 and VB6 as well as Excel and Word.

    As I learn more, I'll share but it might be a while.

    Bob Mechler

    Leave a comment:


  • Paul Franks
    replied
    Originally posted by Joe Byrne View Post
    Bob,
    There are two 'open source' projects that are interesting.
    There's also PoDoFo on SourceForge. Still very alpha quality, though.

    If anyone else is interested, I'd be willing to investigate putting a team of people together to port the iText to PB (actually, to a Win32 DLL).
    Well, maybe when PB becomes OOP, and even then a huge effort. It is possible to compile an older version of specific functions to DLL or EXE using MinGW/MSYS (it's how pdftk was created), but exposing the entire API of iText in a DLL would be an enormous task. The resulting DLL would be very cumbersome, as you would need handles for everything, vs. the very easy-to-use OOP interfaces of the Java lib (I use it very frequently, both in Java and as compiled DLLs for specific tasks).

    Leave a comment:


  • Michael Mattias
    replied
    This thread reminds me of something...

    I have a client who is printing, stuffing and mailing 15,000 invoices per year to one customer.

    I have set a goal for the first quarter to get him to sign up for the necessary software development services to change from paper to electronic invoicing. I'm pretty sure that will save him a few bucks in not too much time: since he already does electronic invoicing with about 10 other customers he will have exactly zero 'infrastructure' costs to do this development.

    Then again, I've been working with ANSI ASC X12 and EDIFACT EDI applications for twenty years... and they say to the man who knows how to use a hammer every problem looks like a nail.

    MCM

    Leave a comment:


  • José Roca
    replied
    I suppose one can find just about anything someplace on the Internet, but alas when looking for PB related items, I normally only look at the PB site.
    Currently there are many PBers that have his own web site and/or forums. Please consider all the code that I have posted in the PB Source Code forum in the past as deprecated. It is a good idea to see if the signature of the author of the code provides a link to a web site or forum.

    Leave a comment:


  • Joe Byrne
    replied
    Originally posted by José Roca View Post
    Of course it has been updated. Up to date headers and many examples are available in my forum for free to registered users.

    http://www.jose.it-berater.org/smffo...hp?topic=373.0
    Oops, ok. My mistake. I probably should have said "when I was working with Haru, the header files available on PowerBasic's web site did not contain the latest changes to the library".

    I suppose one can find just about anything someplace on the Internet, but alas when looking for PB related items, I normally only look at the PB site.

    Leave a comment:

Working...
X