Well, this clarifies your position / code, but also makes my request
even stronger.
As you say, CheckBrowseMode() is a useful method, since "will perform
different actions under different conditions". It's "dataset aware",
we could say.
For parameters, you had to build a "parallel" design just because you
don't have a Dataset event ("entry point") where you could safely put
your parameter assignment code.
What I'm asking is include this useful event in IBO standard
components, and I'm now sure you would like it too.
In addition, the "refresh" use is usual:
a) get the server updated data with the same parameters
b) get new data with updated parameters
what's the behaviour with your code? Only in b) the invalidation is
necessary. In the new "OnParamAssign" event, IBO could check if params
have been changed and invalidate only if necessary... (I'm not expert
in deep IBO/FB working, so maybe I'm telling silly things).
In addition, in the b) situation, when you use OnParamSQL event, you
have to invalidate the query to make this event work. All this "low
level" IBO is confusing for beginners / intermediate, and often is
error prone (you lately introduce OnParamSQL, and all your "refresh"
becomes useless). So, for b), I asked for a "strong refresh" that
could do a lot of things for optimising resources and saving time, like:
a) check in the new "OnParamAssign" what I wrote above
b) check if the OnParamSQL is nil or some code is set, and invalidate
only in the latter case

These (of course) seem to be interesting additions to IBO, and I know
that all the above can be done in code, but I would like to know if
you can do it in a better way or not.
IBO is a great time saver in a lot of situations, but why not push it
benefits a little further?
What disadvantages can you see in the above?
thanks a lot
Marco Menardi
p.s. apologise for my "grammar obfuscated english"

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 10:42 AM 1/03/2003 +0000, you wrote:
> >Ok, I will riassume the problem for your and other's convenience:
> >a) Helen often suggested the BeforeOpen as the ideal place where
> >assign centrally parameters to queries
> >b) she said that not only open, but also Refresh will re-opne the
> >query, so the parameters are used also in refresh
> >c) I've always used BeforeOpen as she suggested, and was very happy
> >with this design
> >d) I've discovered that open is performed on refresh ONLY if
> >"RefreshAction" is set to raOpen. Yes, it's correct, but this means
> >that I can't use BeforeOpen and code like "if Active then refresh else
> >open". To be sure BeforeOpen is fired, I always have to close/open the
> >query
> >e) since I've found that having a central place for parameter
> >assignment is very convenient and better for code manteniance (you
> >have only one place where to look), and since BeforeOpen seems not to
> >be the right one, I was asking 1) is there anoter event to use? 2) if
> >not, what about adding one? or provide a "strong refresh" method that,
> >whatever the RefreshAction is, closes and opens the query?
>
> Marco,
> I was puzzling over Jason's reply to my question, until I realised
that we
> were not at cross-purposes after all...
>
> He advised not to assign parameter values in events at all but to
put them
> "in code somewhere". This seemed unsatisfactory to me until I realised
> that what he was talking about was just what I do anyway - at least, I
> think it was was what he was talking about <g>.
>
> I will always have a method called AssignParams, which takes as its
> arguments a TIB_Dataset and a stringlist of parameter names. So, in
the
> events, I don't do the actual assignments - I just create (or re-use) a
> TStringList and pass on the Dataset argument (of the event, or of
another
> dataset that AssignParams has to operate on) along with this stringlist
> loaded with the parameter names that apply to that particular dataset.
>
> This gives you the flexiblility to call your AssignParams method for
any
> dataset from whichever event is appropriate. It could well be an
event on
> another dataset, or even on a control. So - all I need to be concerned
> about is setting up and calling AssignParams - I don't have to be
concerned
> about the timing. AssignParams itself will call other methods
> conditionally, if it's necessary to have something happen under some
> conditions (Dataset, sources of parameter values), in much the way
that a
> call to CheckBrowseMode() will perform different actions under
different
> conditions.
>
> I think you are misquoting me when you say that I say always use
> BeforeOpen. I'm sure I often do, in response to a question about a
> specific situation. But - looking at your problem of Refresh where
raOpen
> isn't the refreshaction, you can call your AssignParams method on *any*
> event that is timely. This will invalidate the Params[] array (an
IB_Row
> object) and IBO will revalidate it before it does whatever it has to do
> about the dataset - refresh, open, whatever.
>
> Does this help to clarify the picture at all?
>
> regards,
> Helen