Listbox Click event (1 Viewer)

[kirkm]

Can how a listbox is populated effect it's click event?
To my surprise clicking in my listbox does NOT select the row clicked, as expected
Instead row 1 acquires a dotted line and clicking anywhere else has no effect.
Also the list box click event does not fire. I have set Allow Value List Edits to No and can't see any other property settings that might be the cause.
If I copy another listbox onto the Form and fill it with the Wizard, that works fine.

 

[theDBguy]

Compare the properties between your listbox and the one the Wizard created to see if anything doesn't match.

 

[MajP]

You can cause that behavior if the control is bound to an non-editable field/record

 

[kirkm]

Thanks Maj. I'll go back to VBA, was trying to use the Access Bound type stuff (if you know what I mean) and didn't have a bloody clue how to, so it was trial and (mostly) error. Until (days later) I get it working to find you can't click on it. Which was the whole reason for doing it!
DBGuy I did try yhat... short of printing them all out... couldn;tr see anything that different.

 

[MajP]

Thanks Maj. I'll go back to VBA, was trying to use the Access Bound type stuff (if you know what I mean) and didn't have a bloody clue how to, so it was trial and (mostly) error. Until (days later) I get it working to find you can't click on it. Which was the whole reason for doing it!
DBGuy I did try yhat... short of printing them all out... couldn;tr see anything that different.

To be clear you most certainly can have a bound listbox but it has to be bound to an editable record and control. Normally that is no problem. I am only guessing that is the issue. If it is bound when you click on it look at the status bar at the bottom you should hear a beep and see "The control cannot be edited ...". Can you explain what you want to do? Control source of the listbox and recordsource of the form?

 

[kirkm]

How much detail should I go into ? I had an issue with images causing a bad flicker on the screen and someone here gave me an example db that user a control source and added some fields into a query; instead of my VBA in the Current even. , It was perfect, no flicker anymore. But as well as these images there's a couple of listboxes and populating them also caused this flicker. So I was attempting to copy their method to see if that similarly got rid of it. It hasn't and the listbox can't be clicked in. It would be worth knowing why. Explaing the mechanics of this would be difficult. So I'll create a demo and upload it, if you'd like to take a look.

 

[MajP]

That will help if you can. Without seeing it we only would be guessing at the cause.

 

[Uncle Gizmo]

Also the list box click event does not fire

This is often the case when you copy and paste a control from one place to another, you can lose contact with its underlying VBA procedure.

So first question, have you copied and pasted the control from one place to another?

 

[Pat Hartman]

Thanks Maj. I'll go back to VBA, was trying to use the Access Bound type stuff (if you know what I mean) and didn't have a bloody clue how to, so it was trial and (mostly) error.

Bound forms just work. That is so that even someone who knows nothing about anything can create them. Strangely, it is only people who know how to code in a different environment that have trouble with bound forms. Probably because they expect them to work the way their last platform worked and that probably won't be true.

1. Bind the RowSource of the combo to a table or a query. You can build one with .AddItem but why? Can you really not select the data you want using a query?
2. Bind the form to a table or a query. The table or the query MUST be updateable. If it isn't, combos won't be able to select anything since the field it is bound to cannot be updated.

Start with the basic stuff until you understand how forms work.

and added some fields into a query; instead of my VBA in the Current even.

This is part of understanding how Access works. People who know how to write code frequently just jump in with code to solve a problem. Don't do it. Code should be your last option. I came to Access after more than 25 years in the field so I'd written my million lines of code and didn't need the practice. Find your solutions in this order:
1. queries (always faster than DAO/ADO loops BTW)
2. property settings
3. VBA functions
4. VBA

You'll still write plenty of code but it won't be code to control the environment. It will be code to implement the business rules.

The key to success with Access is to let Access be Access. Learn how to control bound forms by using the various form level events. There may be some obscure situation that you can't control with form and control events but I haven't run into any. The single most important event when working with bound forms is the FORM's BeforeUpdate event. Think of this as the flapper at the bottom of a funnel. If the funnel is open, the record gets saved. If the flapper is closed, the record does not get saved. Once you understand this, you can then have complete control over whether or not a record gets saved. Put all the validation code you want in dozens of events call it from everywhere but if it isn't in this event (or called from this event) you'll have holes as big as the grand canyon and bad data will be saved regardless of how many warning messages you display.

 

[kirkm]

Certainly with VBA I have a vague idea what I'm doing.. the other stuff drives me batty. Sometimes I'll fluke it or get advice I can implement.
I persevere as Access is so good once it's nailed down. I follow what you've said Pat, but it ain't plain sailing and those tutorials that spout on about Cunstomers and Orders are never anything I can relate to, Ce's la vi! Uncle G. no the control wasn't copied/pasted.