At 02:37 PM 1/03/2003 +0000, you wrote:

>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.

No, it's not a "parallel design". It's a implementation-level method that
provides a generic, event-context-free handler for assigning values to
parameters from whatever source (variables, the Row property of another
dataset, a value in an edit-control, etc.).

>What I'm asking is include this useful event in IBO standard
>components, and I'm now sure you would like it too.

No, I don't need an event. A method like AssignParams is not an event,
it's just a block of generic implementation code that can be called when it
is timely to do so, from an event handler. In some cases I might write the
block to take a variant array containing some values, an object reference
to tell the handler where the call was made, I might pass various var
arguments, I might make it a function that returns a success/failure
result. The point is, your handler code for such a thing is
implementation-specific.

>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.

But the invalidation *already* occurs, as a result of altering the Value
property of one or more members of the Params[] collection. It doesn't
need to be added, as it is already there.

>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).

It already does it.

>In addition, in the b) situation, when you use OnParamSQL event, you
>have to invalidate the query to make this event work.

Do you mean OnPrepareSQL? If OnPrepareSQL is called, it means that the SQL
is already invalidated. You can call InvalidateSQL yourself when you need
to, but there are events where the SQL gets "invalidated" by virtue of the
SQL property being cleared and/or altered (or presents as empty).

>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).

What is OnParamSQL? I have never heard of it...

>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

It sounds arcane to me. If anything, it doubles up on what is already
happening at the various phases (but probably breaks the current event
chain) and I can't see what benefit it would have.

>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.

Me? No. There's no way I could or would presume to "improve" on the event
chain already implemented by Jason.

>IBO is a great time saver in a lot of situations, but why not push it
>benefits a little further?

I'm only one user, but you would have to make a much sounder case to
convince me.

>What disadvantages can you see in the above?

Broken event chain. Custom handlers being made capable of interfering with
the proper behaviour of the buffers and the parsing levels. More
confusions for developers, not less. Furthermore, I don't see any benefits.

Sorry, Marco.

regards,
Helen
\btw, it's 0215 here and I'm going to bed. <g>