Combobox not populated with array 2

[SitesMasstec]

Hello colleagues!

I am trying to put in a Combobox the data from an array.

These are the data from the array I am using (just to be sure that the array has these data; the similar code is in the procedure Init in the Form):



This is the Form:


As you can see, the data from the array are not presented in the Combobox.

This is the code in the procedure AddItem in the Combobox:

With This
    FOR I=1 TO 3  && QtdeNomes
       .AddItem(NOMES(I,1),NOMES(I,2))
    NEXT I
    .ListIndex=1
ENDWITH

Thank you.

 

[Chriss Miller]

I don't find it, but I think I once even told you you could use the combox list as no matter what rowsourcetypes you use the data always ends up in the comboboxes own list anyway, no matter if you bind to a cursor, dbf, array or whatever else. And that was at a case where you struggled using cursors as they have their benefits but still you need to take care for some details which you didn't. For example you can't bind two or more comboboxes (or also listboxes) to the same cursor without the usually beneficial sideeffect of selecting an item also activating the corresponding record tilts the independency of two or more comboboxes. So putting everything into the list array by means of using additem is a safe way to handle the combobox no matter what. Now you simply struggle with having more than one column. It's not hard to lookup the help and read a bit about things. Anyway, Tamar has told the major information here. You may try to go back to cursor, but be aware every combobox should have its exclusive data soruce or you get cross references you don't want. The forms are lazy with refreshing, so when you make the mistake I think you made in the past and use one cursor for multiple combboxes and select in one combobx, it seems on that combobx changes the selected item, as the other comboboxes display only refresh when you activate them by clicking on them or tabbing to them.

It's your choice anyway, but you have to begin to get a much better comprehension of how things work, you don't improve the way you don't solve problems yourself and don't even try to find out why something doesn't work as you assume. First step to see is to realize often the error is not a bug but you using things wrong. Invest time in learning.

 

[mjcmkrsr]

...

and the same example taking into account Chriss's suggestions

PUBLIC go_Form

go_Form=CREATEOBJECT("clsForm")
go_Form.Visible = .T.
go_Form.Show()

READ Events


CLOSE ALL
CLEAR ALL

************

DEFINE CLASS clsForm as Form

    AutoCenter = .T.
    Width = 420
    MinWidth = 420
    MaxWidth = 420
    Height = 360
    MinHeight = 360
    MaxHeight = 360
    ShowTips = .T.
    
    
    ADD OBJECT lblLabel as Label WITH Top = 6, Left = 6, Autosize = .T., ;
                Caption = "Name", Anchor = 3

    ADD OBJECT txtName as TextBox WITH Top = 30, Left = 258, Width = 90, Height = 24, ReadOnly = .T., Anchor = 3, ;
        DisabledBackColor = RGB(250, 250, 250), ToolTipText = "Name"

    ADD OBJECT txtNumber as TextBox WITH Top = 60, Left = 258, Width = 90, Height = 24, ReadOnly = .T., Anchor = 3, ;
        Alignment = 1, DisabledBackColor = RGB(250, 250, 250), ToolTipText = "ID"                                   
    
    ADD OBJECT txtGender as TextBox WITH Top = 90, Left = 258, Width = 90, Height = 24, ReadOnly = .T., Anchor = 3, ;
        DisabledBackColor = RGB(250, 250, 250), ToolTipText = "Gender"

    ADD OBJECT txtHeight as TextBox WITH Top = 120, Left = 258, Width = 90, Height = 24, ReadOnly = .T., Anchor = 3, ;
        DisabledBackColor = RGB(250, 250, 250), Alignment = 1, ToolTipText = "Height"

    ADD OBJECT cboBox as ComboBox WITH Top = 30, Left = 6, Width = 240, Height = 24, ;
            RowSourceType = 2, RowSource = "csrEmployees", Style = 2, Sorted = .T., ;
            Anchor = 3, ToolTipText = "Type name or click down arrow"
            
        PROCEDURE cboBox.Init()
            This.Value = csrEmployees.cName
            
            WITH ThisForm
                .txtName.Value = csrEmployees.cName
                .txtNumber.Value = csrEmployees.iNumber
                .txtGender.Value = csrEmployees.cGender
                .txtHeight.Value = csrEmployees.nHeight
            ENDWITH
            
            This.SetFocus()                 

        ENDPROC
        
*!*    START of procedure that feeds the TextBoxes with their values

        PROCEDURE cboBox.Click()
        
            WITH ThisForm
                .txtName.Value = csrEmployees.cName
                .txtNumber.Value = csrEmployees.iNumber
                .txtGender.Value = csrEmployees.cGender
                .txtHeight.Value = csrEmployees.nHeight
            ENDWITH
        
        ENDPROC

