Defining Field Values Behind the Scenes

[brents]

Greetings all! I'm admittedly quite "green" when it comes to FileMaker, but I do have 15 years in application development in a variety of different languages, primarily geared towards web application development. That said, I have what I would consider a fairly common scenario and I'm struggling a bit with the best way to implement a solution in FM. Basically I have a "file" table and a "file_type" table. The two tables are related by the file type relationship. Currently I have two file types, "documents" and "files".

Now, within my layout I have a tabbed interface. Included are tabs for "Documents" and "Images". Each of these tabs contain a portal to our "files" table. I would like to set the "file_type" field value behind the scenes, depending on which tab the user has clicked on. So, depending on the tab selected, the returned records would be filtered by file type and any files uploaded would also be inserted with the appropriate file type.

I'm just not sure of how to do something like this in FM. My thoughts would be to set a value to a variable when the tabs are selected. I would then set the value of the "file_type" field to this variable value upon some event. I'm just not sure which event. Maybe I'm not even on the right track at all. I appreciate any guidance.

Thanks!

Edited January 9, 2016 by brents

[jp98]

i'm as knew as you and i don't have the 15 years in application development but i think i might be able to help you to a certain degree here. based on what i found out from toddgiest from stackoverflow (might pay to check out his answer to someone elses question here ) you can set a value/name for each tab by double clicking on the tab (should bring up black border around it) and then in the inspector under Position, enter the name of the tab in the name box at the top. then click the other tab and do the same. you can then use the Get (ActiveLayoutObjectName). i will have to let someone else help you more as i am quite busy right now, but if in the portal you go filter records and specify and then use Get (ActiveLayoutObjectName) = "Documents" or whatever there it should work i think.

[Kris M]

Look into the OnPanelSwitch trigger and the Get ( TriggerTargetPanel ) function to respond to changes in the tab selection.

if trigger target panel is 1 then do a find for the doc type if tab 1 is for documents

if trigger target panel is 2 then do a find for the image type if tab 1 is for images

Edited January 9, 2016 by Kris M

[jp98]

just thinking about it a little bit more - if you have a separate portal on each tab, just set the filter so that in the portal on the documents tab, filter is set to file_type::file_type = Documents and for the one on the images tab it is set to file_type::file_type = Files. however, this will only work if you have a separate portal on each tab (which is simple enough to do but if you change any styling you will have to do it to both tabs which can become a bit of a pain once you start getting more tabs.) and this will also only work for filtering the returned records - you will have to use the formula Get (ActiveLayoutObjectName) to set the file_type for new uploads - possibly in a script with the set field command or whatever it is.

 

[Kris M]

As jp98 mentions there are other way to accomplish the same feat.

Reproducing a web experience is not always the best way (for the users) to do things with FM

I would question the reason you want to use a tab control in the first place.

[brents]

Excellent, I appreciate the replies.

I ultimately went with a hybrid solution. I named the tabs accordingly (e.g. tabDocuments, tabImages), then using the "OnPanelSwitch" trigger, I set a global variable ($$CURRENT_FILE_TYPE) to either DOCUMENT or IMAGE, depending on the value returned from Get(TriggerTargetPanel) ; 2 ).

I setup my "fileType" field as a calculation, getting the value of the global variable ($$CURRENT_FILE_TYPE), defined in the tab trigger. Ultimately I ditched the "file_type" table altogether. May change my mind on this though.

This took care of setting the "file type" on file upload. For the filtering, I used the recommended "filter" option within the portal setup. Easy enough.

Thanks again!

3 hours ago, Kris M said:

Reproducing a web experience is not always the best way (for the users) to do things with FM

Completely agree, although I never said I was trying to reproduce a web experience.

3 hours ago, Kris M said:

I would question the reason you want to use a tab control in the first place.

Okay, also not very helpful. Would you mind to expand on your concern with me using a tab control in the first place.

[bruceR]

" Would you mind to expand on your concern with me using a tab control in the first place."

I don't know what Kris had in mind.

But how about just having one portal; and a global selector field to switch type.

Your current method seems more complex than necessary. If you retain the tab, consider that there is no need for all the trigger and global variable business.

The portal on one tab would be "hardwired" to filter by document; the portal on the other tab would be set to filter by image.

What else differentiates the tabs? Are there other things going on, such as an image thumbnail?

[brents]

1 hour ago, BruceR said:

But how about just having one portal; and a global selector field to switch type.

What else differentiates the tabs? Are there other things going on, such as an image thumbnail?

Great question, and maybe what Kris was after as well. I went with a two tab setup (one for each file type) per the design guidelines of the application. No other reason. These two tabs are merely a part of a series of tabs in the overall design. You're absolutely right, a single "files" portal (for example) with a "filter by file type" option would functionally achieve the same desired results. But the design guidelines given to me require a two tab setup. I see now why one might raise the question of using tabs.

That said, I'm not entirely happy with the solution I ultimately implemented. It's what I like to call "fragile code" in that it can easily be broken and is certainly more bug prone when looking at the application as a whole. I'm not thrilled with defining the file types within a script vs. in a more manageable and flexible place like a "file_types" table. I'm confident there is a better way of engineering this. This would be a nightmare to manage in a bigger application.

Thanks for the feedback! Hopefully this explains the setup a bit more and the method to the madness

[bruceR]

Again, if you stick with the tabs, no need to do it as a fragile solution. You can "hardware" the portal design.

[brents]

On 1/10/2016 at 8:25 PM, BruceR said:

Again, if you stick with the tabs, no need to do it as a fragile solution. You can "hardware" the portal design.

I'm not sure I'm following I guess. By "hardwire" the portal design, are you referring to your previous comment regarding the filtering of records? I've done that I believe (see attached screenshot). Which works great for getting files out of the database, however, I'm not sure how to "hardwire" anything within the portal setup that would take care of adding files to the database. Likely my inexperience with FM showing through here, but I'm just not quite following I guess.