Mass change of field source in layouts

I have a layout with several fields. I have created a new TO in the graph, and would like to change the table referenced in the field layout to the new TO. Is there a way to do this for multiple/all fields at once?

Other than double clicking each field, I’m afraid not. This has been on our wish list for about 30 years.

2 Likes

You could copy the layout object, convert it to XML text, replace the table occurrence, copy XML, convert back to a FM object, and paste back in.

We keep a utility tile that does this kind of stuff for us.

7 Likes

apart from using an utility this could be done via MBS of course :slight_smile:

2 Likes

I like using Clip Manager for this. I believe there are many tools that let you do this. You could build your own just with the BaseElements plugin.

Note: I do not use the Windows version of Clip Manager. Here are the links:

5 Likes

Both BaseElements plugin and MBS can do the conversion piece.

I'm wondering if Developer Assistant might help also...

In the past, I've used a copy paste approach.

Whether or not it will be feasible for your layout is an open question.

The steps that I use.:

  1. Try this out on a duplicate copy of the layout, in case anything goes haywire. Whatever you do, please definitely practice on a copy of the layout.

  2. Rename the TO that you want to un-hook up to something very simple to type. For this example, let's say I just rename it to the letter "X".

  3. Group all of the layout objects together into one object.

  4. Copy entire huge grouped object to the clipboard, and then delete it from the layout. (Or use the Cut editing command to achieve the same).

  5. Rename the old TO that you are detaching from to any other available TO name.

  6. Rename the new TO that you want to hook up to "X".

  7. Paste the giant grouped object back onto the layout. When you paste it back, the fields that were previously attached to the "X" TO will re-attach themselves to the TO named "X". This is true even though the "X" TO is actually a different TO than it was before the Copy/Cut. (This is due to the renaming in step 6).

  8. Save the layout changes.

  9. At this point, i.e. once everything has been pasted back into the layout, you can go and rename the new TO to whatever you would like.

EDIT: Originally I left out an important step above -- just added it in. Apologies!

Some comments:

  1. The key here is that the field objects on the clipboard are aware of the TO name at the time the objects were copied. When you paste back them back in, they reattach to their remembered TO name, even though you have swapped TOs while the field objects were on the clipboard. Since they attach by name, they will attach to the new TO if you have properly renamed the new TO to what the clipboard data is expecting (in the example above, "X").

  2. Renaming the TO to "X" isn't absolutely necessary. As long as you understand the concept behind this, you don't have to do the "X" rename. You still have to do TO renaming, but "X" doesn't have to be part of the process of swapping names. The only reason I added this step (and apologies if it made things more mysterious) is that when it comes time to rename the new TO, typing "X" is an easy proposition, and it prevents one from having to type a potentially long TO name, and it removes the temptation to copy a long TO name (recall that Copy is forbidden at that moment, because we need to keep the field objects on the clipboard, and so we can't use Copy).

  3. I note that there are a good number of recommendations to use a utility for this. Since I've already typed this up, I am going to leave it -- partly because I think it is helpful information to see and understand. But, having said that, I would say that using a utility is probably a more "professional" way to handle this - if not professional, at least more elegant, and less hack-like.

4 Likes

Can you explain how to accomplish this conversion back and forth to XML of an object for the less advanced of us here...

4 Likes

@cpking @Cecile @AndyHibbs here's one easy way to do the conversion back and forth. It uses the Monkeybread plugin (no license needed for this function), but as others have said, you can use BaseElements plugin too, or my preferred method of AppleScript + TextExpander/Typinator.

This example uses this free utility file to do the conversion: Download Zip or View on Github

6 Likes

I don't think Developer Assistant will work for modifying layout objects because it says "Find not possible in focused control." for layouts:

Interesting, thanks. It was just an idea I hoped might help. If it were just table fields, you could use DDL commands.

1 Like

I use FM Pastebox by Karsten Wolf (Mac only). It does essentially the same: grab the clipboard as XML and push it back to filemaker, after you did some searching and replacing.

On Github: GitHub - karstenw/FMPasteBox: FMPasteBox is a OSX FileMaker Clipboard translator.

2 Likes

Interesting to read how many Mac tools there are for this and how few Windows options. We always wonder how many Windows developers there are out there, as we report bugs and always think ‘surely other people have this same problem’, the most recent being last week. This remains something we believe FileMaker should offer as a built in standard.

6 Likes

+1
Yes!

If feasible (company policy allows for it), developing on Mac and testing on Win for Win clients seems to be the best comprise.

3 Likes

This is really helpful, and worked beautifully. However, I did get an MBS message that it was unlicensed.

@Cecile If I get time today, I'll try to clean up the file we use ( remove some NDA stuff I can't share ), and post it. It has a couple other tools that do some specific tasks in our dev process where we may need to convert a set of script steps to a JSONSetElement or JSONGetElement, etc.

5 Likes

Andy, this old poll had 55 fmSoup members answer about their preferred platform for FileMaker development. Roughly 9 out of 10 prefer mac.

When going to DevCon, people and speakers have mostly macs. From there, I think there are 2 things that give this snowball effect: most tools we see surfacing come from a developer building the tool for themselves and making it available to a larger crowd with the least effort. If someone wants to commercialize a product, they will try having something crossplatform, but if this is somewhat challenging, it could very well be that it will be done only for one platform instead and that is influenced by 2 things I can think of, technical limitations of a platform over another and reaching the largest number of developers on the platform they use.

I develop on mac. Clients mostly use Windows machines. Client will report bugs they see on Windows, but if it is something that would only impact a developer, they won't report that.

Interestingly, with the webviewer layout object, there is also a great deal of disparity between windows and mac. Now that we can expect more addons to use interract with webviewers, I'm glad to hear that Claris is working on putting Edge in the webviewer for
windows instead of IE.

1 Like

100% agree would be great if built in.

If you’re looking for a nice Windows tool in the meantime that does not require plugins or filemaker files then this one is great: GitHub - dansmith65/FileMaker-PowerShell-Clipboard: Manipulate FileMaker formatted clipboard formats with PowerShell.

Dan, the author, uses it + autohotkey to convert back and forth as well as paste in saved script snippets.

1 Like