Some things just annoy me and I think it should annoy my users. This doesn’t, but it’s annoying me.
I have a browse B that is dependent on browse A (standard ABC BrowseClass). When I make a selection in Browse A, the Browse B list populates properly, sorts properly, but about half the time, the last line in the Browse B list is selected instead of the first line. I could spend an hour or two trying to determine what the problem is, but it has to be something simple. What am I missing?
You can give this a try. I wrote it more than 23 years ago 
Used it quite a bit back when I used appgen.
jsbrowsec55.zip (2.2 KB)
Here’s the readme:
Real Parent/Child Listboxes for ABC.
Currently in ABC, there is no built-in way to relate a
particular “Parent” browse with its “Child” browse(s).
When a parent browse is scrolled, the child browse does
change the displayed records, but instead of resetting
selector bar to the top, it tries to find the “closest”
to the previously selected record. This behavior often
might be desirable in some cases, but when it is a child
browse, it should be re-set (in my opinion).
This enclosed derivation of the ABC BrowseClass class
allows a parent browse to keep track of it’s children
so that they can be properly reset upon the scrolling
of the parent browse. It also handles the enabling/disabling
of the child browse’s INSERT button if there are no records
in the parent browse.
!Installation-------------------------------------------
!Implementation-----------------------------------------
For a “PARENT” browse, uncheck “Use Default ABC Browse” in the
browse class properties, and set the class to “JSBrowseClass”
In the embeditor, after the browses initialize, put this:
YourParentBrowse.AddItem(AChildBrowse)
YourParentBrowse.AddItem(AnotherChildBrowseIfYouHaveOne,0)!Pass a zero like this if you don’t want the child browse to be disabled if there are no records in the parent browse.
YourParentBrowse.AddItem(YetAnotherChildBrowseIfYouHaveOne)
!Add more if you need
!That’s It-----------------------------------------------
Thanks, Jeff! It’s comforting to know that it’s a common problem and that I’m not a complete idiot. But I am looking for a easy peasy solution. Something like clear the file record and do a ResetFromFile method call somewhere.
If you read the code, you can see what it does on line 56.
But there are things you need to keep track of, which this class does. It’s much easier to just do what the notes say than fart around with this stupid issue for days, like I did.
But I’d love to see a one liner and/or property that someone uses.
A 23 year old recognized problem in ABC that SV hasn’t manage to fix even with an available public solution?
Not sure how you’re getting there from here. Maybe nobody asked them for it.
Oh, that could well be the case. Nevertheless, it is an example of a problem that has repeatedly come up over the years and a general fix, most likely welcomed by developers using ABC, just never happened. I haven’t any doubt the same is true for several other ABC problems as well. No person to blame, just an observation regarding a flawed process.
Thanks for the valuable and positive input.
In Event:NewSelection for the Parent browse…
IF NotFirstTime
FREE(Queue:ChildBrowse)
ELSE
NotFirstTime = TRUE
END
I think it was Jim Kane who suggested this solution last century?
Can probably be made a one-liner if you can find the right embed to FREE(Queue:ChildBrowse), I couldn’t after a quickish look.
I cobbled together Jeff Slarge and your solutions into the following code. Jeff’s code “on line 56” worked, but not the first time through. Here’s my Easy Peasy solution. I don’t like the idea of using the static variable, though.
IncomingTextsBrws.TakeNewSelection PROCEDURE
FirstTime Byte(1),static
CODE
IF FirstTime THEN
FirstTime = False
ELSE
EmployeeTextBrws.ListQueue.Free
EmployeeTextBrws.Reset()
end
PARENT.TakeNewSelection
if you use a static like that it is best to make it threaded:
FirstTime Byte(1),static,thread
Using it from C5.5 to C11!!
Helps a lot!
Okay, perhaps a better rephrasing of my original question and worthy of a discussion elsewhere in order to actually be valuable & positive. How do simple fixes, such as yours or whatever comes from this thread, to long standing ABC problems get incorporated into the shipping classes? It seems wrong that a widely recognized problem from 23 years ago is still around.
It’s not quite working right. If you click on a line in the parent browse, it works. If you click on the same line again, the child browse empties and doesn’t reload. If you double-click, the same thing happens. Hmmmmm. 
Welcome to the “farting around for days” that I spoke of.
I forget exactly what was going on when I wrote it, but notice that my class is not using TakeNewSelection. For whatever reason, I had determined that keeping track of the ViewPosition was the best way to know if we should free the queue. This was done in the UpdateWindow method, after the parent call.
So maybe if you just declare a Save:ViewPosition, you can do something like my UpdateWindow code, without the extra stuff.
After a bit of trepidation, I went with Jeff’s original solution. It works great! Thanks, Jeff. I got tired of fartin around. 
Greetings,
How would one implement this non-fartin method on a DropList?
Most of the time the LAST DATE is selected, which is at bottom of the Browse.
The user has to navigate back to the top.
In the DropList, in TakeNewSelection, or EVENT:Selected (after parent call) try:
YourBrowseLabel.Free
YourBrowseLabel.Reset