Thank you for your post.
I am able to replicate the issue. The "¶" return characters (ASCII-13) change to ASCII-10 (line feed) characters once the current script has finished. This is why the PatternCount function fails for "¶", and why it will still work as an array. I have forwarded your post to our Development and Testing departments for review. When I receive any feedback, I will let you know.
As a workaround, use: PatternCount ( $$globalVariable ; Char (10) )
The pilcrow (ASCII 182) is a symbol representing a paragraph. But what
is a paragraph? That depends on the operating system, doesn't it. And
because of this inherent ambiguity the pilcrow has been used within
FileMaker Pro to provide semantic equivalence between different computer
platforms which use different encoding to generate a paragraph.
The paragraph is of particular importance in FileMaker programming
because it represents an item in a list. The pilcrow should be the
standard definition of a record delimiter in a list.
Shouldn't we be able to use the pilcrow in that way, that is, we should
be able to use it to represent a paragraph, which may be CR, LF or CRLF?
And if the programming team chooses to use LF behind the scenes,
shouldn't we be able ignore the gory details and use the pilcrow?
Thanks for the workaround suggestion TSGal. If I have some guys still using FMP12 on our network should I go with:
( PatternCount ( $$globalVariable ; Char (10) ) ) + ( PatternCount ( $$globalVariable ; Char (13) ) )
Your workaround works under Mac OS X 10.11.3, Windows 7, and iOS 9.2.1.
Testing is able to replicate the issue. The information has been sent to Development for further review.
You are all over it TSGal. Thanks for the quick replies.