Nils ! Stop your hunting work for any of the bug I have reported and continue
only after having read this message ! Mine was an incorrect bug report becouse
I have found an ADDLVFIELDENTRY hidden inside a G4C gui !!!

 Let me correct myself quoting from my first message:

---- FROM THE BUG REPORT ------------------------------------------------
SETFIELD 'CreateListEntries' 'STEM' '"DBC_Cliente"'

 Where DBC_Cliente. are connected SELECTONLY listviews.

 When the SETFIELD command is executed Fiasco does not recognize that the
database has changed thus if I select LOAD in the menu no warn requester
appears.
-------------------------------------------------------------------------

 This bug persists..

---- FROM THE BUG REPORT ------------------------------------------------
 I could say the problem is all here but becouse I like to let you be
desperate in front of my bug reports I have experimented with the script a
lot !  :-)
 There are many problems in the LV implementation..
-------------------------------------------------------------------------

 And in my brain too...

---- FROM THE BUG REPORT ------------------------------------------------
 Using the previos script, the command '"DBC_Cliente"'> where DBC_Cliente..COUNT is 0, a LINE in then
empty LVs is always created.
 (Verified executing a Getfield '""' 'listentrycount' before and
after the SETFIELD command)

 Obviusly I have the same result when x (.COUNT) is 1 instead of 0.
-------------------------------------------------------------------------

 No no no no, it does not exist !  Like I have already stated there is an
ADDLVFIELDENTRY hidden inside a gui that adds one line just after the
SETFIELD command...

---- FROM THE BUG REPORT ------------------------------------------------
 Then I have experienced these other workings:

 If I set .count of all the LV to 1 and I initialize the respective stems
line to something and the SETFIELD command is executed using these data,
 returns 7 entries for the first LV and 1 for
the others.  There are 7 selectable lines in the LV (but empty).
-------------------------------------------------------------------------

 This bug persists but the report have to be corrected, to explain it
you must consider only the following report:

---- FROM THE BUG REPORT ------------------------------------------------
 If I set .count of all the LV to 1 but I set only the stem number 1 of the
first LV and do the SETFIELD,  returns 7 on the
first LV and 0 in all the others (and 7 lines are selectable).
-------------------------------------------------------------------------

 The REAL BUG IS IN:  ADDLVFIELDENTRY '"CODPROD"' 'Listentry' '0'
that is executed after the command I have reported in the quote.
 It creates 6 list entries other than the one created by setfield.  As I
have 6 connected LVs I suppose it is not a coincidence, look at your
routines, something is pointing to a wrong data/structure.  To verify this
I have deleted one LV and magically the created lines have changed from 6
to five. (Plus the one created by 'Setfield')

 There is a side effect I suppose it is connected to this bad pointer:
I have converted these LVs from ReadOnly to normal ones and when I select
the just created lines of the first LV (2nd, 3rd, 4th, 5th, 6th) the gosthing
of the string at the bottom of the LVs disappears in this order:

 Line Selected in 1st LV  |  Ghosting disappears in LV
 -------------------------+--------------------------
 2nd                      |         5th
 3rd                      |         4th
 4th                      |         3rd
 5th                      |         2nd


---- FROM THE BUG REPORT ------------------------------------------------
 In the same situation, If I set only the first line of the second stem,
its stem returns 2 lines and 1 in the others.

 When I manually select an item in the LV, it is then updated and fiasco
reveals to have set the second line of the LV but not the first as
requested.
-------------------------------------------------------------------------

 Forget this one but one thing:  fiasco does not update the displayed LVs
contents until the user clickes the LMB inside the LV.

 My apologies for the unusefull work...

 Ciao,
   Giuseppe Chillemi

PS:  However, the working proposal explained after the BUG report is still
    valid, hope you'll implement it.


-------------------------------------------------------------------------
fiasco - Majordomo 1.94.4 - http://www.amigaworld.com