Pointer to form's query

[whanigsberg]

Hi all,

I am going round in circles on something that should be easy.

I have a button on a form which calls a second form based on the same table (set)in dialog mode. I am using the dialog form as a record picker. It has an embedded browse and users double click on a row to return to the calling form with the selected record showing.

This works fine.

The problem is that the calling form's filter includes a variable and I re run the query on the dialog form which is slow on a network.

Can I,
get a pointer to the calling form's query and simply apply it to the dialog form thus obviating the need to run the same query a second time.

Bill

[Tom Cone Jr]

RE: Pointer to form's query

Bill,

Can you leave the called (dialog) form open, but hidden? If so, I should think you would not need to re-run the query when you 'show' it again. Is this what you have in mind?

-- tom

[Tom Cone Jr]

RE: Pointer to form's query

Bill, on re-reading your post I see that I missed the point. (Was looking in the wrong end of the telescope!)

I don't think you can see the calling form's query list from the called (dialog) form. Will be very interested if others can suggest a solution.

First thought that comes to mind here would be to investigate the use of a conditional object on your calling form. Something that could hold the browse object you need, but remain hidden, only to popup when it's time to select a record. Would something like that work?

-- tom

[Tom Cone Jr]

RE: Pointer to form's query

Bill,

You know of course that you could populate a ui_get_ list_array and let the user select the desired entry from there, without opening another form or re-running the query...

I'm thinking the array could be populated earlier in the sequence, and the list box remain hidden until needed...

-- tom

[whanigsberg]

RE: Pointer to form's query

Hi Tom,

I managed to do it and it is not difficult. I attach the script with the old lines which recreate the query commented out and the new lines indicated. The script runs from a toolbar button.

It works instantly which is my goal. The previous version really couldn't be optimized so on the network with a cartload of records in the application you could see the progress bar moving.

Since I have my users jumping among forms but always seeing a particular selection of records (their department's) I think this technique will be of use to me.

All the best,
Bill

[whanigsberg]

RE: Pointer to form's query

and I don't even need
q = t.index_primary_get()
because

t = table.current(1)
vTag = t.index_name_get(1)

gets the tag which is all I need.

It seems I can't apply the index to the dialog form using a pointer but I can tell it to use an existing query on the table so long as I have its name.

I am presuming that in the expression "index_name_get(1)" number 1 will always give you the index active index in the current session.

Time will tell.

Bill

[Tom Cone Jr]

RE: Pointer to form's query

Bill, how did you intuit the use of the 'tag' property for the called table? I'm certain I would never have thought to use it...

-- tom

[whanigsberg]

RE: Pointer to form's query

Well Tom, I figured that tag meant name and tag does get you the name of a named index so I assumed that all those files with filenames begining with $$ that we try so hard to delete had names too, even if they began with dollar signs.

I will concede that I wondered whether it would work but it did. As Aristotle said, "Actuality implies possibility". As my mother said, "go figure?"

Best,
Bill

[whanigsberg]

RE: Pointer to form's query

Caveat:

Further testing required. I'll report back tomorrow.

Bill

[whanigsberg]

RE: Pointer to form's query

It doesn't work.

That is, I have not found a way to obtain a pointer to the query controlling the current form. Tag works ok but refers to the index controlling the table. One might think that this is the query imposed by the current form but it seems not to be true.

So I am left with the original problem. The reason I posted was that I have some recollection of a newish method to grab this property but I can't remember where it is.

To make things even worse, I impose the filters on the forms using xbasic so when I try to get at them using form based methods I get an empty string.

Bill

[Tom Cone Jr]

RE: Pointer to form's query

Bill, maybe it's time to investigate ui_get_list_array() to avoid burdening the system with the load of opening a new form and re-running the query. If the sole purpose of the called form is to present a list for the user to select from, maybe ui_get_list_array() will suffice. It's bound to be faster, though the display options are more limited.

-- tom

[JerryBrightbill]

RE: Pointer to form's query

Bill

Been following your post and I think I understand what you want. I had a similar need and found that running a query before opening the dialog was just too slow. Instead, I tried a filter on the form which was set to filter using a global variable. An index existed on the field to use in the filter. Example - grp_no is a field for a list of inventory groups. I set a global variable , "grp_no", to the group I want to see. The global is initially defined in an autoexec script (could be defined in the table properties too) Then in the form filter I put

Grp_No=var->grp_no

This works many times faster than running a query, since an index already exists for the grp_no field. I normally also include an order expression too.

Jerry

[whanigsberg]

RE: Pointer to form's query

Thanks to you both.

This morning I experimented with another way which works but is a bit of trouble to retrofit.

I covered my entire calling form with a conditional object and put everything from the original on the default layer. On a second layer I put everything I had on the called (dialog) form.

Since the two "forms" are actually the same form they have the same record pointer, filter, and order so choosing a field on the one instantly synchs to the other.

So this does work. The same button that called up the dialog now just changes a variable and refreshes the conditional object. Double click on a row in the embedded browse on the second layer of the cond obj toggles you back by pressing the same button (the same code won't work directly on the double click event).

My problem is I have so much event based code on the original form that I hesitate to mess with it. Perhaps I'll experiment with both of your approaches first.

I concur with Jerry's observation about the speed of the query process. That's why I'm seeking an alternative.

Best to you both,
Bill

[whanigsberg]

RE: Pointer to form's query

I have a solution of sorts. It involves moving the deck chairs around in order to create a query which will optimize. Since this is really a different topic I am starting a new thread.

There is a demo.

Bill