Full Version: Search a list box
UtterAccess Discussion Forums > Microsoft® Access > Access Forms
patrickrac83
I was wondering how I would go about searching a list box which is based off a value list?
Jack Cowley
I never ever use a value list. Create a table and use the table, or a query based on the table, as the Row Source for your list box. Now you can easily search the table, or query, the list box is based on.

hth,
Jack
ChrisO
I’m not sure if anything has changed since this thread.

Are there further requirements?

Regards,
Chris.
patrickrac83
i never got an answer on the first thread, the guy who was responding didn't know what he was talking about. I don't want to make a tabl;e because I don't want to have to store the data in a table. User will ad to the list by inputing to a text box. Sometimes htey are stupid and run the original copy on the server, and multiple of them will do it, even though I tell them to copy it to their local m,achines. If two people open the same copy, they will be trying to use the same tabble.
ChrisO
“i never got an answer on the first thread”
Actually no, you got 9 replies on the first thread. They may not have been the answer you require but you did get them.

“the guy who was responding didn't know what he was talking about”
Maybe, but he may also not have known what you were talking about.

You had 5 different people respond to that thread, not one guy (singular).

If I’m being overly semantic then that’s because we are in that game.
(To me, half the problem in solving the issue is in the specification of that issue.)

So, I ask the question again; Are there further requirements?

Regards,
Chris.
Jack Cowley
"I don't want to make a table because I don't want to store the data." That is what tables are for and the data is now being 'stored' in the Value List! If you set up your db on your server correctly you will not have a conflict between user accessing you database.... If your users have free reign with your server then there isn't much you can do if they mess it or your database up...

Just my views...

Jack
patrickrac83
I am sorry, I did not notice the further postings after dealing with the first person on my original pots, I will look into those further. To answer the question as to why I don't want to use a table, as I said , the client app (FE) is ocated on a sever, people are supposed to COPY it to their local machine and run that. But as users go, they are as clever as can be an inevitably a few create shortcuts instead. That means I would have several people trying to use the same table in teh same FE. If there is a way to stop them from doing that, I would love to hear it, otherwise, I wanted to make it so they simplywouldn't matter by storign the data as a value list on the form. This requires me to be able to search that value list do do the things I need to do with the data.
Jack Cowley
Hmmm. As a developer you can only do so much and after that you can't be responsible, in my opinion, for what the users try to do with your application. I don't like value list because their values can change and if they do you have to redistribute new front ends to everyone and that is why I suggested a table.

I would not put the front end on the server and if people need a copy of the program they can come to you to get it. No FE's available, no problem with people trying to use the same FE at the same time....

Just my 3 cents worth...

Jack
norie
What would be the problem with multiple users using the same table?

Aren't you just using it to store values?

The users won't be altering it, will they?
Jack Cowley
As I understand the problem there is a copy of the front end on the server and more than one person at a time tries to use the FE at the same time causing conflicts. If the FE's are on each users machine there would not be the conflict.

Jack
R. Hicks
Jack is absolutely correct in what he is saying ...
The FE should not be shared .. each user needs their own seperate FE file.

RDH
Jack Cowley
Hiya Ricky!!!

How the heck are you? Still in the brick making business? Any horse steaks left in the freezer? shocked.gif

Jack
patrickrac83
Problem with same table ios they are changing it, basically the list contains a list of items whch an action will be taken with. If multiple user uinput to the same table, it will mesh multiple inputs, which is bad. I am not sure what I can do about the FE beeing on the server, i am only allowed to decree so much to the company. Is there no way to searcbh a list box?
Jack Cowley
At this point I do not know what you can do. We have given you suggestions and none, apparently, will work for you. I do not see how 'reading' the list box is going to make any difference since the users seem to have as much control over the database and its data as the devolper does...

I'm sorry that we have not been able to help you find a solution to your problem...

Jack
ChrisO
“Is there no way to searcbh a list box? “

Sure…

CODE
Private Sub txtMyTextBox_BeforeUpdate(ByRef intCancel As Integer)
    Dim blnFound As Boolean
    Dim intIndex As Integer
    Dim vntList  As Variant
    
    Const conDelimiter As String = ";"
    
    If Len(Me.txtMyTextBox.Text) Then
        vntList = Split(Me.lstMyListBox.RowSource, conDelimiter, -1, vbTextCompare)
        For intIndex = LBound(vntList) To UBound(vntList)
            If Me.txtMyTextBox.Text = vntList(intIndex) Then
                MsgBox Me.lstMyListBox.RowSource & vbNewLine & vbNewLine & _
                       "Value " & Me.txtMyTextBox.Text & " already in List."
                
                blnFound = True
                intCancel = True
                Exit For
            End If
        Next intIndex
        
        If (Not blnFound) Then
            Me.lstMyListBox.RowSource = Me.lstMyListBox.RowSource & Me.txtMyTextBox.Text & conDelimiter
        End If
    End If
    
End Sub

That was from the first thread, upon which you have made no comment.

Maybe it’s about time you upload a demo of the problem???

Regards again,
Chris.
patrickrac83
Thankyou for your help, it has all come together and is working now.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.