Subject | Re: [IBO] Re: Refreshing parameterised IB_Query when params change |
---|---|
Author | Helen Borrie |
Post date | 2003-03-01T13:39:43Z |
At 10:42 AM 1/03/2003 +0000, you wrote:
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
>Ok, I will riassume the problem for your and other's convenience:Marco,
>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?
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