Dynamic value list on popup causes Big slowdown

[Paolo]

"Products" contain products avaliable from a supplier. for each item several information is provided: description, price, supplier code, etc.

in order to have a product classification, for each item 3 codes are specified (macro-family, family, sub-family)

items are displayed in list view.

the user can edit the product classification by selecting the mfamily, family or sfamily throught three popup menus

popup menus

[ernst]

Hi Paolo

Can't you set the mfamily-, family- and sfamily fields to be

[Ugo DI LUCA]

Hi Ernst, Hi Paolo,

Honestly, I really don't like it, but I disagree with Ernst here.

Conditional value lists can have this behaviour. I had to deal a lot with this behaviour when engineering my product files and others, as I used a lot of conditional VLs on huge related lists.

This can happen even with a 2 fields list actually. From the different tests I've made, this is due to a lack of refresh steps between each commitments of values in the fields.

It is even worse when each values are set to follow each other in the tab order

It would be even slower if after having selected a value from a list, you tend to reactivate this field value list.

What I recommand before any investment is to try the following script, attached to a button or the fields themselves, from which you will uncheck the allow modification in Layout Mode.

Also reset the tab order.

SetField[Fieldx,"")

ExitRecord

GoToField[Fieldx-select]

Loop

Pause/Resume Script[00:00:01]

EndLoopIf[not IsEmpty(Fieldx)]

EndLoop

ExitRecord.

This will force FM to refresh between each step, and surely would help getting the lists to appear quicker.

Even if this may work, I suggest that you use portals rather than value lists when not in List Mode.

Now, it can also depend upon how you created your index calculation in the related file and upon the relationship established.

There are several methods used, and depending upon ones need, one could suit better the case.

The first would be to create 3 relationships.

Relationship#1 - Field1::Field1

Used for Field2 Value List

Relationship#2 - Field1&"-"&Field2::Field1&"-"&Field2

Used for Field3 Value List

Relationship#3 - Field1&"-"&Field2&"-"&Field3::Field1&"-"&Field2&"-"&Field3

Used for Field4 Value List

.....

The second would be to use one relationship only, and to append it to a concanation field in both the Main and the related file

Field1& Field2&Field3&Field4

The third would be to use a MultiKey on Right side and a standard concanation at Left side.

There may be other methods, but for sure the results may be different according to which you're using.

Hope all this makes sense and help.

[djgogi]

Hi Paolo, I think that you see the answer yourself:

The "List" view is reporting view and not the record editing view.(there are many reasons for that)

You pick up the record from list view (where all fields are read only, hence neither conditional value lists are allowed) and you edit it in single record (form) view.

Don't have nothing else to add.

Dj

[Ugo DI LUCA]

Paolo said:

when I switch to this layout FM hangs for about one minute. Scrolling of the list is also extremely slow.

This I had not read carrefully....

and

Dj said:

Don't have anything else to add

Hmm...

Could be it....even if I experienced slow downs even in Form views and solved it with the Exit Record step..Did I say something ? Naa

[Paolo]

Paolo said:

when I switch to this layout FM hangs for about one minute. Scrolling of the list is also extremely slow.

------------------------------------------------------------------------

i'll explain better: if I use popups FM needs 3-5 seconds in order to display a record.

If I switch to the popups layout (and several records have to be displayed) it hangs for a minute. If I scroll down 1 line, just 3-5 seconds.

---------

Ugo said:

>>Now, it can also depend upon how you created your index calculation in the related file and upon the relationship established.

-----

I put mfamilies, families and subfamilies all in a single file structured this way:

Level: 1=mfamily 2=family 3=sfamily

MFamily code: always specified

Family code: (empty if level=1)

SFamily coode: (empty if level=1 or level=2)

Description

Breaking the single file into three will make the mechanism simpler. Probably this will make things faster, but unless I reduce the time of the 90% it will be not enought.

So very probably the best option is djodgi's one: edit the record in form view...

...or resize the window to hold 2-3 records

[ernst]

Ugo DI LUCA said:

Honestly, I really don't like it, but I disagree with Ernst here.

No Problem Ugo, but do you disagree with Paolo needing a 2x2Ghz G5?

I think it will certainly help with slow redraws!

But seriously, what I still do not completly understand is if Paolo's slow redraws only occur when he has the three fields displaying as popup menu's or also if they are changed to standard fields.

Can you elaborate on this, Paolo?

Hi to all,

Ernst.

[Paolo]

if I set the three fields' format to "standard" there is no slowdown.

if I set the three fields' format to "popup menu" there is a 3 seconds delay for each record displayed.

my guess is that FM precalculates the dynamic list inside each popup. With 20 records displayed (60 popups) it's a lot of work.

every field involved in this is stored and indexed.

[Paolo]

I just found a solution...

Using POPUP LIST instead of POPUP MENU solves the problem, (at least on mac, I have to try on PC).

There is no delay and the most popupmenu-like behaviour.