combobox Text Displays wrong information

I have a combobox issue that I am unable to figure out. There are three comboboxes, each of which serve an identical purpose, and each of which is populated from a different table.

The three comboboxes are bound to the tables as can be seen below. Now as far as I know these are the only places where the combobox is touched by the code.
Each of the comboboxes are bound to each of three tables. The only table properties I touch in the code are the enabled, and tabStop properties.

The issue is the text showing in the first combobox. What should be displayed and is bound to the combobox text property is the type of document. The data displayed in the first combobox is the data from another column in the table.

There are no errors and I have been unable to think of what is going on. I am sure that there is a code mistake somewhere, but I have no idea how to find it. I have pretty much used up everything I know to look for.

Attachment 187506

Code:

---

    Public Sub GetTypeComboBox()
        cboType.Items.Clear()
        MasterBase.MasterBaseQuery("SELECT colType From lkpDoc")
        If RecordCount > 0 Then
            For Each r As DataRow In MasterBase.ListDataSet.Tables(0).Rows
                cboType.Items.Add(r("colType"))
            Next
        End If
    End Sub

---

Code:

---

    Public Sub GetDeptComboBox()
        cboOwner.Items.Clear()
        MasterBase.MasterBaseQuery("SELECT colDept From lkpDept")
        If RecordCount > 0 Then
            For Each r As DataRow In MasterBase.ListDataSet.Tables(0).Rows
                cboOwner.Items.Add(r("colDept"))
            Next
        End If
    End Sub

---

Code:

---

    Public Sub GetWhereComboBox()
        cboWhere.Items.Clear()
        MasterBase.MasterBaseQuery("SELECT colWhere From lkpWhere")
        If RecordCount > 0 Then
            For Each r As DataRow In MasterBase.ListDataSet.Tables(0).Rows
                cboWhere.Items.Add(r("colWhere"))
            Next
        End If
    End Sub

---

Code:

---

        cboType.DataBindings.Add("Text", MasterBase.listTable, "colType")
        cboOwner.DataBindings.Add("Text", MasterBase.listTable, "colOwner")
        cboWhere.DataBindings.Add("Text", MasterBase.listTable, "colWhere")

---

Code:

---

    Private Function GetDocument(ByVal SystemID As String) As Object
        'Add Parameters
        MasterBase.AddParam("@recno", SystemID)
#Region "Establish Connection and execute Query"
        Try
            Dim RecordCount = 0
            MasterBase.Exception = ""
            MyError = "Failed to find the selected document."
            MasterBase.MasterBaseQuery("SELECT colSystemID,colRev,colName,colDetail,colFilePath,colChangePath " &
                                      "colType,colOwner,colWhere,colActive,colObsolete " &
                                      "FROM sitDocMaster " &
                                      "WHERE colSystemID = @recno")
            MyRev = MasterBase.listTable.Rows(0).Item(1).ToString
            MyDocument = MasterBase.listTable.Rows(0).Item(0).ToString + "." + MasterBase.listTable.Rows(0).Item(1).ToString + "." + "Draft"
        Catch ex As Exception
            MasterBase.Exception = ex.Message
            MsgBox(ex.Message + vbCrLf + MyError)
            Me.Close()
        End Try
        Return SystemID
#End Region
    End Function

---

Quote:

---

Originally Posted by gwboolean

Now as far as I know these are the only places where the combobox is touched by the code.

---

The first thing you should do is view the contents of the database directly and verify that the values you are expecting to reside in specific columns are in place.

The second thing you should do is search any and all of your code files for any other code that accesses "cboType" and verify that nowhere else are you modifying the values inside of it.

The third thing you should do is update this thread with the results of the first and second things you should do.

Good luck.

Edit to add:

A fourth thing you could do is to add a brand new combobox to the form, use the identical code that you are currently using to populate the "misbehaving" combobox (modifying the new code to add items to the new combobox, of course), and see what the results of that test are.

I have done all 4 items listed prior to posting the thread. I even tried different combobox using a different name for the combobox and made sure that there was no weird record in the table. One possibility that I hesitate to mention, is that this form started with the entire contents of the form, except for the toolbar, copied/pasted from another form from another project.

Having said all of that, there must be something overwriting that text property somewhere in the code, and it is overwriting it with the value from another field in the table. I think that before I tear down the form and start again I will try looking for extraneous cboTypes in the code again.

Quote:

---

Originally Posted by gwboolean

I have done all 4 items listed prior to posting the thread. I even tried different combobox using a different name for the combobox and made sure that there was no weird record in the table. One possibility that I hesitate to mention, is that this form started with the entire contents of the form, except for the toolbar, copied/pasted from another form from another project.

Having said all of that, there must be something overwriting that text property somewhere in the code, and it is overwriting it with the value from another field in the table. I think that before I tear down the form and start again I will try looking for extraneous cboTypes in the code again.

---

It shouldn't be that hard to find if it is there. Presumably you are using the "Search" functionality built in to Visual Studio, and not manually scanning through copious lines of code by eye...

