Date Query filter

[Mike Wilson]

I have spent more time on this than I should have to. I have toured the board, and played with this ad nauseum, and can't make it happen. I need help, please, to show me the error of my ways.

I am simply (quite the joke) trying to filter the single table - Donations - by date range, through an xDialog that collects the start and end dates into variables, and using queryrun() to filter the table. I cannot get variables to work. Direct entries work through the Genie, but I can't get variables to run.

The attached example has one table - 'donations'. The form F_donations has two, red buttons. One uses tries to use the character variables and the other converts them to date variables. Niether works.

Any help is appreciated.

[Tim Kiebert]

Re: Date Query filter

Hi MIke,

I think you are still recovering from your little holiday.;)

I got the "date" version working by dimming the vdSdate and vdEdate variables as shared. I haven't worked through the code on the "C" type button yet. Work is interupting again, will have to get to it later if no one else has in the mean time.

[Mike Wilson]

Re: Date Query filter

Tim,
Yes, that must be my excuse. And working on things late into the night. Thank you for that rather simple solution that wasn't one of the 100 things I tried. Nothing further is needed. I just threw the Character path up for some degree of completeness. Don't bother (although I know you, as I, thrive on finding solutions!)

Now, off to try and understand why the variables dimmed as local within one script didn't work and needed to be shared... The docs don't seem to tell me this should be necessary. Thanks again.

[G Gabriel]

Re: Date Query filter

Mike:
A variable dimmed local will run at that script only. After the script runs, it goes to file 11.

A shared variable is a session variable and is created when a layout window is first opened, or when an Operation is defined or run. You can use it between scripts running from the layout. More broad than local, less than global.

[Mike Wilson]

Re: Date Query filter

Deleted. Accidental posting.

[Mike Wilson]

Re: Date Query filter

Mike:
A variable dimmed local will run at that script only. After the script runs, it goes to file 11.

Gabriel,
Yes... so this is what the documentation suggests, too. Maybe you can offer a bit more wisdom for this dense sole. In the following code that has the variables vdSdate and vdEdate dimmed local (and does not work), which part of the code consitutes 'at that script only' and what defines the boundries of the code that delineate 'a script', such that the variable scoped local lies outside of the code that equals 'a script' and covered by scoping local?

	dim dbxDate as C
	dim vtitle as C
	
	dim vcSdate as C="06/01/2007"
	dim vcEdate as C="08/01/2007"
	vTitle = "Dates"
	
	dbxDate=ui_dlg_box(vtitle,<<%dlg%
            {lf};
	{region}
	Start Date:|[.16vcSDate];
	End Date:|[.16vcEdate];
	{lf};
	{endregion};
	{line=1,0};
	{region}
	<15OK!OK> <*15Cancel!CANCEL>
	{endregion};
	%dlg%)
       SELECT
	CASE dbxDate = "OK" [COLOR="Red"]
           dim vdSdate as D
           dim vdEdate as D
	   vdSdate = ctod(vcSdate)
	   vdEdate = ctod(vcEdate)[/COLOR]
	
	   DIM records_found as N
	   records_found = topparent.queryrun("between(Do_date,Var->vdSdate,Var->vdEdate)","recno()","","No","",.f.)

	CASE dbxDate = "Cancel"
	   END
       END SELECT

[Tom Cone Jr]

Re: Date Query filter

Mike, I'll take a crack at it, subject to correction or clarification by those more knowledgeable than I.

topparent.queryrun("between(Do_date,Var->vdSdate,Var->vdEdate)","recno()","","No","",.f.)

This code calls a method in the form, not a function in the currently running script. The method must be evaluated in the context of the form, and the form doesn't know about the local variables in the currently running script. Imagine doing this with two buttons. In button one you open the dialog and populate the local variables, vdSdate and vdEdate. Then that script ends. The dialog closes and the user is taken back to the form where she pushes the 2nd button. This button calls the queryrun() method of the form using the local vars from the first button. You wouldn't expect that to run, right? Well your script is doing the same thing. It's not passing variables to a function, it's trying to call a method of the form object using parameters the form itself can't evaluate.

