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
**********************************************************************
