its now working properly, its 99.9% perfect 
1 more thing thou, the NONE option in the dropdowns doesnt make the list blank. I traced it (by script debugger), your sample works perfectly fine. But mine bypasses the code GetField ( Get (ScriptParameter = "None"))
and i am now adding a script for date range
anyway, thank you very much for the assistance
Please look at the the fields in Layout mode and observe the Set Script Triggers… (right click on field)…Script parameters settings. I set Script parameters to match each field name.
Date range can be included in the same script if you like. Or a separate script using the Constrain Found Set step. What I do is have fields in my Globals table for startDate, endDate, and dateRange (the last is just what I like, not required). Then on the layout I have a date picker of various designs depending on needs.
Commonly, I have a popover button and on the popover I display the Globals::startDate and Globals::endDate fields. In some cases I have value lists instead, offering a list of 1-12 for months, and list of years (incorporating the "*" wildcard for the day). This latter option is for reports or finds for a given month.
In my use cases, the startDate is a required field (if adding Date to the find), but endDate is optional. This way one can find based on a specific date or a date range.
If you need any help incorporating such into the filtering script don't hesitate to ask.
And by the way: Since the popover will close when I hit the "Go" or "Filter" button, I typically show a $$globalVariable on the layout such as "Showing " & Globals::startDate & "though " & Globals::endDate –– or similar. It could also be displayed in a calculation field or dedicated Gloabals table field. There are more refinements, but I don't want to complicate things.
actually i have incorporated my previous date function
as you can see, i selected the NONE value in the dropdown and i pop a dialog to show the value and there is no value. thats the reason why it bypasses the if statement
the next thing here is i needed your suggestion. i am creating a report count on each category (dropdown).
i am thinking of the following:
which is more reliable and fast and logical?
should i create another thread for this?
Have you confirmed the script parameter on each of the selector fields' script trigger? Exact spelling to match your global fields, and in this implementation include the quotes as illustrated on the parameter value.
For the sharp eyed: Today I had changed the field name to include my conventional "g_" for global field names, but had not yet updated the script parameter value to reflect that at the time of this screenshot. That difference would've broken it. 
I think a new thread makes sense here so that others can benefit if they search for something similar. You can reference this thread if it helps provide context, @marke1415 .
its now working perfectly. the culprit is the double quote, i misLooked it, my mistake
Just a note that, if passing in the name of a field as a parameter, it is worth considering using the GetFieldName function, instead of a literal (quoted) string.
So, in this example, instead of a parameter of:
"Globals::dropdown2"
The parameter would be:
GetFieldName( Globals::dropdown2 )
The use of GetFieldName helps prevent code from breaking if the field name ever changes. That is its big advantage. That said, it is not necessarily the best choice 100% of the time.
There are use cases where GetFieldName could work against you. The two such cases that come to mind are:
If the receiving side (the side that receives the parameter) is using literal strings for comparison.
A case where the relationship graph has a really long path between the current context TO and the TO used in the field fed into the GetFieldName function. This type of scenario could cost some unexpected time overhead during the call to GetFieldName.
Hope this helps and kudos to @marke1415 and @daleallyn for getting this thread to a good resolution.
Yes, @steve_ssh, you're of course absolutely correct. I opted to hard code it just to keep it bare-bones simple and digestible, but I should have mentioned it in the message. Especially, where I made the edited comment above about it. I was rushed, and you pointing out the value of dynamic code is spot on.
I typically show someone the hard coded method for clarity and then explain how to improve it by using functions and other methods to harden it against such changes or for flexibility, etc.. In this case I neglected to follow-up, so thank you for doing so. 
Totally. I hope you know I was not trying to pick on anything in all the great help that you provided/shared -- rather, I just wanted to enhance that one small detail.
@steve_ssh, that small detail could give a big impact on the application.
@daleallyn , thank you for showing that code to us newbie, the code is very understandable, eventually that static variable can be enhanced to dynamic variable.
thank you everyone who contributed.
Absolutely, @steve_ssh ! You improved the thread and covered something I left out. Feel free to ALWAYS add to or correct whatever I may post. After all, this is The Soup, not an old, stale cracker.
Each sequential PERFORM FIND will replace the previous one. It is likely better served with a EXTEND FIND or a CONSTRAIN FIND based on “in addition to” or “within current found set”. A PERFORM FIND looks at the entire table’s worth of data.
If the find is against the same field, then once you enter find mode, each SET FIELD condition needs to be separated by a script step of NEW RECORD REQUEST (although duplicate works, it is a lot of extra overhead)
If you use a check box set instead of a drop down list, each checked item is a list of items separated by a carriage return (pilcrow character). You can then enter find mode and valuecount the number of items checked and loop through them (getvalue ; increment) into a SET FIELD and NEW RECORD REQUEST existing when increment equals valuecount
If the goal is just to get a count of the items in a field, there are a myriad of ways to do this in simpler ways
thanks sir kirk, that is another way of doing this.
