Piotr recode this! On Fri, 1 Dec 2017 14:49:11 +0000, Piotr Chabot Stadhouders via 4D_Tech wrote: > > No big deal you could say, but for a couple of our forms it IS a big deal > We have a form with 27 listboxes on it, all dynamically build, with a > total of 477 columns recode this - I can't say this enough!
I do not know what your interface looks like, however, I find it difficult to believe that more then 2 or 4 list boxes are on screen at one time, maybe not even that. Load the list boxes as you go. Depending on your usage, you might only need 1, or 4 list boxes not 27(!) Basic concept (assume 1 listbox on screen at a time - modify to meet your specific on screen needs, the base form has ONE listbox, with no columns) On load - determine what is being displayed (which table/data set) - setup the listbox for this data during execution of the form. repeat as needed - user changes 'page', using a tab control (or whatever user does to change displayed data) - determine which data set is needed based on user 'request' (above step) - (re)build the listbox for this new data set - using the SAME listbox <-- this is the key... the SAME LISTBOX using this approach you should not need to build/load more list boxes then are currently on screen. In addition to this you can reduce the form's complexity by removing 20+ list boxes, this in it self will help the form load faster, and use a far smaller memory footprint. Reducing your form complexity may increase code complexity - but the increase will be a LOT less then the decrease in your form's complexity. As example: - Listing forms : for my systems I use a single form/listbox (selection based) for record listings. It is built based on the current table to be displayed. The base listbox has NO columns in it. The listing form is a project form, and in a few instances is used as a parent form for inheritance (when additional functionality is needed in addition to the standard functions provided). - Entry forms : many of the entry forms in my systems display related data (i.e. Invoice [parent], and Invoice items [children in listbox]). Some forms have as many as 11 "pages" of related information to be displayed, controlled by a Tab Control (not actual form pages). These entry forms have 1 listbox on page 0 (zero), so the form has 2 pages, page 0 (zero) and page 1. When the form loads, the Tab control is used to determine what data to display, and the listbox is built appropriately. During form execution, when the user selects a specific Tab in the control, the SAME listbox is re-built to display that specific information. In both of the instances (examples) above - interpretedly, in C/S, there is no noticeable time required to build the list boxes, regardless of how fast the user changes tabs. If you want some example code on how to do this, I can provide an example database (v11 or v13 I forget which) Actually, if anyone wants the demo - feel free to ask off list. Note: the demo stores data for building the list boxes in 3 tables in the database, and note THIS IS NOT a component, nor does it use 'widgets' (subforms <-- really bad naming convention). The 3 tables are: Listbox setup data ([table], dimensions, listing or entry listbox etc), Column setup data (field or calculation info, order, formatting, enterable, visible etc), and query (specifics {fields, relations, field title to show users, etc} for the [table] displayed using an iTunes like search object) --------------- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************