Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Unexpected Behavior Adding Grid Columns as Listed in Table
Message
De
23/07/2000 16:35:13
Cindy Winegarden
Duke University Medical Center
Durham, Caroline du Nord, États-Unis
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Titre:
Unexpected Behavior Adding Grid Columns as Listed in Table
Divers
Thread ID:
00396007
Message ID:
00396007
Vues:
49
I have a form class which will be used with either of 2 tables which have some fields in common but not all. I have a list of the columns I want to include in the grid, which I have put in a GridColumns table. The fields are (ColumnNo I, GridColumn C, ColumnName C).

At the time I didn't know that the parameter in the ADDCOLUMN() method was the visible order number and not the position in the Grid.Columns collection/array, but it shouldn't matter since the 12 records in my GridColumns table are in order, and numbered in order. In other words, Columns[1] should be in visible spot #1 and Columns[12] should be in visible spot 12.

Here's the strange behavior -
1. When I run this against the "other" table it adds the columns, completes the instantiation of the form class and generally works correctly.

2. When I run this against the "main" table it does several very unexpected things:

2a. When instatiating the form for the first time it starts the SCAN on GridColumns record #1, adds the column, assigns the ColumnName, assigns the ControlSource, and then skips to GridColumns record #7 and of course tries to assign the ReadOnly to item #7 in the Columns collection, which, of course doesn't exist yet.

2b. When instantiating the form for the second time (after having instantiated for the "other" table first) the record pointer for the GridColumns table is on #12 where it was left after the columns were added to the grid the previous time. It tries to start the SCAN on record #12, runs into trying to change properties for Columns[12] and errors.

Questions:
What is making SCAN skip to record #7 in case 2a?

Does SCAN always start at the top if there are no FOR or WHILE conditions? If so, why does the SCAN not start at the top in 2b? Is there a rule, or do I always need GO TOP to be sure? In my experiments in a separate program, SCAN starts at the top even after I position the record pointer somewhere else first.


I have also re-written this a couple of different ways, including assigning the properties in a different order but I keep getting a SKIP after assigning the CONTROLSOURCE.


FUNCTION libAddGridColumns
    LPARAMETERS poMyGrid, pcTableName

    *!* Add columns to the grid based on table GridColumns
    WITH poMyGrid

        LOCAL lnOldSelect
        lnOldSelect = SELECT()
        SELECT GridColumns
        SCAN
            .ADDCOLUMN(GridColumns.ColumnNo)
            .COLUMNS(GridColumns.ColumnNo).Header1.CAPTION = ;
                GridColumns.ColumnName
            .COLUMNS(GridColumns.ColumnNo).CONTROLSOURCE = ;
                (pcTableName + [.] + ALLT(GridColumns.GridColumn))
            .COLUMNS(GridColumns.ColumnNo).READONLY = .T.
        ENDSCAN
        SELECT (lnOldSelect)

    ENDWITH

ENDFUNC
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform