Programming a filtered dropdown search field above the grid

[clintg@erols.com]

Can it be done without doing it in a dialog? I was looking at Before Search events and putting filters in the a5w page, but haven't had any luck.

How cool would it be to have the equivalent of a cascading (filtered in this case with a session variable) pulldown in the built-in search above grids when the user wanted to find something?

I know you can hard code a filter with a constant but that isn't helpful for me at least.

Can this be done? Alpha?

[rleunis]

Clint,

This code works for me:

if eval_valid("session.org_id") ' session.org_id exists 
    if (session.org_id <> "") ' value exists
		If (session.__protected__SecurityLevel <> 7)
			tmpl.DBF.filter = "Organization_Id=\""+session.org_id+"\"" 
			tmpl.SearchField_Info[1].DropDownBox.Filter = "Organization_Id=\""+session.org_id+"\""
			tmpl.DetailField_Info[1].DropDownBox.Filter = "Organization_Id=\""+session.org_id+"\"" 
		end if
    end if 
end if

SearchField_Info[1] is your searchfield indexed by a number. You can lookup the number in the xbasic of your component. You insert the code in the a5w page which contains the component.

In my case I only display records of a certain organization where the logon user is attached to. Except when this user has security level =7. In which case this user can see and search all records for all organizations.

regards, Ron

[clintg@erols.com]

Clint,

This code works for me:

if eval_valid("session.org_id") ' session.org_id exists 
    if (session.org_id <> "") ' value exists
		If (session.__protected__SecurityLevel <> 7)
			tmpl.DBF.filter = "Organization_Id=\""+session.org_id+"\"" 
			tmpl.SearchField_Info[1].DropDownBox.Filter = "Organization_Id=\""+session.org_id+"\""
			tmpl.DetailField_Info[1].DropDownBox.Filter = "Organization_Id=\""+session.org_id+"\"" 
		end if
    end if 
end if

SearchField_Info[1] is your searchfield indexed by a number. You can lookup the number in the xbasic of your component. You insert the code in the a5w page which contains the component.

In my case I only display records of a certain organization where the logon user is attached to. Except when this user has security level =7. In which case this user can see and search all records for all organizations.

regards, Ron

Thanks Ron, I'd like to try that. Would I put code like this in the same place I'd put code if I wanted to filter the grid or somewhere else?

I'll include a sample of the filtering I mentioned above.

Delete tmpl_GrdClassReview
DIM tmpl_GrdClassReview as P
tmpl_GrdClassReview = a5w_load_component("GrdClassReview")
'Following code allows you to override settings in the saved component, and specify the component alias (componentName property).
'Tip: Keep the componentName property short because this name is used in page URLs, and it will help keep the URLs short.
'Each component on a page must have a unique alias (componentName property).
with tmpl_GrdClassReview
.dbf.filter = "Officenbr = " + s_quote(session.FromOffice)
.field_info[1].DropDownBox.Filter = "Officenbr = " + s_quote(session.FromOffice)
.field_info[2].DropDownBox.Filter = "Officenbr = " + s_quote(session.FromOffice)
.field_info[8].DropDownBox.Filter = "Officenbr = " + s_quote(session.FromOffice)
componentName = "GrdClassReview"
end with

Thanks again

[rleunis]

Clint,

Yes, place it same place as the DBF.filter in the webpage.
Alpha Five webhelp give following example:

with tmpl_Selected_Invoic
    componentName = "Selected_Invoic"
    DBF.filter = "userID = \"" + session.__protected__UserID + chr(34) 
    field_info[7].DropDownBox.Filter = "userID = \"" + session.__protected__UserID + chr(34)
end with

So I would place > componentName = "GrdClassReview" <
right after > with tmpl_GrdClassReview< ... Because I am not sure if you leave it like this it will generate an error or not..

And if you have a grid with detailview and this detailview also contains a dropdown, then you can use the tmpl.DetailField_Info[1].DropDownBox.Filter.

You should be able to use this code also in Lookups but then in the override section of the lookup definition. But I did not give that a try yet. Maybe somebody else has experience with that?

good luck, Ron

[Edward Larrabee]

You can see another example in Filtering a Grid with a Session Variable.

[clintg@erols.com]

Clint,

Yes, place it same place as the DBF.filter in the webpage.
Alpha Five webhelp give following example:

with tmpl_Selected_Invoic
    componentName = "Selected_Invoic"
    DBF.filter = "userID = \"" + session.__protected__UserID + chr(34) 
    field_info[7].DropDownBox.Filter = "userID = \"" + session.__protected__UserID + chr(34)
