I'm contemplating whether I can enhance the portal displaying visitors to facilitate the selection of the employee (host). Please note that the current portal functions perfectly, but with the increase in employees to around 150, such as the sales department with 25 employees, the process of selection has become more challenging. I'm considering splitting the portal into three columns instead of one to streamline the selection process.
Additionally, I aim to improve the system by enabling searches based on the employee's name, as opposed to relying solely on department searches as we did in the past.
You can create 3 (or more) portals of the same TO, the first (as example) beginning with record 1, displaying 15 records, the second one beginning with record 16, displaying 15 records - and so on.
It is an option in the settings for a portal - or in the inspector (I got just an iPad here, no FM)
If there are 3 columns, I do not set the scrollbars for the first 2 - but I do set the scrollbars for the last column...
Basically, I think that a search function in the portal would be sufficient to quickly display suitable results. This would make the three-column portal unnecessary. I must also confess that I find a three-column portal more difficult to keep track of from a UI perspective than a single-column portal where all the names are in a single row.
If you still want to have the three columns, this could possibly work via a virtual list (I haven't tried it though):
For this you would have to summarize the data records of the portal in a list (in a variable). This list is then distributed to the data records of an auxiliary table, which forms the basis of your portal, with the help of a script (or a clever function that I can't think of right now) according to the following scheme:
Name1 Name 2 Name 3
Name4 Name5 Name6
...
You then place 3 buttons per row on the portal to copy the first, second or third name.
The OP's 3-column target design is a grid view . A grid view is something FM can't do out of the box and the 3-portal approach is the closest we can get within FM.
I'll post a file here that I did not create. It was provided in a discussion elsewhere in the FM community (Claris) and I believe it was offered as an example of grid design by user "Onefish" (it's been awhile). It may not be helpful in the context of this discussion, but I could see ways to adapt it as a possible "picker" UI similar to the OP request. The child record fields could have a button action attached to them.
I would not expect it to be particularly performant in a very large solution, but @Saeed has suggested that the tables referenced have fewer than 200 employee records, so shouldn't be an issue in most cases.
Edit: Short answer is that I present a popover or a card window and enter the search criteria there.
Hello, @Saeed . Searching content in portals is a little different because the results will be all the parent records which have the criteria in the portal row. Not always (or usually) what we want. I mean, if you search the portal for "Susan" you'll get a found set of the all the Parent records with "Susan" in the portal for that field.
When I want to search within the portal currently related to the parent record I'm sitting (the context) I do scripted finds using an off-screen "utility" window based on the table occurrence upon which the portal is based. I always use a blank layout (no fields) for improved performance unless I'm doing the find in a card window which is designed to also set another field with the results directly.
When doing this, in the script(s) we'd want to store the foreign key for the parent--<portal relationship so we include that in our search, together with the desired name or email address or whatever the search is.
There are a lot of UI options for this. One is a popover or a card window which has a global field on it into which the user enters the search criteria, then the script does the find by setting the appropriate search criteria (including the foreign key to isolate the records to those related to the parent record).
In fact, all of my search tools are scripted in my solutions. My clients' users don't even know about the View... Find Mode option in nearly all cases. Even though my custom menus do include the Find Mode. The point is: if you give the user an intuitive way to search within the data represented in the portal by providing tools in the UI, it's easy to script the process.
That's a cool example. Thanks for sharing. I've used the Mod() function to make a grid view before, with kind of the same approach. Just pass in a sequential number for the first param, and the number of columns for the second param, then check it against the column number.
I used the sample data from the example you shared to set up a demo of it.
> If I need to search by name or department in the portal, how can I add the search field?
Hi @Saeed , I've modified the file I uploaded previously to include a "find as you type" option, in case it's of some use to you or others. This sort of method is not recommended on large tables (say, 20,000 name records), but for narrowing down a list of staff it tends to perform okay. I made no effort to "beautify" it, and in fact mostly copy/pasted from projects I've used it in without providing real specific comments on the scripts. Please ask if you have questions.
I also set the portal rows with a transparent rectangle over the top with a button action, so that clicking the yellow panel will set the name and email address into the parent record.
In another approach, I would consider adding fields to my "Globals" table (all global storage) which is always a part of my designs. I'd have fields such as "g_dept"; "g_toVisitName"; "g_toVisitEmail", etc., so that I could construct the Find criteria. I'd place these fields on a Card window (or possibly a popover depending on UI/UX needs or preferences), perform the find by script, and provide for inserting it in the registration field. I'd likely have value list for department and possibly a conditional value list for the names associated with each department. This sort of thing just depends on scale and design preferences. If departments have 8-10 staff, value lists can be manageable, if each has 100+ it gets pretty messy.
Note: I forgot that you mentioned three columns as portals. I made the sample four columns across. We'd need to tweak the calculations a bit for three to paginate correctly or use a different method.
Edit: I've replaced the file with a minor edit to a script to fix a bug/quirk. 2023-11-30
Hi, @Saeed , I noticed a bug/quirk in the pagination navigation that was caused by the modifications I did to the original file. I've edited the script that inserts the name and email to include a couple extra lines to fix it. I suggest you replace it with this newer version if you intend to play with it or consider using the method at some point.