*!*    END of the feeding procedure
    
        PROCEDURE cboBox.InterActiveChange()
        
            This.Click()
            
        ENDPROC

    PROCEDURE Load()
        CREATE CURSOR csrNames (cName c(8),iNumber I, cGender c(1), nHeight N(5,2))
        
        INSERT INTO csrNames VALUES ('Karl', 123, 'M', 1.75)
        INSERT INTO csrNames VALUES ('Robert', 124, 'M', 1.80)
        INSERT INTO csrNames VALUES ('Luisa', 125, 'F', 1.70)
        INSERT INTO csrNames VALUES ('Megan', 126, 'F', 1.68)
        INSERT INTO csrNames VALUES ('Georges', 127, 'M', 1.82)
        INSERT INTO csrNames VALUES ('Kim', 128, 'F', 1.65)
        INSERT INTO csrNames VALUES ('Paul', 129, 'M', 1.85)
        INSERT INTO csrNames VALUES ('Corinne', 130, 'F', 1.54)
        INSERT INTO csrNames VALUES ('Elisa', 131, 'F', 1.68)
        INSERT INTO csrNames VALUES ('John', 132, 'M', 1.72)
        INSERT INTO csrNames VALUES ('Frank', 133, 'M', 1.90)
        
        SELECT * FROM csrNames ORDER BY 1 INTO CURSOR csrEmployees       
    ENDPROC

    PROCEDURE Destroy()
        USE
        ThisForm.Release
        CLEAR Events
    
    ENDPROC
ENDDEFINE

************

hth

MarK

 

[Chriss Miller]

That's good. If you, SitesMasstec, run that last demo from MarK, you'll be able to verify what I said. that it's eventually always the list that's holding the data a combobox shows.

If you run the example and then suspend with the menu item Program->Suspend, the form will still run and you can still use it. Now you can verify that though the rowsourcetype is alias, meaning it's a workarea. The combobox still has its list populated, though there was no use of additem or addlistitem:

oCombo = _screen.forms(1).cboBox
? oCombo.List(1,1), ? oCombo.List(1,2),? oCombo.List(1,3),? oCombo.List(1,3)

This will display the first record field1-4. Because the combobox always reads data into its list property.
That also works when using MarKs first example with the gaEmployees array. So in the end the combobox items always end up in its list.

That's the reasoning I must have given, it doesn't matter how you populate the combobox, its items always end up in the list of it. And so you don't spare RAM with one or the other approach, you can always work on the list with array indexes for row and column numbers. It's simpler in several ways to use cursors or dbfs, in short any workarea, but it comes with the effect you can't use one cursor for several comboboxes (or listboxes, or grids when you consider other controls) as a workarea always has one concept that arrays don't have: The currently active/selected record. The record pointer.

That's why using additem/addlistitem (and understanding the difference and how to use them to poplulate a 2d list (with several columns) vs a simple 1d list (only 1 column, one value for each item) is the only thing you need to know and not worry about anything else, advanced, when you don't get the implications and effect the use of a workarea has for grids, listboxes and comboboxes: That using the same workarea for several of them you get the side effect of making a selection in one of them also changing the active item in others.

With an array or feeding the list with additem/addlistitem you can, in fact, use one array to feed multiple comboboxes and let each have their individual selected item, as an array doesn't have the same concept a workarea has: There is no current array row, no row pointer in an array, you always address an array with index numbers for row and column or a single number for item number in a 1d array.

I think in the thread I don't find anymore, I gave up teaching you this and I fear this goes lost down the road, too. I think you wanted to stick to populating the way you know it with additem, because then also any other code using the list with index numbers wouldn't need to change. Well, using a workarea, you can work with much less code overall, you just need to ensure you're creating a cursor per control. There's one thing that's less fine with cursors in a listbox with multiselect, and it's based on the same concept of the record pointer: There is only one record pointer, not multiple. There is not even one array row pointer, but it's less confusing to find out which list items of a multiselect listbox are selected using an array instead of a cursor. It's possible with cursors, too, anyway.

If you ask me for the best way to work with in VFP, arrays or cursors, for data it's definitely cursors, or better said workareas. That's the core thing that distinguishes VFP from any other programming environments. Not even the DBF file, how you store data is mainly the storage engine, it doesn't make VFP unique from any other database just because there's a file (or set of files) per table. That's also that way in MySQL using some storage engines like ISAM. You also don't just have the same concept as a recordset with a workarea. It's how they work and ingteract with the VFP controls that makes it an overall concept.

You have arrays in any other programming language, too, and many more concepts like lists, sets, dictionaries (that's not only for words). You have controls in any other programming language offering a GUI (so anything that's not just purely a database server). You often even have more variety, like a treeview VFP lacks. That's not why you use VFP, you use it to use workareas and controls easily bound to workareas. Sure, it's an oversimplification of what's making VFP good, but if you don't make use of that, the question is why you're even here.