That’s not the way to bind a ComboBox…

Dim dt as New DataTable ‘ prior to this, fill your DataTable with the appropriate data
ComboBox.DisplayMember = “a field name”
ComboBox.ValueMember = “an optional other field name”
ComboBox.DataSource = dt

Quote:

---

Originally Posted by .paul.

That’s not the way to bind a ComboBox…

Dim dt as New DataTable ‘ prior to this, fill your DataTable with the appropriate data
ComboBox.DisplayMember = “a field name”
ComboBox.ValueMember = “an optional other field name”
ComboBox.DataSource = dt

---

Unfortunately, the OP has made it clear in their other recent threads that this "MasterBase" approach - where they feed all of their queries in to one object, it does its thing, returns the appropriate data to some shared objects (clobbering whatever was in those shared objects from the last query), and they access those results and move on - is used by hundreds of methods in their code.

I get the impression that this code-base is possibly a years long work in progress, and far beyond the OP's ability (in terms of amount of code that would need to be changed) to rework in a more "standard" way. And, unfortunately, I'm convinced that their choice of "MasterBase"-ing everything is the root cause of their recent issues.

Quote:

---

Unfortunately, the OP has made it clear in their other recent threads that this "MasterBase" approach - where they feed all of their queries in to one object, it does its thing, returns the appropriate data to some shared objects (clobbering whatever was in those shared objects from the last query), and they access those results and move on - is used by hundreds of methods in their code.

---

OK, I get the idea that you believe that having a function or method that is located in a class/module and used by many different methods from many different locations is a bad thing and screws up processes. Now why is that so? What is a standard way?

I do not pretend to know much about VB coding processes, it has long been presented to me that doing that is both efficient and less problematic.

Quote:

---

It shouldn't be that hard to find if it is there.

---

I have been there several times and have even searched through all of the files in the whole project. There are no extraneous cboType anywhere.

I have noticed one other problem that occurs that might be related. Although I cannot see how. I have noticed that when loading data to a new record I am getting extraneous text added to the column. Extraneous being all of the text before C:\

I do not know why the extraneous text is there and am working to figure that out (If you can see it from what I have here that would be cool.) and eliminate that. The only relationship I can think of is that what is displayed from the text property of that combobox is the value from that particular field in the table, instead of the value from the field called from the query.

Quote:

---

System.Windows.Forms.Label, Text: C:\Development\FileCabinet\Change\CR100000048\

---

Code:

---

    Public Sub ReviseDoc()
        'Modifies a selected sitDocMaster record to the next AA revision and creates a document FilePath.
        MyRev = OORevision.Increment00Revision(MyRev, ChangeID).ToString
        docPath = GetDirectory(MyUser).ToString 'Creates article filepath
        'chgPath = chgRecord.lblFilePath.ToString
#Region "Establish Connection and execute query"
        MasterBase.AddParam("@rev", MyRev)
        MasterBase.AddParam("@active", False)
        MasterBase.AddParam("@dpath", docPath)
        MasterBase.AddParam("@path", chgRecord.lblFilePath.ToString)
        MasterBase.AddParam("@recno", SystemID)
        MasterBase.MasterBaseQuery("UPDATE sitDocMaster " &
                                  "SET colRev=@rev,colActive=@Active,colFilePath=@dpath,colChangePath=@path " &
                                  "WHERE colSystemID=@recno")
        If CheckException.HasException(True) Then Exit Sub
#End Region
    End Sub

---

Quote:

---

Originally Posted by gwboolean

Code:

---

        MasterBase.AddParam("@path", chgRecord.lblFilePath.ToString)

---

---

That should almost certainly be:

Code:

---

        MasterBase.AddParam("@path", chgRecord.lblFilePath.Text)

---

Edit to add for JMC's sanity:

It should actually be a variable as the second parameter to AddParam, since UI elements shouldn't be used to store/retrieve data.

Quote:

---

Originally Posted by gwboolean

OK, I get the idea that you believe that having a function or method that is located in a class/module and used by many different methods from many different locations is a bad thing and screws up processes. Now why is that so? What is a standard way?

---

Here's some reading for you.

https://learn.microsoft.com/en-us/vi...s-2022&tabs=vb

Quote:

---

That should almost certainly be:

---

It most certainly is. Sorry I missed that, but then I always miss a lot. I don't proof well. That took care of the extraneous text in the field.

I was hoping that it would deal with the combobox thing, but I knew that would be a stretch. Going to keep looking around for awhile, and then I think I might be better off just rebuilding the form and controls. It isn't a really big deal.

Quote:

---

Here's some reading for you.

---

I will take a look at your offer. If it isn't to heavy a lift for my limited capabilities, I will give it some study. Thanks.

Quote:

---

Originally Posted by gwboolean

I get the idea that you believe that having a function or method that is located in a class/module and used by many different methods from many different locations is a bad thing and screws up processes.

---

