>no offense but... double ick.

Double Ick!?!?!?! Geee... three icks in a matter of hours... I'm definitely doing well with you, Roxanne... ;-)

>>With the approach I've been using, It's the responsibility of the CALLING entity (be it a form or another object) to set things up before asking the bizobj to requery.
>
>Alex that's not cool at all, the bizobj should adhere to the concept of encapsalation and take care of itself internally. Plus your bizobj is your thinker object... that's where you want all the logic and data element handling built in at in order to get the most reuse possible out of it.

I like the idea (having the bizobj refer to its own properties to get the view parameters from), but I still fail to see what's so wrong with not hardwiring this behaviour and allowing the calling entity to decide WHERE those values will come from at run time.

If I do what you're saying, and stick the AddViewParameter in the bizobj's postinithook(), I still have to add a property to the bizobj (to hold the view parameter's value) and my calling form must know about this property in order to set up the bizobj properly.

With my approach, instead, all ... ahh, nevermind, in my world I still need to know the name of the view parameter when I issue the AddViewParameter() from the form.

As I mentioned in profox, "Yes dear, you're absolutely right". Especially because I can indeed picture myself six months from now going after the views looking for the parameter's names when I could instead have a property in the bizobj with it's own little explanation at the bottom and everything and make my life really simple.

Thanks for the icking! ;-)

Alex