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