Hi Chip, Thanks for your quick response, it is much appreciated
First of all you are right that I could recode some parts and is also for other reasons sometimes no bad idea at all > Load the list boxes as you go. Depending on your usage, you might only need 1, > or 4 list boxes not 27(!) In fact our customers have big screens an want to see a lot of data at once They like how it is displayed right now. I have counted the listboxes displayed at once and the number is 10 !! So, after a lot of recoding they still have to wait for more than 5 seconds > When the form loads, the Tab control is used to determine what data to > display, and the listbox is built appropriately I know I could do something like this, and maybe there is no escaping of doing this I also read about a way to create subforms and use OBJECT SET SUBFORM to dynamically change the subform But, bottom line, we are skipping the fact that still the command LISTBOX INSERT COLUMN is very slow compared to all other commands And we wouldn't probably having this discussion if it was executed as fast as the other commands Again, thanks for your response, Piotr > -----Oorspronkelijk bericht----- > Van: Chip Scheide [mailto:4d_o...@pghrepository.org] > Verzonden: vrijdag 1 december 2017 16:35 > Aan: 4D iNug Technical <4d_tech@lists.4d.com> > CC: Piotr Chabot Stadhouders <p.stadhoud...@timeff.com> > Onderwerp: Re: poor performance LISTBOX INSERT COLUMN > > 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 **********************************************************************
