Leaderboard

Here are just 2 ideas that spring to mind: Let ( [ lastChar = Right ( Trim ( text ) ; 1 ) ; lastPos = Position ( text ; lastChar ; Length ( text ) ; -1 ) ] ; Left ( text ; lastPos ) ) or: Let ( tmp = Trim ( "a" & text ) ; Replace ( tmp ; 1 ; 1 ; "" ) )

You can construct the calculation along the lines of: List ( "image:Photos/" & ArtistName & ".jpg" ; "image:Photos/" & ArtistName & ".png" ) This will create both paths as a return-separated list. The container field will then go over this list and display the first image it can find.

MBS Plugin 14.2 was Released today: Your function wish is included: Text.LeftTrim Trims whitespace on the left side. All ✅ Server Text.RightTrim Trims whitespace on the right side. All ✅ Server

Like this - although I think Michael is right about his calc's sansrepeaters.fmp12

Well, see what you can get from the temple I used for getting my thoughts straightened: --sd Untitled.fmp12

Define a repeating calc field with 9 repeatings, containing this: Let( [ tsf = Extend( TotalSchoolFees ); ef = Extend( EnrolmentFee ); ss = Extend( Scholarship ); rg = Round( Div( tsf - ef - ss; 9 ); -2 ) ]; Case( Get( CalculationRepetitionNumber ) - 1; rg; tsf - 8 * rg - ef - ss ) ) Imports from internal tables allows then to split each repeater out into individual records, in a related table, but today with the fm20 "Layout calculation" would I perhaps use the portal row number instead of Get( CalculationRepetitionNumber ) and then get rid of the Extend( shenanigans. Then would only data in the portalized just have one single boolean field, with a checkmark.... --sd

My preferred location is inside a script, using the Insert Text step to populate a variable. This is especially convenient for storing non-native code (such as SQL, AppleScript, HTML, Javascript, XSLT etc.) without having to escape it.

I'll add it to the plugin for you: Text.RightTrim and Text.LeftTrim functions.

As you can see in the help: https://help.claris.com/en/pro-help/content/paths-in-server-side-scripts.html

I am not sure why you have an EmployeeIDs field in the Days table. Or why you need the Days table at all. I think you should have a calculation field in the DailyHours table that calculates the date of the previous calendar day. Then construct a self-join matching the calculation field to the Date field and EmployeeID to EmployeeID. Then you can subtract the 2 values. Added: The above assumes that the date to compare to is always the previous calendar day. If that's not true (for example, if a violation can occur when someone worked until very late on Monday and started again on Wednesday, or when someone logged twice on the same date) then you will need a slightly more elaborate method: Calculate the start and end timestamps of each entry. Define the self-join relationship as: DailyHours::EmployeeID = DailyHours 2::EmployeeID AND DailyHours::StartTS > DailyHours 2::EndTS and sort the DailyHours 2 by EndTS, descending. Then subtract the 2 timestamps.

It seems to me that it is the field that has the purple color, not the portal row? If so, you could apply conditional formatting to it, using [Value is] [empty] as the condition. --- This has nothing to do with the portal row being active or not.

Or ....use both, since the ExecuteSQL does not know of found sets, you often gather a list of ID's in a $$ variable, and loop thru each ID building native request upon request and make a final perform find. Using a new window and issue say a selfjoin GTRR(FS) in it, and then stuffing list of summaries into a $$ could mimic this approach ... by remembering to close the extra window just in time. --sd

We have nothing to base an answer upon. Are you sure you performed a find on the current layout in the current window during the current session? Perhaps Constrain Found Set would be a better choice for this purpose. https://help.claris.com/en/pro-help/content/constrain-found-set.html

The ORDER BY clause should come at the very end. But there is a problem here: The sort will be applied to the entire result - including the "Total" line produced by the 2nd SELECT statement. If it starts with a ¶, it will be sorted to the top. If it starts with a "T", it will come before "Vision". You could try and prepend a control character to force it to be the last - for example, this seems to work in my test: ExecuteSQL ( "SELECT Department, COUNT (*) FROM Staff WHERE Status = 'Active' GROUP BY Department UNION SELECT CHR(127) + '¶Total', COUNT (*) FROM Staff WHERE Status = 'Active' ORDER BY 1" ; Char (9) ; "" ) However, I would rather make 2 separate calls to the ExecuteSQL() function and combine the result using the FMP calculation engine. And of course, if you can produce the same result using a FMP native report, that's always preferable.

Because Claris did not bother to add an "event listener" to monitor variables like they have with fields: OnPanelSwitch_Modified_Again.fmp12

Without knowing exactly what you did, we can only guess. I don't like guessing. Take apart the attached demo file and see if you can spot what's missing in yours. OnPanelSwitch.fmp12

According to the help, the Install OnTimer Script script step is supported in FileMaker WebDirect.

wow! such a quick response; thank you all for your feedback and for sharing your discussion on this topic. some of this needs time to digest to better get my head around the terms and principles involved and thereby appreciate the nuances involved; the posted 'example' file helps with that effort. the remark by bcoony prompted me to review the 'definition' of my newly added field which I had set as type 'numeric' and then I applied a calculation expression to it that yielded the attendent behaviour that was problemmatic for me on this occassion. I decided to change the field type to 'calculation' and for it to yield a 'numeric' result, this has now resulted in the record(s) updating and displaying their value(s) as I require. It would seem that I had 'my horse and cart' configured contrary to my intended requirement/result. in summary, setting a field as type 'numeric' then applying a calculation parameter to it leads to a behaviour that is different to a field set as type 'calculation' then defining its output as 'numeric'. as my understanding and knowledge of this software deepens I feel I'll be able to take on-broad and better appreciate some its nuances discussed above, for now my issue is resolved. your prompt feedback, comments and support are all gratefully appreciated. regards & best wishes, yoyojoe

This is one example that I built.

I am afraid I don't know. I would try removing some or all of the top 3 options, but that's just blind groping. If you cannot make it work through the native Insert from URL step, try the BaseElements plugin: https://docs.baseelementsplugin.com/article/517-behttppost

Hm, what a strange thing indeed. I have never seen such thing, and I would have to run another test or two to be sure, but this is my preliminary diagnosis: Your values are very long, and some of them are identical to others except for a few words at the end. For example, the values under General and Transmission are identical for the first 767 characters. Filemaker indexes only the first ~100 characters. If you look at the field's index, you will see that there are only 3 entries that start with "(COVID 19" - although there are 8 such values. So what probably happens is that when you select Transmission, the correct value is entered into the field - but when Filemaker looks for the corresponding label, it finds General and attaches a check mark to that. I would suggest you use IDs as the values to enter into the field and use a relationship to get the long descriptions. Or (if possible) make sure that the differences between the descriptions occur within the first 100 characters.

I see no difficulty in going to the related table and creating the records there. Sometimes it is easier to use a relationship, but the difference is minute, not "infinite". If there is a need to show a portal based on the same relationship, I would much rather add a few steps to the script than muck around hiding the objects in the portal.

I am not able to reproduce this behavior. If you put the list in a global field, you can then use a relationship matching the global to the primary key to go to related records. I am not sure what exactly you are doing (and why), but perhaps you could simply open a new window before performing a new find? Then you will be able to return to the previous found set just by closing the new window.

Hello Everyone, I am trying to construct a pedigree tree/chart out of parents and pedigrees for a number of generations in a plant breeding work. Any ideas how to approach this in filemaker or should it be done in JS? Thanks for any suggestion.