[AccessD] Listbox Issue - Selected Property or ListIndex persisting after requery

LOL, you either like it or you don't. If you have in fact used classes and decided you don't like 
them then that is that.

As an OOP kinda guy it has always annoyed me that I cannot inherit a built-in control and add my own 
functionality and properties to them.  Wrappers kinda sorta give you that ability.  I use it to the max.

I started OOP with Turbo Pascal back in the late 80s.  When I came over to Access I gained events 
and lost OOP.  It was a shock trying to figure out how to do things that were so easy with Turbo 
Pascal.  I did not discover classes until Shamil turned me on to them, and even then it took awhile 
to wrap my mind around sinking events in them and so forth.  Once I did however my ability to do 
complex things in an OOP way was back.

I still sink object events in forms... where it is a "one off" kind of thing that will never be 
repeated.  If I end up doing it a second time that tells me that this is a candidate for a wrapper 
class.  I pretty much stop what I am doing, build a class to do that thing, and start using the 
class.  Once you do classes like that, creating a new class is trivial and using it becomes second 
nature.  It extends the wrapped object, gives me new methods and properties.  Nothing wrong with that.

I would never write the exact same function twice.  My programming education teaches me that is a 
no-no.  The code you are discussing is "writing the exact same function twice".  Except you have to 
modify that "exact same function" each and every time to make it work.  So now you have something 
that should be calling a function and passing a parameter.  Except that it has to ripple down the 
chain...  So now you have to have a bunch of functions calling the function passing in different 
parameters...

sub cboState_AfterUpdate()
begin
     cboCity.Requery
     cboHS.Requery
     cboClass.Requery
     cboPeople.Requery
end

sub cboCity_AfterUpdate()
begin
     cboHS.Requery
     cboClass.Requery
     cboPeople.Requery
end

sub cboHS_AfterUpdate()
begin
     cboClass.Requery
     cboPeople.Requery
end

sub cboClass_AfterUpdate()
begin
     cboPeople.Requery
end

NOW... add in a cboSportTeam which displays lists of people on each team for each year.  That is two 
more combos, one for the team (cboSportTeam dependent on cboClass) and another cboTeamPeople 
dependent on cboSportTeam.

The way I do it is add two more combo classes, one for each new combo.

then:

     clsCboClass .mDependentObj clsCboTeam
   clsCboTeam .mDependentObj clsCboTeamPeople

Again, I can simply read that cboTeam is dependent on cboClass and cboTeamPeople is dependent on 
cboTeam.

Obviously clsCboClass has now been passed TWO class pointers, one for the people and one for the 
teams.  When it is time for it to requery it simply requeries everything in its collection and 
voila, it is all figured out and handled.

Again, I really do this.  When I design any form with dependent objects, I sit in the form_Open 
event analyzing which objects are dependent on other objects and programming them there.  If the 
chain changes, new objects are added, objects are deleted, objects are moved etc. I simply program 
it using methods and properties in form_Open.  I am not searching down through my form code figuring 
out where I did that part, and what I have to modify.  I used to do it that way, so I know what is 
involved.

John W. Colby

Reality is what refuses to go away
when you do not believe in it

On 3/13/2014 9:58 AM, Bill Benson wrote:
> I guess IF you know which list box goes with each class but if you write
> code that takes care of that,  you may as well let Access give you the
> event handler (of the child) and trigger it by writing childlist.requery in
> the parent company's re query event; the way you propose you still need at
> least one line of code (probably 2 or more) declaring the variable, setting
> it equal to the class, then adding to the publicly declared collection for
> persistence, plus you've got the wrapper code.
>
> I dunno, guess I will take your word this is better,  more efficient,  or
> more readable/fun.  Having done both I take Access straightforward code in
> Access, although lots of people do like class midules.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com