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 <[email protected]> Im Auftrag von mferguson--- via
4D_Tech
Gesendet: Freitag, 27. Juli 2018 00:34
An: 4D iNug Technical <[email protected]>
Cc: [email protected]
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 <[email protected]>
> wrote:
>
> Michael,
>
> On Thu, Jul 26, 2018 at 6:32 AM mferguson--- via 4D_Tech <
> [email protected]> 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:[email protected]
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