[G Gabriel]

Re: Date Query filter

Tom:

I'll take a crack at it, subject to correction or clarification by those more knowledgeable than I

Don't hold your breath!

Mike:
I feel your pain. You reason that, since queryrun is part of that one script, then the local variables should, by definition, be available to queryrun. True. Except that this script opens an xdlg. When the user enters the values and those values are stored in the local variables, then you run the queryrun, in essence, you abandoned the "layout", that is the xdlg in which these variables were defined, and once that is closed, the variables goes away with it. Perhaps a better definition is:
"..Variables of this sort are called local variables because they are restricted to the context in which they are defined"

This makes me a bit curious if you would see the same behavior if you keep the xdlg open or make it modeless? I will have to investigate that.

Anyway, I can't think of any good reason to dim a variable as local, except a couple. Maybe if I think hard enough, I might stumble at others. First reason is George Forman (a living proof that boxing causes brain damage or perhaps and more aptly in his case, brain damage causes one to box, which in turn causes brain damage).

George Forman in his great wisdom, named all his five sons George. Thank goodness for an alert nurse who made sure to dim his sons as local variables, because if he dimmed them as shared, that household would be a major mess.

What I am trying to say, you dim a variable local just for the mere chance that you might have dimmed other variables with the same name George in other areas.

Second, if you have no plan to use them anywhere else, why clutter memory with useless variables.

[Mike Wilson]

Re: Date Query filter

Tim, Tom, Gabriel,

I appreciate your insights, I really do. I'm needing some time to digest this. I'm sensing I'm in a place a bit like Steve Hawkings trying to evaluate string theory to establish a unified theory to amalgomate relative physics.

I have broken this down to it's most "particle matter", and it still requires shared variables, holding a relational concept I haven't yet grasped. OK. I have to clearly ponder this more carefully.

I thank you all, sincerely!

[G Gabriel]

Re: Date Query filter

another way to look at it is, you have a script (quryrun) within a script (xdlg).

[Tim Kiebert]

Re: Date Query filter

another way to look at it is, you have a script (quryrun) within a script (xdlg).

Technically in Mike's above (or below if you view newest messages at the top) code we have a script for the OnPush event that contains within it an xDialog and also the queryrun method. The query run code is not actually in the xdialog code. This doesn't really have a bearing on the scoping of the variables as far as the discussion has gone. It is rather just an observation.

[G Gabriel]

Re: Date Query filter

Thanks Tim..that's makes even easier to explain that those local variables were created in the context of the xdlg and cannot be shared with other scripts.

This begs the question, what if it were in the xdlg code?
I've got few questions to investigate and a little apetite to do so.

[G Gabriel]

Re: Date Query filter

I did some testing and found out that whether the "second script" is run after the xdlg is closed vs if it is in the xdlg code it makes no difference. In both cases the variable is visible to that "second script".

[G Gabriel]

Re: Date Query filter

Let me see if I could explain this more intelligently, because I've done a lot of rambling that might cause more confusion than understanding.

1-The variables are dimmed as local in the context of a script that:
a-opens an xdlg, and then
b-runs queryrun

2-The variables, being local are visible throughout that script

The question becomes, if that is true, then how come queryrun gives an error message of bad filter, when the filter uses those variables?

I have run across this issue long time ago and learnt that to get it to work you need to either dim those variables as shared or global.

So, here is my explanation and it is purely speculative.
Yes, the variables are visible throughout the script, but when you invoke queryrun, which is a high level function, it opens the table to be queried, then it looks for the filter. In the context of the table opened by queryrun, those variables are not visible. It's a different context from the ones in which they were originaly dimmed.

To verify my theory, I used a different line of script instead of queryrun, just a message box after the OK button is clicked in the xdlg, and it shows the variable.