8 Replies Latest reply on May 29, 2017 5:19 AM by beverly

    Illegal Characters Post FM 15

    DaveRawcliffe

      I have used "¬" as a parameter in Script Parsing for 7 + years to script a tree process through to a desired result.

      "¬" has worked as recgonised and undeclared value in both the Mac & Win environment from ".fp7" up thru FM 15's ".fmp12"  as far as I can tell.

       

      I had thought "¬" worked until I caught its failure in FM 16 when I ran script debugger.

       

      Pre FMP 16: typical Script Parameter passed to Called TO's ID if TO's called ID is not known Thus :

      ____

      If Known TO::ID:

      "LayoutName|Navigate|Form|" & TO::ToID

      Else If unKnown TO::ID:

      "LayoutName|Navigate|Form|¬"

      Parsed Script Parameter "¬" produced an extractable ID

      _____

      "¬" should be available as $SP [4]

      Screen Shot 2017-05-28 at 00.22.28.png

       

      There has been major discussions over the years about legitimate usable characters: Upper & Lower case alphas "a" thru "z" and numbers 1 thru 0 with Underscore as the primary  characters allowed.

       

      With FMP 16 there are now other known (FMP 15) usable characters that have been moved to the unusable column.

      This without a know posted list of deprecated characters.

      At this point I am flying blind. Do I wait for v.1 in hopes of fix or do I bite the bullet and expend unnumberable hours revising "¬" to a specified  <unknown> value at this point through out.

       

      I would like to know how many other characters such as "¬" are now no longer recognizable & will produce false results and should be avoided.

       

      Currently this is a Major time hurt.

        • 1. Re: Illegal Characters Post FM 15
          DaveRawcliffe

          I should have noted that "," and "_" now should be used with caution.

           

          WTF

          • 2. Re: Illegal Characters Post FM 15
            beverly

            "_" should never begin anything named. And comma is a delimiter that shouldn't be in a name either.

             

            But you are primarily talking about Script Parameters? As quoted text that is passed from one script to another?

             

            Perhaps this should be a reported issue and not just a discussion?

            Beverly

            • 3. Re: Illegal Characters Post FM 15
              TomHays

              I am unclear from your post what exactly you are saying has changed in FM16.

               

              What FileMaker command produces different results?

               

              My reading of your post suggests to me that you have an expression inside a custom function that is giving different results, but you haven't provided the custom function definition to show what command specifically nor what commands are generating the passed Script Parameter sent to that custom function.

               

              Please provide a simple FileMaker expression that we can try in FileMaker Pro 15 and FileMaker Pro 16 to illustrate your point.

               

              Also provide what platform and operating system version under which you see this behavior.

               

              -Tom

              • 4. Re: Illegal Characters Post FM 15
                DaveRawcliffe

                I guess I deserve a partial “Dope Slap”

                 

                My initial query I would say should stand as a general question.

                 

                What I found was that the “¬” would not parse out in either a LeftWords or MiddleWords call.

                 

                Here is the Parsing custom function:

                Screen Shot 2017-05-28 at 09.49.49.png

                 

                After correcting the Parameter Parse:

                Screen Shot 2017-05-28 at 17.10.01.png

                 

                I now had a usable "¬" and my world had a Happy Face.

                 

                The “Best” result was that I learned something new and negate an assumption. It also caused a revisit of various scripts with a few resultant cleanups / corrections for v16.

                 

                Thanks to Beverly & Tom@

                • 5. Re: Illegal Characters Post FM 15
                  DaveRawcliffe

                  See Parameter Parse screen grab.

                  I do agree with your comment but it was a character "recognition"  not correctly implemented error

                  • 6. Re: Illegal Characters Post FM 15
                    TomHays

                    David Rawcliffe wrote:

                     

                    What I found was that the “¬” would not parse out in either a LeftWords or MiddleWords call.

                     

                    Please clarify what has changed in FM 16.

                     

                    I don't see any difference in FM16 vs earlier versions in its treatment of ¬ which is Char(172) in the LeftWords(), MiddleWords(), or RightWords().  That character is treated as a word boundary FM16, FM12, and FM11 in my quick tests.

                     

                    -Tom

                    • 7. Re: Illegal Characters Post FM 15
                      user19752

                      I can't get why your function worked on FM15.

                      "¬" is word separator on both my FM15 and FM16. LeftWords("¬";1) is nothing on both, Japanese or English index.

                       

                      Anyway I rarely use ..Words() function. It is hard to learn for me Japanese. Like

                      "ab.cd" is 1 word, but "ab1.cd" is (are?) 2 words.

                      1 of 1 people found this helpful
                      • 8. Re: Illegal Characters Post FM 15
                        beverly

                        Ditto. I also rarely use the ..Word(s) functions because a "Word" isn't always what I expect regardless of language.

                        Even this doesn't always help me, "Word separators in FileMaker Pro":

                         

                        Dave seems to have found the carbon-based error.

                        Beverly

                        1 of 1 people found this helpful