>Hi Ed.
>
>>> Marcia, I tend to put this in the AfterRowColumnChange() of the grid, because in most cases, there's more than one textbox involved (eg qty, list price, discount), and changes in the status of a row often will affect the sum of the price (eg, I delete a row off an invoice.) <<
>
>Good point. As I mentioned, the response that I gave John was off the top of my head < s >.
>

I know; I'm not in any way criticizing (you should see some of my SWAGs), just pointing out things that are obvious to you, but might get overlooked by someone trying this for the first time. I'm personally responsible for one slick little demo of an invoice form with a subtotal box that worked fine as long as you didn't change the quantity, and of course, that's the first thing the prospective client tried when I sat the prospective client down in front of the demo and said "Go ahead, try it..."

That's one I'm not likely to forget.

>>> and frankly, I like ListBoxes, especially with MoverBars and multiple selects being simple. <<
>
>Check out the multi-select grid in chapter 6 of KiloFox < s >. You may find that to be a more user-friendly alternative to multi-select list boxes which IMHO are a real PITA.
>

I've seen it; a slick approach. I unfortunately really need ListBoxes (I'm close to writing one with exactly the behaviors I need as an ActiveX control.) Many of my apps involve route planning, so a re-arrangable list control, especially one that allowed easy block shifts (select three consecutive lines of a list and move them as a group within the list; select three discontinuous members, disallow movement of the group in the list, but permit other types of block operations (delete, drag to another list retaining their relative ordering, assign common properties) - stuff that is a recurrent theme in routing and packing applications that I seem to be writing.