Why should VFP allow large programs?


I received a question regarding this post: How do large programs work?


 


Hi Calvin. I thought we’re supposed to write granular, encapsulated programs. I have read that the highest quality code is also some of the smallest code. If that’s true, then why, oh why permit any one to write a monster routine thousands of times bigger than 64K?


 


Yes, it’s true that good programming practice encourages modular, encapsulated programs. Some people feel that a function should be completely visible on the screen.


 


Looking back at the feature request in our internal documents, I found this topic: “Optionally enlarge 65kB limit for compiled code in programs” with this comment:


 


I don’t know why this “limit” exist in 32bit Windows, but our large programs generated from framework generator, must be fragmented to separately aplications. Please look in compiler, if there is only forgotten limitation from 16bit DOS times.


 


Another big motivator of this feature was customers bumping into this limit when creating fairly complex queries. Also each byte in a literal string adds one byte to the compiled program. If you have long table names, each with 250 fairly long field names, each with a few DBSetProps, the compiled program gets quite large.


 


I just created a simple remote view on SQL Server Northwind joining 4 tables and here are a few lines generated from it


 


SELECT Customers.CustomerID, Customers.CompanyName,;


  Customers.ContactName, Customers.ContactTitle, Customers.Address,;


  Customers.City, Customers.Region, Customers.PostalCode,;


  Customers.Country, Customers.Phone, Customers.Fax, Orders.OrderID,;


  Orders.CustomerID, Orders.EmployeeID, Orders.OrderDate,;


  Orders.RequiredDate, Orders.ShippedDate, Orders.ShipVia, Orders.Freight,;


  Orders.ShipName, Orders.ShipAddress, Orders.ShipCity, Orders.ShipRegion,;


  Orders.ShipPostalCode, Orders.ShipCountry;


 FROM ;


     dbo.Customers Customers ;


    INNER JOIN dbo.Orders Orders ;


   ON  Customers.CustomerID = Orders.CustomerID ;


    INNER JOIN dbo.”Order Details” Order_details ;


   ON  Orders.OrderID = Order_details.OrderID ;


    INNER JOIN dbo.Products Products ;


   ON  Order_details.ProductID = Products.ProductID


 


DBSetProp(ThisView+”.contacttitle”,”Field”,”DataType”,”C(30)”)


DBSetProp(ThisView+”.contacttitle”,”Field”,”UpdateName”,”dbo.Customers.ContactTitle”)


DBSetProp(ThisView+”.contacttitle”,”Field”,”KeyField”,.F.)


DBSetProp(ThisView+”.contacttitle”,”Field”,”Updatable”,.T.)


 


 


Does anybody appreciate this feature? What are some reasons you have large programs? Please post a comment if you do.


 

