Script with custom dialogue that allows user to search for multiple values within one field

[jl2017]

I have a database that tracks submissions we get from our VFX Vendors.  I have a field in this database that I import all of the vendor submissions into.  I would like to know if there is a way to search for multiple submissions through a custom dialogue.  I have successfully created a script for searching for one submission.  Is there a way to expand upon what I already have?  Here is what I have so far:

Go to Layout [ "VFX Notes Original" (VFX Notes) ]

Enter Find Mode [ ]

Show Custom Dialog [ "Vendor Submission Notes" ; "Enter the vendors submission name down below." ; VFX Notes::VFX Notes_CompDateRecieved ]

If [ Get ( LastMessageChoice ) = 1 ]

     Perform Find [ ]

     Go to Layout [ "Vendor Issue Notes" (VFX Notes) ]

     Enter Browse Mode [ ]

End If

If [ Get ( LastMessageChoice ) = 2 ]

     Enter Browse Mode [ ]

     Go to Layout [ "VFX Counts" (VFX Counts) ]

End If

 

Any guidance would be greatly appreciated.  Thanks in advance!

[comment]

I would like to know if there is a way to search for multiple submissions through a custom dialogue.

Of course there is - but I am not sure if that's the best user interface for such scenario. By the time you enter the third search term, you may have forgotten what the first one was.

Anyway, if you want to take this route, your script must be in a loop and your custom dialog must provide the user with 3 choices:

1. add another search term;
2. perform find;
3. cancel.

 

[jl2017]

Not ideal...as you have suggested but let's say I go about this and add a third button.  Say we turn 1 into Find, 2 into Cancel and 3 into Add Vendor...so I would add a loop to the If equation for 3, but how would I maintain the data entered in order to search it once 1 or Find is pressed?

Is there a way to generate a list of all of the vendor submissions that the user could highlight and then perform the find?  Basically a way to generate a custom dialogue where one could select the appropriate submissions and execute said selects from the custom dialogue?  Just curious if there was a way to do that and if it was more effective.

 

[Kris M]

Learn to use the Filmmaker find function in all its permutations (omit, multiple find requests etc) then script what you can't do?

FMs built in find functionality is pretty stout.

 

Edited August 12, 2015 by Kris M

[comment]

how would I maintain the data entered in order to search it once 1 or Find is pressed?

The loop would create a new find request on every iteration, something like:

Go to Layout [ “YourTable” ] 
Enter Find Mode [  ] 
Loop 
  Show Custom Dialog [ Buttons: “Add”, “Find”, “Cancel”; Input #1: YourTable::Vendor ] 
  Exit Loop If [ Get ( LastMessageChoice ) ≠ 1 ] 
  New Record/Request 
End Loop 
If [ Get ( LastMessageChoice ) = 2 ] 
  Perform Find [  ] 
Else 
  Enter Browse Mode 
End If 

 

Is there a way to generate a list of all of the vendor submissions that the user could highlight and then perform the find?

I didn't quite get this part. If they have selected the submissions they want, what would then the find do? Just omit the records they haven't selected?

Edited August 12, 2015 by comment

[Mark Scott]

Hi jl,

I agree with comment that the custom dialog approach might not be the most graceful way to script a find . . . and with Kris that your goal should be to support FileMaker's native Find functionality (particularly multiple find requests, as Kris mentioned) as much as possible, even as you script the process and put a more intuitive interface on it.

Assuming you want to stick with, and build upon, the custom dialog approach, and if you can limit your users to searching a maximum of 3 submissions at a time—is that a reasonable assumption here?—then you could:  (1) give them 3 input fields (make them global fields, out of which you'll grab user input with successive loop iterations); (2) limit your loop to up to 3 iterations (depending on how many input fields are filled in); and (3) create a New Request with each loop, one request per input field, populating your actual submission field from the global inputs.

See if that works for you.  (Personally, I'm not sure I'd do it this way, as I intimated above, but it may be worth exploring.)

Mark

[comment]

(1) give them 3 input fields (make them global fields

IMHO, the cost outweighs the benefits.

(2) limit your loop to up to 3 iterations

What would be the point of that?

[jl2017]

So I was able to get this to work with the loop that was provided.  It may not seem graceful to the outside world, but I think it will work just fine for my needs.  Far better than what I had before.  Thanks for all the input and advice.  Greatly appreciate it!

[LaRetta]

So I was able to get this to work with the loop that was provided.  It may not seem graceful to the outside world...

On the contrary ... it seems ideal for your need.  :-) 

[Mark Scott]

So I was able to get this to work with the loop that was provided.  It may not seem graceful to the outside world, but I think it will work just fine for my needs.

Many ways to skin a cat.  Glad you got a good solution.

[comment]

It may not seem graceful to the outside world, but I think it will work just fine for my needs.

I still think you should set your aspirations higher. I know for sure that I wouldn't like this as a user. When I enter 3 or 4 pieces of information in succession, I want to be able to review my entry and, if necessary, modify it before taking action on it.

There is a way you can at least see what you have entered so far, by inserting the following into the loop, say right after the Exit Loop If[] step:

Set Variable [ $searchTerms; Value:List ( $searchTerms ; YourTable::Vendor ) ]

and making the custom dialog display a calculated message =

"Search terms entered so far:¶¶" & $searchTerms

 

Ultimately, though, I would prefer working in a list view displaying the requests and being able to add/modify/delete requests at will. Or perhaps just tick the vendors of interest in a checkbox field, if that's what this is about.

 

 

Edited August 12, 2015 by comment

[Mark Scott]

One other thing to consider, jl, is whether you might want to extend your design in the future to support searching on multiple fields, say vendor and date range.  A more standard approach, such as the one comment has advocated, is going to be more flexible and extensible.

That said, FileMaker is forgiving, so there is nothing wrong with using the approach you've worked out, getting user feedback, and then, depending on that feedback (or simply on evolving user needs and business rules), changing the approach down the road.

Let us know how it works out.

Mark

[jl2017]

Okay...so I added the $searchTerms custom dialogue and have to admit, it is extremely helpful.  I have a simple okay button to move onto the next submission so entering multiple submissions is a breeze by hitting the enter key.  I wanted to search this way to make it a cleaner experience for the user.  I realize I could do all this within a layout, using list view and doing multiple finds.  But I like the finder like interaction the custom dialogues give.  I'm happy with how this came out...way better than I was expecting.  Thanks for all the support everyone!  Greatly appreciate it.

[LaRetta]

I have a field in this database that I import all of the vendor submissions into.  I would like to know if there is a way to search for multiple submissions through a custom dialogue.  

I too prefer another method: presenting the user a global text field where they can enter their multiple requests as lines.  It is easy to view (unless there are a lot of course), and then script can simply loop the values and set a new request accordingly.

But I enjoyed the clarity and simplicity of Comment's script which will come in handy for many different (but similar) scenarios and his script DID completely fulfill the request.  Since Comment pointed out it wasn't the best approach, I didn't take it any further.  Both Mark and Kris also gave great feedback.

I wonder if we aren't missing the beginning though (at least I did at first):  instead of leaving those 'imported' lines (vendor submissions) as a multiline in a single field and then searching for them later, it might be best to break it into records at (or during) the import process so the find is based upon records. This may provide additional benefit for the rest of the solution and is more normalized anyway.

 

[Mark Scott]

I know you've got a workable solution, jl, so consider the following just a thought exercise. LaRetta's comment about entering multiple requests ("vendor submissions" in this case) as lines reminded me of an approach I've used before. My goal was to be able to enter a list of specimen accession numbers, and then find those records in order to generate a "pick list" to carry back to our lab specimen freezers. In a nutshell, GTRR!

A colleague would email me a simple, return-delimited list containing any number of accession numbers that she needed pulled. Then, I'd simply paste that list into a global field (must be a text field to accommodate return-delimited values), and Go to Related Record(s) via a relationship from that multi-valued global field to the actual accessionNumber field in the same table. GTRR itself is lightening fast, and it was simple to design the UI for it. As an alternative, a picker UI could also be used to choose the items to be found and populate the global. Just a thought.

[Steve Martino]

‌@comment quick question (sorry to hop on thread)

Set Variable [ $searchTerms; Value:List ( $searchTerms ; YourTable::Vendor ) ]

Does this just appends the search terms by taking a list of the search terms and adding the last search term to the end, each time thru the loop? I've never seen it done that way, saves some typing with &'s and pillcrows.

[comment]

‌Does this just appends the search terms by taking a list of the search terms and adding the last search term to the end

Yes.

‌saves some typing with &'s and pillcrows.

It also prevents the creation of an empty row when the appended value is empty (not always an advantage, though).