end with

So I would place > componentName = "GrdClassReview" <
right after > with tmpl_GrdClassReview< ... Because I am not sure if you leave it like this it will generate an error or not..

And if you have a grid with detailview and this detailview also contains a dropdown, then you can use the tmpl.DetailField_Info[1].DropDownBox.Filter.

You should be able to use this code also in Lookups but then in the override section of the lookup definition. But I did not give that a try yet. Maybe somebody else has experience with that?

good luck, Ron

Alpha's help didn't help because it doesn't reference search fields.

Here is my code below. It fails when run because it can't resolve the search field. The search field is correctly named as a review of the Xbasic shows.

Delete tmpl_GrdLGAudit
DIM tmpl_GrdLGAudit as P
tmpl_GrdLGAudit = a5w_load_component("GrdLGAudit")
with tmpl_GrdLGAudit
componentName = "GrdLGAudit"
if eval_valid("session.FromOffice") ' session.org_id exists
tmpl.SearchField_Info[2].DropDownBox.Filter = "Officenbr = \"" + session.FromOffice + chr(34)
end if
end with

Do you have an example where you modify a search pulldown that is complete so I can compare it to what I'm doing? Does Alpha?

Thanks, I feel I'm close and an example showing the concept in use would really help me identify my error. Thanks Ron, Thanks Alpha

[Edward Larrabee]

Delete tmpl_GrdLGAudit
DIM tmpl_GrdLGAudit as P
tmpl_GrdLGAudit = a5w_load_component("GrdLGAudit")
with tmpl_GrdLGAudit
    componentName = "GrdLGAudit"
    if eval_valid("session.FromOffice") ' session.org_id exists
        tmpl.SearchField_Info[2].DropDownBox.Filter = "Officenbr = \"" +  session.FromOffice + chr(34)
    end if
end with

The bolded code is causing a problem. Remove it. You are saying: "tmpl_GrdLGAudit.tmpl.SearchField_Info[2].DropDownBox.Filter = " and should be saying "tmpl_GrdLGAudit.SearchField_Info[2].DropDownBox.Filter = ".

[clintg@erols.com]

Delete tmpl_GrdLGAudit
DIM tmpl_GrdLGAudit as P
tmpl_GrdLGAudit = a5w_load_component("GrdLGAudit")
with tmpl_GrdLGAudit
    componentName = "GrdLGAudit"
    if eval_valid("session.FromOffice") ' session.org_id exists
        tmpl.SearchField_Info[2].DropDownBox.Filter = "Officenbr = \"" +  session.FromOffice + chr(34)
    end if
end with

The bolded code is causing a problem. Remove it. You are saying: "tmpl_GrdLGAudit.tmpl.SearchField_Info[2].DropDownBox.Filter = " and should be saying "tmpl_GrdLGAudit.SearchField_Info[2].DropDownBox.Filter = ".

Wow, that did it. I greatly appreciate your and Ron's assistance.

Will Alpha will include help elaborating web related modification of grid defaults (like this for *search* fields above) in it's helpfiles in the near future?

I'm also really looking forward to clearer help files indicating which platform (Web vs Desktop) functions relate to. I think everyone would be able to program with less problems if there were clean examples of each function and designation of its Web vs Desktop usage.

Perhaps you could break the help into a Web section and one for Desktop like you do in the forum?

Thanks again

[Edward Larrabee]

Functions and methods that are inappropriate in web applications are those that display messages or dialog boxes. In other cases where functions or methods are incompatible, I am documenting them as they turn up.

[clintg@erols.com]

Functions and methods that are inappropriate in web applications are those that display messages or dialog boxes. In other cases where functions or methods are incompatible, I am documenting them as they turn up.

While I understand what you've written above "applications are those that display messages or dialog boxes" "are inappropriate in web applications", how would a new user know that?

Wouldn't it be better for Alpha to do what Alpha does in the forums (where we are now), break into sections for Desktop versus Web, functions that only work in Desktop and functions that only work on the WAS. Those that work in both would be included in both.

How can this not be the best way to represent the complexity of the code in the help file? Other than it taking Alpha some effort to segregate the help meaningfully for their paying customer base, what reason would there be *not* to do that way?

Again, I thank Alpha for assisting this customer.

(Hmm, I'm talking about myself in the 3rd person, that's just wrong ;) ).

[Edward Larrabee]

You can easily tell which functions or methods display messages or dialogs by checking the help files. At least 90 percent of Xbasic functions and methods are usable in both desktop and web applications.