Virtual Pickers (without Selector-Connector)

Questions
1

Hello,

I have been an in-house developer for a long time and have used the selector-connector model exclusively there. I have one virtual table for pickers that I can use everywhere to select a person, a room, a device,... It is quite interesting regarding modularity.

Now I have a new client and want do deviate from selector-connector. What is the best approach regarding pickers? Card windows are nice, but what to do if I am already in a card window and have to use a picker there (and do not want to lose state)?

Is it best to stick to a virtual table and have it hanging off every table for which I need a picker in a card window?

Regards,

Matteo Krings

1 Like
2

Welcome to The Soup @Matteo. I hope it becomes a good resource for your FileMaker needs.

Dialogue box windows are a good fit here. You can invoke many at the same time and the top-most dialogue box window blocks access to all other windows.

There is a caveat. This would be a poor choice if you want your users to access windows of other files while the dialogue box window is displayed.

I access the source table from which I need to pick. I use inbound JSON to alter the behaviour of my pickers during runtime, callbacks to handle pick logic and window variables to save state when script execution stops.

Hope this helps.

3

Thanks!

However, as I use Webdirect a lot this is not an option right?

4

I use a table which is devoted to storing state for the application. Every field is a global so that it is accessible across all contexts. Like @bdbd I use JSON because it provides so much flexibility. The script that calls the picker receives the JSON and stores it.

The pickers gets to use the JSON and add to it if needed. Importantly, the pickers never need to know who is calling them. They just do their thing and update the JSON if needed.

5

Unfortunately correct. Only document and card windows are supported in WebDirect… and only the top-most document window is visible.

6

Ok, thanks for your replies. Two more questions:

  1. So I guess I have two possible solutions when using a card window as picker in cases where I already am in a card window :
  • use a picker table (virtual list) and hang it off every base table for the existing card window and use a popover as picker.
  • save the state of the card window, close it open the picker and then restore the card window that was shown before.
  1. I would like to use JSON as well for different reasons (especially encoding from certain characters), but I wonder if the gathering process for the picker ist fast enough. Usually I use SQL to gather IDs and some additional information to display in the picker. If I have to gather all this in JSON, isn't it much slower that pure SQL?

Any suggestions?

7

I don't think you will need to save much state in the card window. A card window is like any other window. State is saved for the exiting layout when you change layout, assuming the new layout isn't based on the same table occurrence. You could simply go from the picker 1 layout to the picker 2 layout, do your thing in the picker 2 layout, and then return to the picker 1 layout. Picker 1's layout state will be as you left it.

1 Like
8

I am not sure why you would want to use a gathering process. I've never had a need to do so for pickers.

Let me demonstrate one use of inbound JSON for pickers. It contains:

  • A layout to use;
  • A find to perform;
  • Pre-select values (for multiple-selection pickers);
  • A callback to process the user's selection(s).

Many of my pickers use a common set of scripts. A layout indicator allows generic picker scripts to target many pickers.

Of course I don't usually want to display all of a table's records for a picker. A find indicator allows generic picker scripts to constrain the picking set of records.

I use multi-selection pickers in some of my solutions. A user may want to add selections to a set of selection, so pre-selected values can either appear already selected or be omitted from the picking set of records.

Pickers can be invoked from anywhere and aren't necessarily related to anything else in the solution. They hand the pick(s) (or cancellation) over callbacks, which then apply whatever logic is needed to process the pick(s).

The above is only an example. There are many ways to use inbound and outbound JSONs.

Hope this helps.

1 Like
9

I talked about a gathering process, because so far I have only used virtual lists as pickers and displayed them in a portal on a popover. This was easy to manage in the selector-connector-framework. Using this approach I had to gather IDs and additional information to put it into the virtual list.
It is difficult to think otherwise, as I have done this for years.

I might try to use the actual context for the picker from now on, but it still leaves me with the difficulty regarding opening a picker in a card window in webdirect. I guess I have to think and try closing the existing card window and then open a new card window with the picker.
Still without having tried it it seems not the best user experience if the card window I am working on disappears, because I need to pick something, and the re-appears again.

A card window in a card window would be nice...

10

Have you looked at the Get(WindowStyle) function? It's a handy way to fork behaviour in a script. If you are in a card window you cannot create a card window but you can switch layouts.

Returns:

  • 0 (zero) if the window is a document window
  • 1 if the window is a floating document window
  • 2 if the window is a dialog window
  • 3 if the window is a card

Notes

  • The window on which the script is acting may not necessarily be the foreground window.
  • In FileMaker WebDirect, this function returns 0 or 3.