Announcement

Collapse
No announcement yet.

DDOC page limit

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

  • DDOC page limit

    A customer tried to do a large job that stopped in DDOC at 34768 pages but they were all blank. Same program the week before did 24,000 + pages just fine. This time they ran in a Citrix environment. I'm guessing Citrix limits the memory that can be grabbed or DDOC has a page limit.

    Anyone know for sure?

    Bob Mechler

  • #2
    Speed Reader??

    Hummmm

    No knowledge about Ddoc or Citrix but your customer must be able to read pretty fast to use a 32,000 page report.

    OK --- I know you can search for a page you want but it would seem some other "non-report" solution might prove useful also.

    I am not trying to be critical since I don't know your app or customer but I am just curious and could not resist poking some fun ... my apologies in advance.
    Mark Strickland, CISSP, CEH
    SimplyBASICsecurity.com

    Comment


    • #3
      One of these days... I am going to take all those #INCLUDE files which make up ddoc.bas and ddoc.32.bas and "in-line" all those files into one source file. Then I will find this.

      Meantime, what do you mean "all blank" -- that's the way they printed? or that's what you see in "preview?"

      First thing I'd do is change the code to not delete the *.DDC file. Then I'd use Ultra-Edit or something like it to see if my text is in the DDC file. If it ain't, the problem comes BEFORE "print" or "Preview"... if it is, the problem is in "print" or "preview"

      If nothing else, you have better idea of where to look for the problem.

      MCM
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        >I'm guessing Citrix limits the memory that can be grabbed or DDOC has a page limit.

        Citrix could do that, but you'd think ddoc would report 'unable to allocate'

        Regardless, ddoc should not be grabbing all that much memory anyway. Only thing I can think of in ddoc which could grab that much would be many, many (many) graphics.
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Originally posted by BOB MECHLER View Post
          A customer tried to do a large job that stopped in DDOC at 34768 pages but they were all blank. Same program the week before did 24,000 + pages just fine. This time they ran in a Citrix environment. I'm guessing Citrix limits the memory that can be grabbed or DDOC has a page limit.

          Anyone know for sure?

          Bob Mechler
          From the history file included with 1.9e

          " Version 1.4 Released Upgrade 1.4.99
          **********************************************************
          >> ddoc used to be limited to 4000 pages. It is now limited
          only by the memory on your computer (actually limited by
          the size of a long integer - 2 billion + pages)."

          So the limit is not intended but could be a bug...
          Dominic
          Manchester UK

          Comment


          • #6
            I modified ver 1.9c to include a find button that would highlight lines in red that contained a search key. Maybe we need to switch this particular customer to 1.9e and see what happens.

            This customer is a major bank and they produce a PDF by bringing up ddoc's print preview and sending the entire job to a PDF. They then send the PDF to a mailing house that collates the statements (blank page between each statement) and sends them out. They were able to run a partial statement run with 27,000 pages but when they tried the entire run it produced 34768 pages all of which were blank. There is not an option of them breaking up the print job so we have to get an answer or switch to some other method.

            I'll try 1.9e.

            Bob Mechler

            Comment


            • #7
              Bob,

              I used to use DDOC myself, but it didn't take long for my customers to figure out that it wasn't "compatible" with anything else. So, for my last update, I stripped out all the DDOC stuff and went pure PDF. It took a bit of learning, but I am convinced that its the best way to go now.

              I ended up using isdQuickPDF mainly because I jumped on the change to get a source-code license a few years back. The biggest "problem" is the fact that there is no 'vendor' support any longer. There is a small, but dedicated group that make bug fixes and help each other out a lot, but basically, it looks like this one is dead.

              There are two 'open source' projects that are interesting. 'iText' appears to be a very active PDF generation platform. However, its primarily Java with a port to dot net. Perhaps someone with some talent could create a PB port. I'm sure it would be a HUGE hit around here

              The other option is HARU which is also open source. There is a PB include file floating around here someplace for it too. I used this for awhile. Its pretty good, but the include file hasn't been updated to keep up with the latest releases of Haru and since I had QuickPDF available to me, I opted to go that route instead of putting time into either of these other options.

              You might want to give Haru a look-see. It could very well be a good solution for you.

              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). I know the question of PDF generation comes up from time to time, and it would be nice to have a definitive 'source', especially an 'open' source, for PBers.
              Software makes Hardware Happen

              Comment


              • #8
                I recently downloaded 'HARU' but have not had time to play with it. Ddoc is crucial to our operation as we've developed a generic wrapper to output our standard reports and have also created many custom reports using the wrapper functions embedded in our programs. We've always just temporarily changed the default printer to a PDF printer (CutePDF,PDFCreator etc) to produce the PDF and then changed it back to whatever the default printer was before the report was started. It is isn't a perfect solution.

                I'll share the results when I finish testing v1.9e.

                I wish there was a way to concatenate two ddc together. Just have the program output a set number of complete pages and then close that file and open another one. At the end of the run, concatenate the output. But alas, I don't have a clue how this could be done.


                Bob Mechler

                Comment


                • #9
                  The other option is HARU which is also open source. There is a PB include file floating around here someplace for it too. I used this for awhile. Its pretty good, but the include file hasn't been updated to keep up with the latest releases of Haru and since I had QuickPDF available to me, I opted to go that route instead of putting time into either of these other options.
                  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
                  Forum: http://www.jose.it-berater.org/smfforum/index.php

                  Comment


                  • #10
                    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.
                    Software makes Hardware Happen

                    Comment


                    • #11
                      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.
                      Forum: http://www.jose.it-berater.org/smfforum/index.php

                      Comment


                      • #12
                        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
                        Michael Mattias
                        Tal Systems Inc. (retired)
                        Racine WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          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).
                          --pdf

                          Comment


                          • #14
                            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

                            Comment


                            • #15
                              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

                              Comment


                              • #16
                                I'm creating one as I'm writing this. Thanks, Don.

                                Bob Mechler

                                Comment


                                • #17
                                  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

                                  Comment


                                  • #18
                                    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
                                    Michael Mattias
                                    Tal Systems Inc. (retired)
                                    Racine WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      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.

                                      Comment


                                      • #20
                                        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
                                        Michael Mattias
                                        Tal Systems Inc. (retired)
                                        Racine WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X