1) To put "new text" between line1 and line2 of this text:
Leftvalues ( YourField ; 1 ) & "new text" & ¶ & RightValues ( YourField ; 2 ) // but this adds a trailing ¶ that you can remove as a final step.
2) GetValue ( YourField ; 2 ) will return "line2"
Thanks Phil. Just what I needed.
I've started a FMP database where I just store important tips, like the one you mentioned above.
Quick Question: Do you think FMP will ever become object oriented with its 25-year roots as non OO?
As you know, a non-OO is the older model where you have functions over here and data over there and you connect them in your program. The OO model is where the code and (private) data are in the same object (class) so you immediately know what functions (methods) are available for any object. Plus, at even higher levels of abstraction, FMP could use the same "interface" (method/function names) across related classes for related objects so the user/developer has the same calling syntax.
The details are then handled behind the scenes. If the particular class (for example, "Perform Find", which creates a "data set" of sorts) has the same defined behavior as ExecuteSQL, then they both would have the same calling functions (like next, previous, first, last, etc.). FMP would 'abstract' how this works so the developers (us) have a consistent calling syntax and we don't have to be inundated with FMP's implementation details and constantly struggle with how "this" is different from "that". This is a big deal.
If you look at other products with "property sheets" and inheritance, I think the argument for an OO approach is compelling. Instead of endlessly searching for some "function" in the tiny separate not-really-connected-to-what-you're-doing search window, you can immediately see, via property sheet or other, what "functions" work with this "object" (the object being a text field, a query, or whatever).
In traditional programming languages like Java or .NET (C#, for example), you type in an object name and type "." after it and you see all the available methods (functions) for that object. Very nice. While I wouldn't expect the "." notation in FMP given its current script approach, a property sheet approach wouldn't be out of the question.
Ease of use and consistency would be two benefits from an OO approach.
For example, with the recent ExecuteSQL question I posted....if every database operation had the same "Interface" (supported the same callable functions), then they would all support the same "behaviors". The FMP programmers (the developers of FMP itself, I mean) would, of course, need to create the code to make it work, like any programmers, but the actual FMP users/developers could expect the same calling syntax (via scripts) to work for any "data set" or related object.
I'm guessing, however, that FMP will, instead, just keep globbing on new features, release after release, as seems to be the model in software these days, and won't do anything revolutionary. Plus, (and I don't know if this is true) it's possible that there is so much historical code FMP legacy code logic that perhaps few at FM, if any, understand all of it. Thus, any change may be difficult to this really old code base.
P.S. I'm constantly trying to figure out just who uses FMP. If you look at the FileMaker Today Web site, there are only a handfull of developers shown on the "Find FMT Preferred FileMaker Developers & Services" map.
I don't work for FileMaker and don't have any special pipeline into what a future version of FileMaker will become. Your guess is as good as mine.
Yes, I know. You've said that before. :)
Not really my point, however.
I was just knocking around some ideas.
But it's the question that you asked me (again) and so I have the same answer for you again.