Hi Michael, Absolutely, dynamic footer variables are typed as text, but footer sum requires a numeric variable.
Changing the type of a dynamic variable does not work in compiled mode. Only changing the type of dynamic arrays. Would be great if 4D would extend LISTBOX INSERT COLUMN with an additional optional parameter: LISTBOX INSERT COLUMN ( {* ;} object ; colPosition ; colName ; colVariable ; headerName ; headerVar {; footerName ; footerVar} ) LISTBOX INSERT COLUMN ( {* ;} object ; colPosition ; colName ; colVariable ; headerName ; headerVar {; footerName ; footerVar};{footerDataType}) Allowing us to do something like this: LISTBOX INSERT COLUMN ( * ; MyListbox ; 1 ; "Col1" ; $Nil ; "Header1" ; $Nil; "Footer1" ; $Nil ; Is Real) Olivier |||| https://flury-software.ch/ -----Ursprüngliche Nachricht----- Von: 4D_Tech <4d_tech-boun...@lists.4d.com> Im Auftrag von mferguson--- via 4D_Tech Gesendet: Freitag, 27. Juli 2018 00:34 An: 4D iNug Technical <4d_tech@lists.4d.com> Cc: mfergu...@myofficelink.com Betreff: Re: Memory leak with dynamic variables in list boxes? Hi, I converted it to use dynamic variables for the listbox columns insert, passing in nil pointers for the header and footer variables. It works great for regular columns but I can’t get it to work for footers. Specifically: LISTBOX SET FOOTER CALCULATION(*;Object name;listbox footer sum) where the object name is either the column name or footer name, gives me incompatible type. And LISTBOX SET FOOTER CALCULATION(variable_Ptr->;listbox footer sum) where variable_Ptr-> is a pointer to the the column name, column variable pointer, or footer variable_Ptr:=OBJECT Get pointer(Object named;name returned by dynamic variable assignment obtained via listbox get arrays) gives incompatible type even though column is real or $ColumnPtr:=OBJECT Get pointer(Object named;column name) etc. Footers are turned on in the listbox properties. I can’t get any combination to work. Seems like it should be simple, but I’m missing something. I’d appreciate an example from anyone who has this working. Michael > On Jul 26, 2018, at 7:48 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Michael, > > On Thu, Jul 26, 2018 at 6:32 AM mferguson--- via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > >> We have a memory leak in our v15.6 Windows database and have narrowed >> it down to a listbox where the columns are dynamically added using >> LISTBOX INSERT COLUMN. >> The header and footer variables are nil pointers, in accordance with >> the documentation. >> And to reference these variables for the assignment of properties, >> per the >> documentation: >> >> $FtrVar_P:=OBJECT Get pointer(Object named;FTR_Names_aT{$Ndx}) >> $HdrVar_P:=OBJECT Get pointer(Object named;HDR_Names_aT{$Ndx}) >> >> However, the get object pointer above returns nil pointers, so we >> can’t assign properties. >> > I was just writing about using Listbox get arrays for this purpose > when I saw Olivier's post. I suggest this approach as well. > > >> So, we set up our own variable manager that declares and reuses >> header and footer variables for the listbox, using execute formula. >> The variable manager has been tested and the number of variables for >> the form does not grow. However, the apparent search speed preceding >> the display gets slower and slower. The queries themselves are fast, >> but the re-display seems to be the culprit eating up memory. >> > > Using EXECUTE ... is probably not the best solution for what you are > attempting to do. 4D is pretty good at managing these variables. It > sounds like you're working with 4D interpreted. There are a lot of > tricks you can get away with using Execute in an interpreted db that > fail if you plan on compiling it later. > > A few weeks ago another developer was having speed issues with > listboxes as well. In that case he was rebuilding the listboxes every > time there was a change and found the LISTBOX INSERT ARRAY command was > slow. When I build listboxes dynamically I handle the chores of > configuring the listbox (that is, inserting the columns, headers and > footers) and populating them independently. Changes in the data may > require a REDRAW command but usually not re-configuring the whole > listbox. The point is once he changed his approach he found the speed > issue disappeared and overall management was easier. > > -- > Kirk Brooks > San Francisco, CA > ======================= > > *We go vote - they go home* > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************