comment

Try something like: "data:text/html, <img src='http://s3.amazonaws.com/photos.ecarlist.com/egWK/Z0og/ECQk/1XB9/I4Zn/vw_640.jpg' style='max-height:300px; max-width:400px;'/>" See if this helps: https://support.filemaker.com/s/article/Web-Viewer-renders-blank-in-WebDirect?language=en_US

Depending on what exactly you want your solution to do, you may not want to use repeating fields to store data. In the current example, the field is used mainly for display and, if necessary, the actual data could be stored elsewhere (figuring how exactly would be an interesting challenge). You can use conditional formatting to set the fill color to black (or rather a darker color, if you want the black pieces to remain visible) when: Let ( [ i = Get( CalculationRepetitionNumber ) - 1 ; row = Div ( i ; 8 ) ; col = Mod ( i ; 8 ) ] ; Mod ( row + col ; 2 ) ) There is only one version 18. It becomes Advanced by setting an option in Preferences. The FMP client runs only under Windows and macOS.

I wasn't able to reproduce the claimed behavior (using v.18). Copying a script that contains a Set Field By Name [] step with no target field specified and pasting it into another file results in a Set Field By Name [] step with no target field specified - exactly like in the source file. BTW, if you don't want to specify the target field name, why not simply use the Set Field [] script step.

See if the attached demo helps: Generatelabels.fmp12

Earlier I was confused by your saying: But in fact you do NOT want to change the aspect ratio, so that's not a good reason why the GetThumbnail() function wouldn't work for you. I might be reluctant to use it for reasons of image quality, but if this is for on-screen display only (and there is no requirement for a hi-res on-screen display), it can work. There should be no problems with this because the target size (or rather the size limits, if you're using the GetThumbnail() function) can be calculated using the source image dimensions as the input. These dimensions can be retrieved using the GetHeight() and GetWidth() functions as well as the GetContainerAttribute() functions. If you like, you can make this completely dynamic by giving the target container an object name and getting its dimensions via the GetLayoutObjectAttribute() function. Then the calculation can automatically adjust the size to fit the size of the target container on the current layout (but then it must be unstored). I would be careful with that. Resizing an image results in permanent loss of quality.

The two are not mutually exclusive: auto-entering a value works at the data level and isn't affected by how the field is formatted on a layout (note that the same field can have multiple instances placed on multiple layouts).

Filemaker does respect the transparency of an image in a container field. However, the JPEG format does not allow for transparency. Try using the PNG or the GIF format instead. I would use a single field with 64 repetitions. And I would use a Text field, with Unicode characters in the range of Char ( 9812) to Char ( 9823 ) representing the pieces: ♚♛♜♝♞♟ ♔♕♖♗♘♙ If you want to show a succession of moves, you should have a related table of moves. Then a script that executes the moves one by one, with a pause in-between them. To move a piece, make your script set the target field to the source field, then set the source field to empty. Also make sure you have a way to restore the initial state. -- P.S. Please update your profile to reflect your version and OS, so that we know what you can use.

You cannot keep in it FM - but perhaps you can use a plugin, e.g. https://baseelementsplugin.zendesk.com/hc/en-us/articles/206609078-BE-ConvertContainer Without this, you would have to process the images in an external application and store the results in additional container fields.

Perhaps you can use a web viewer to display the image. IIUC, setting the CSS object-fit property to cover should achieve the requested resizing. https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit

An XSLT stylesheet is a plain text file that can be created using any text editor. You need to be familiar with the source and target XML schemas and have at least a basic knowledge of the XSLT language (try perhaps the tutorial here). You also need a testing environment - either of your own or an online one such as this). There are also numerous examples of import and export stylesheets posted here, mostly by Fenton and by me.

You can do your own formatting within the calculation, for example: Let ( [ n = If ( $$NoGPABump = 1 ; Classes::GPANoBump ; Classes::GPABumped ) ; r = Round ( n ; 2 ) ] ; Int ( r ) & SerialIncrement ( ".00" ; 100 * Mod ( r ; 1 ) ) ) Note that this assumes the number is not negative - otherwise the calculation needs to be a bit more complex.

I am afraid I don't see the connection. I believe the topic is XSLT. If you have a situation where you need to choose which XSLT stylesheet to apply during the import from a "library" of existing stylesheets, there is a solution. However, I believe such situations are very rare, because usually it's not only a matter of selecting the stylesheet, but also the target table - which cannot be selected dynamically. So you would have a script (or a script step) for each type of import - and the path to the appropriate stylesheet would also be stored there. I recommend you adopt this approach instead of trying to import everything and anything into a single flat table.

What problem would it solve for you?

Under certain assumptions (which I hope will be self-evident), you could something like: Check if the last line matches the pattern of "@@ #####"; if yes, set the Country field to USA (or leave it empty?), the State field to the first word of the last line, the ZIP field to the second word of the last line, and the City to the entire line before last . Otherwise , set the Country field to the entire last line. If the last line is "Canada", parse the line before last as follows: the last 2 words (or 7 characters) go to the ZIP field, the 3rd word from right is the State, and the rest is the City. If the last line is something else, then we don't know how to handle the line before last. Now we need to look at the remaining lines: if there are 2 remaining lines, then the first of them is Owner1 and the other one is Address 1. If there are 4 of them, then the first 2 are owners and the other two are the address. If there are 3 remaining lines, then check if the 2nd line begins with a digit character (or with a word that consist of digits only?). If yes, then there is one owner and two address lines, otherwise it's two owners and one address line. The problem with this approach is, of course, that if will fail colossally when any of these assumptions is not true, as well as the missing instructions for countries other than USA and Canada. So at best it can serve as a first draft for human review.

I don't think it's possible to automate this process without introducing some additional rules that are not apparent from the given examples. I notice that the last line can be either the country or the (US?) state and ZIP code. We need a way to determine which one it is - perhaps we can assume that if the line contains any digits, it is the latter? Next there is the problem of deciding whether the 2nd line is owner #2 or the street address (this is assuming that the number of owners is always either 1 or 2). I don't think a computer is able to look at "ANYUSER MELANIE & JANINE" or "C/O THE RICK AND MEL TRUST" and make this decision on its own, without some helper rule. Finally, the line "COLDSTREAM BC V1B 3W8" is going to be very difficult to parse into city (which can be more than one word), state and ZIP without some additional rules to determine where the city name ends and where the ZIP code starts.