That's not the idea at all. A dedicated Data Access Layer is a good thing. The problem is that so many of them are poorly implemented. It's the implementation that is the issue in this case, not the principle. For instance, a well implemented DAL would not have a Shared property of type DataTable that contained the results of every query. It would have an instance method that returned a DataTable when called.

Quote:

---

That's not the idea at all.

---

I must be beginning to understand some of this stuff. I almost got everything you stated Jim. Although I do not quite get all of it, why is an instance method superior? I think that when you say a shared datatable you are referring to the fact that I build the datatable there and use it in other places, instead of building where and when it is needed (instance?). Is that correct?

Are you referencing the MasterBaseQuery() that was discussed in another posting?

I also am still using the dataset for comboboxes. In retrospect, I suppose that this could be related to the problem I am experiencing with the one combobox on the one form. I have not looked at that yet but will be getting on that.

Anyway, thanks for the information. I will see what I can do to understand all of this. and determine how I might do this better.

Code:

---

        Public Sub MasterBaseQuery(SelectQuery As String)
            RecordCount = 0
            Exception = ""
#Region "Connection"
            Try
                MasterBaseConnection.Open() 'Open connection
                ListCommand = New SqlCommand(SelectQuery, MasterBaseConnection) 'Database command
                Params.ForEach(Sub(p) ListCommand.Parameters.Add(p)) 'Load parameters into command
                Params.Clear() 'Clear parameters list
                listTable = New DataTable
                ListDataSet = New DataSet 'Dataset created and used only for table driven comboboxes
                ListAdapter = New SqlDataAdapter(ListCommand)
                RecordCount = ListAdapter.Fill(listTable)
                ListDataSet.Tables.Add(listTable) 'Dataset created and used only for setting table driven comboboxes
            Catch ex As Exception
                Exception = ex.Message
                MsgBox(ex.Message + vbLf + vbCrLf + MyError)
            Finally
                MyError = ""
                If MasterBaseConnection.State = ConnectionState.Open Then MasterBaseConnection.Close()
            End Try


#End Region
        End Sub

---

try and change this...

Code:

---

Public Sub GetWhereComboBox()
        cboWhere.Items.Clear()
        MasterBase.MasterBaseQuery("SELECT colWhere From lkpWhere")
        If RecordCount > 0 Then
            For Each r As DataRow In MasterBase.ListDataSet.Tables(0).Rows
                cboWhere.Items.Add(r("colWhere"))
            Next
        End If
    End Sub

---

to this in a Modul called modMainl...

Code:

---

' you must have a valid connection called Cn

 Public Sub FillComboBox(ByVal comboBox As ComboBox, _
                        ByVal SQL As String, _
                        ByVal valueMember As String, _
                        ByVal displayMember As String)
        Using sda As OleDbDataAdapter = New OleDbDataAdapter(SQL, Cn)
            Dim dt As New DataTable()
            sda.Fill(dt)
            comboBox.ValueMember = valueMember
            comboBox.DisplayMember = displayMember
            comboBox.DataSource = dt
        End Using
    End Sub

---

now you can use it like this on a Form

Code:

---

Public Class Form1

    Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load


        modMain.FillComboBox(ComboBox1, _
          "SELECT CategoryName,CategoryID FROM Categories ORDER BY CategoryName ASC", _
          "CategoryID", _
          "CategoryName")

    End Sub


    Private Sub ComboBox1_SelectedIndexChanged(sender As System.Object, e As System.EventArgs) Handles ComboBox1.SelectedIndexChanged
        Label1.Text = ComboBox1.SelectedValue
    End Sub
End Class

---

probably still not the best way if you want to use a DAL, but do you really need Project with DAL ?

Quote:

---

Originally Posted by gwboolean

OK, I get the idea that you believe that having a function or method that is located in a class/module and used by many different methods from many different locations is a bad thing and screws up processes. Now why is that so? What is a standard way?


I do not pretend to know much about VB coding processes, it has long been presented to me that doing that is both efficient and less problematic.

---

Having a reusable method that can be called from multiple places is a good idea, however it does require the method in question to be implemented with this in mind.

A typical approach would be to have the function return the data to the calling code, that way each caller gets a version of the data specific to the caller. If you call the function twice, then you return two pieces of data that are completely separate from each other.

IIRC your MasterBase approach is using global variables / Shared properties to manage the returned data - this means if you call it twice then the second execution effectively overwrites the data from the first execution. Using this kind of global data makes it incredibly difficult to maintain the function, often leading to hard to track down bugs due to this shared data being changed in unexpected ways / at unexpected times.

You could have implemented the Data Access functionality as a class, that way you could create a new instance of the class each time you need access to the database, each instance would have it's own connections etc. and therefore multiple instances wouldn't interfere with each other.

Have you tried lloading the combobox without using the MasterBaseQuery?

Use the same connectionstring.

Maybe even create a new form with a combobox with the same name. Then test.

Because there is nothing obviously wrong. But we also don't have the complete picture.

You say you checked what's actually in colType field in the lkDoc table.

You sure your looking at the right database?

Corrupt form???