Using Variable for Table Name in Set Field

[mdfOffman]

I have made a Card Window to select a document number to assign to a foreign key in another layout.  It works perfectly if I specify the table name from which I am searching

e.g. Set Field [PartyDoc::fkDoc ; $Doc]  or Set Field [ProjectDoc::fkDoc ; $Doc]

But I want to be able to select from multiple layouts that all have "fkDoc" field

So I want to say Set Field [ Get(LayoutTableName)::fkDoc ; $Doc]  but it won't let me do that even with Set Field By Name

How do I achieve this effect?

[comment]

You should be able to do:

Set Field By Name [ Get ( LayoutTableName ) & "::fkDoc"; $Doc ]

Whether this is a good arrangement to have is another matter.

Note that unlike a "regular" Set Field[] step, this will break if you rename the fkDoc field in the target table/s (there is a way to protect against that - but it's a lot of work and probably not worth it).

 

Edited February 5, 2023 by comment

[comment]

I have given this some more thought, and I believe the best approach to take here is to make your script do:

Set Field By Name [ Get ( ScriptParameter ) ; $Doc ]

Then, when you call it from the PartyDoc table, define the script parameter as:

GetFieldName ( PartyDoc::fkDoc )

and from the ProjectDoc table as:

GetFieldName ( ProjectDoc::fkDoc )

and so on.

This way you get to have your cake (have a single step that serves all target tables) and eat it (can change the target field names without breaking the script) too.

 

Edited February 5, 2023 by comment

[mdfOffman]

Thank you once again for all your help.

With a bit of a struggle, I managed to work out how to achieve the text you suggested and it works perfectly when called from a main layout but does nothing when called from a portal even though a Custom Dialog shows that it is correctly reading the Layout Table Name.

So for the moment, I am stuck with an If and a whole bunch of Else Ifs which do work when called from a portal!!

I like your latest suggestion very much but it's going to take me a while to find the time to explore/test it.

[comment]

2 minutes ago, mdfOffman said:

does nothing when called from a portal even though a Custom Dialog shows that it is correctly reading the Layout Table Name

I may be misunderstanding the situation you describe, but if you want to set a field inside the portal, then you cannot use Get ( LayoutTableName ) to construct the field's name. The field in the portal belongs to the portal's table (or possibly to a third table), not to the current layout's table.

 

[mdfOffman]

Yes, that's what I suspected.  But your comments made me realise that I had omitted a critical part of the table name.

I have strict naming conventions, so this works perfectly from all the portals:

Set Field by Name [Get(LayoutTableName) & "Doc::fkDoc" ; $Doc]  

You may consider this amateurish but it works just fine so I shall stick with it till I can afford to engage professionals :-)

Thank you again for your guidance that leads me to solutions

[comment]

3 hours ago, mdfOffman said:

You may consider this amateurish

I consider it bad practice to make things unnecessarily depend on each other. This applies equally to hardcoding the field's local name as well as to deriving the table name.

I don't think it should take you more than a few minutes to implement my earlier suggestion.

 

[mdfOffman]

I hear the wisdom of your experience.  I'll have a go :-)

 

[bcooney]

This is exactly the use case where we use this technique. https://www.proofgeist.com/blog/2022/06/24/building-a-modular-picker-with-an-ontimer-script

[passando]

It seems bad programming practice but, in this case, you could hardwire the table name into the field definition. That would cope with the situation where you are not in the parent table concerned.

You could still set a variable to the table name but it would need to be $$ variable.

[comment]

@passando I believe you are thinking of a scenario that's fundamentally different from the one OP described.

 

Edited February 7, 2023 by comment

[mdfOffman]

Dear "Comment"

I've been meaning to thank you for some time but been too busy getting it done!  Your proposal about using a parameter for the Select script works a treat.  To be transparent, I was nervous about it because I had not used parameters before and I wasn't sure how to carry the parameter through to the next script that inputs the selected record.  When I learned I can make a global variable as the first step in the script, it all came together.  Obvious when you know, intimidating when you don't yet know!!

It's just amazing what an amateur like me can do with Filemaker and much of it depends on the free help and training from you guys and girls.  Thank you so much.

[comment]

3 hours ago, mdfOffman said:

how to carry the parameter through to the next script that inputs the selected record

Do you really need two scripts for this? Can't you pause the original script and resume it upon selection?

 

3 hours ago, mdfOffman said:

I learned I can make a global variable as the first step in the script,

The issue with global variables is that if you don't take care to destroy them as soon as you're done with them, they hang around until the end of session. And if you're not extra careful with their naming, they can collide with another variable of the same name defined for another purpose.

 

[mdfOffman]

Providing a table name as a parameter works just fine.  And using a single script with a pause instead of 2 scripts also woks brilliantly.  No global variable needed!

Thank you yet once again.  What would I do without you guys & gals? :-)