Comments (17)

  1. Rick Schummer says:

    I know developers I have mentored over the years that ran into the 64K limit with VFP generated stored procedure based RI code (before I introduced them to Steve Sawyer’s NewRI approach). I personally never hit this limit, but figure there must be good reasons why developers hit this.

    That said, I never thought I would need arrays larger than 64K until I was processing a folder filled with images at a customer site one day. The folder had something like 20K folders and VFP 9’s new array size limit was the thing that did the trick for me. Heck, why would anyone want to process 64K worth of array elements? It is not a best practice. Then wham, I get smacked with a good reason.

    Sure the best practice is to keep the modules small, but with trade offs and different approaches, it is one of those things with different strokes for different folks.

    Your implementation does not penalize those who implement best practices, and still gives others a way to work around their own issues. Looks like a win-win.

  2. Garry Bettle says:

    I think it’s a very weird question for VFP.  

    A better, and certainly more relevant question, might be why Office 12 is going to allow > 1 million rows in Excel?

  3. Marco Wotschadlo says:

    In my opinion it’s needed for automatic generated code like from Active FoxPro Pages.

    The design of AFP-applications and pages is somewhat similar to ASP.NET. There is a visual representation with (X)HTML, a "code behind" page  with plain VFP code and some additional features like global events. All those files are automatically merged into one (big) .PRG and compiled to an .FXP.

    So, I really appreciate that feature :=)

  4. Jack Liebschutz says:

    We ran into this limitation in several projects with the size of the menu program generated.  We had to break our menus into pieces because they hit the 64K limit.  Thank you very much for removing that limitation.

  5. Calvin,

    I really appreciate the support for large programs and large arrays.

    We’ve found the large program support works great for programs that use the TEXT/ENDTEXT and , \ TEXTMERGE features. It is very easy to create programs larger than 64K when such programs have embedded content.

    We’ve recently started to write programs that generate PRG files with VFP logic/flow control and lots of embedded , \ statements. These generated programs in turn are used to generate XML, HTML, and RTF output. Awesome!

    BTW: On the topic of writing VFP applications that output VFP source code – any thoughts on giving us a hook into the VFP compile process that would allow us to write our own pre-processor in VFP that would preprocess the code being sent to the VFP pre-processor/compiler? (Apologies, but I couldn’t think of a simpler way to make that request)

    VFP’s string processing and textmerge capabilities are soooooo powerful and the VFP environment is soooooo extensible, that this seems like such a natural capability … and certainly the ONLY area of extensibility where I see VFP lacking.

    THANKS AGAIN FOR SUCH A GREAT DEVELOPMENT TOOL!!!

    Malcolm

  6. Hey Calvin!  I’ve used very large generated programs for testing VFP itself — Creating hundreds or thousands of subclass levels, then testing instantiation performance.  I’ve also created very large programs to iterate through VFP’s classes, subclassing them deeply, and then nesting them to improbable levels of depth to stress-test the product.  Sometimes I’ve done this up until the program size limit.  It’s not a real-world implementation, but i thought you’d like to know that I was always very impressed with VFP’s ability to handle these way-out conditions, and in the rare case it didn’t, you fixed it quickly 🙂   Keep up the great work.

  7. Chris Carron says:

    We hit the limit in a procedure used to load a lot of static (and various) data we didn’t want to store in tables. Thanks VFP9!

  8. Doug Mahugh says:

    It’s easy to grow a pretty large program over a few years if you’re constantly tinkering around and adding functionality. Support for large programs is a good thing for those situations, and there are lots of those bloated APPs and EXEs out there.

    That stuff Steve puts VFP through, on the other hand, that’s just sadistic. 🙂

  9. Mike Yearwood says:

    Sorry Calvin, but I have no need for this "enhancement".

    Large arrays: Sys(2000) can be used to iterate the files without *needing* huge arrays.

    Menu generation: The VFP community has wanted OOP menus for what seems like forever. The scx and frx don’t generate code anymore. Code generators as a whole seem to have become bad practice many years ago.

    Large menus are very difficult on the user.

    Growing programs over the years so they exceed manageable limits – sounds like a sandwich someone left in their locker.

    Each to his own I guess.

  10. It’s one of the greatest features in VFP 9 (although there are many more). We need it for AFP (http://www.afpages.com), because AFP compiles each source file into a single PRG file. With all the HTML inside the document, these files can grow pretty quickly beyond the 64 KB limit.

  11. Grady says:

    Why not?

  12. Mike Potjer says:

    If every PRG you ever use is hand-crafted, then it’s not a big deal.  But, as others have stated, for any code that generates a PRG programmatically, very large program sizes make that task considerably easier, because it eliminates all the code you would need to make sure you don’t exceed the 64K limit.  As we all know, less code in such a generator means less opportunity for bugs.

  13. Andreas Lange says:

    I have never reached the limit of 64K until I decided to rewrite a program which I knew very well. The structure was nearly "visible" for me like a long text in literature. With the feature "document view" and "bookmarks" I could handle the code very fast. The need of modulation comes from the wish of better understanding and documention of complex structures but in the rare case of total oversight it could hinder the creative process.