Checking for an empty ScriptParameter containing text - filemaker

I am working on FileMaker 14 and am using ScriptParameters. In my parameters I use text, not numbers. I am looking for a way to calculate whether a parameter is empty or not, but the code below returns a 0 value (false) if there is text in ScriptParameter or not:
If [ isEmpty ( Get ( ScriptParamter ) ) ]
The help docs in FileMaker do say that IsEmpty will return a value of 0 if the argument is text. So obviously I am looking for a different calculation or something. Ideas?
Thanks
GW

FileMaker's IsEmpty() function absolutely returns TRUE (1) if a text argument is truly empty. If you're getting false, there's something in your script parameter.
It looks like you might be passing multiple values in your script parameter (based on your use of the plural "script parameters"). If so, your script parameter will never evaluate to true, because of the presence of one or more carriage returns. If you need to pass multiple values, you'll need to first extract a given value using GetValue( Get(ScriptParameter); ), which gets the nth line of text without a trailing carriage return, then test the extracted value.
If that's not right (and you're only passing a single value), this likely means you're passing invisible characters in your script parameter you're not aware of. To test, you can use Length( Get(ScriptParameter) ) to test how many characters FileMaker "sees" in your script parameter. To quickly get a handle on invisible characters, you might use Code( Get(ScriptParameter) ), which will return the ASCII codes for each character. This can quickly reveal if you have spaces, tabs, returns, etc.

The help docs in FileMaker do say that IsEmpty will return a value of
0 if the argument is text.
No, that's most certainly not true. IsEmpty() will return a value of
0 if the argument is empty. If your parameter is of type text, then IsEmpty() will return 0 if and only if the parameter is a string of zero length.

Related

Azure Data Factory - Dynamic Skip Lines Expression

I am attempting to import a CSV into ADF however the file header is not the first line of the file. It is dynamic therefore I need to match it based on the first column (e.g "TestID,") which is a string.
Example Data (Header is on Line 4)
Date:,01/05/2022
Time:,00:30:25
Test Temperature:,25C
TestID,StartTime,EndTime,Result
TID12345-01,00:45:30,00:47:12,Pass
TID12345-02,00:46:50,00:49:12,Fail
TID12345-03,00:48:20,00:52:17,Pass
TID12345-04,00:49:12,00:49:45,Pass
TID12345-05,00:50:22,00:51:55,Fail
I found this article which addresses this issue however I am struggling to rewrite the expression from using an integer to using a string.
https://kromerbigdata.com/2019/09/28/adf-dynamic-skip-lines-find-data-with-variable-headers
First Expression
iif(!isNull(toInteger(left(toString(byPosition(1)),1))),toInteger(rownum),toInteger(0))
As the article states, this expression looks at the first character of each row and if it is an integer it will return the row number (rownum)
How do I perform this action for a string (e.g "TestID,")
Many Thanks
Jonny
I think you want to consider first line that starts with string as your header and preceding lines that starts with numbers should not be considered as header. You can use isNan function to check if the first character is Not a number(i.e. string) as seen in the below modified expression:
iif(isNan(left(toString(byPosition(1)),1))
,toInteger(rownum)
,toInteger(0)
)
Following is a breakdown of the above expression:
left(toString(byPosition(1)),1): gets first character fron left side of the first column.
isNan: checks if the character is "not a number".
iif: not a number, true then return rownum, false then return 0.
Or you can also use functions like isInteger() to check if the first character is an integer or not and perform actions accordingly.
Later on as explained in the cited article you need to find minimum rownum to skip.
Hope it helps.

how to remove # character from national data type in cobol

i am facing issue while converting unicode data into national characters.
When i convert the Unicode data into national using national-of function, some junk character like # is appended after the string.
E.g
Ws-unicode pic X(200)
Ws-national pic N(600)
--let the value in Ws-Unicode is これらの変更は. getting from java end.
move function national-of ( Ws-unicode ,1208 ) to Ws-national.
--after converting value is like これらの変更は #.
i do not want the extra # character added after conversion.
please help me to find out the possible solution, i have tried to replace N'#' with space using inspect clause.
it worked well but failed in some specific scenario like if we have # in input from user end. in that case genuine # also converted to space.
Below is a snippet of code I used to convert EBCDIC to UTF. Before I was capturing string lengths, I was also getting # symbols:
STRING
FUNCTION DISPLAY-OF (
FUNCTION NATIONAL-OF (
WS-EBCDIC-STRING(1:WS-XML-EBCDIC-LENGTH)
WS-EBCDIC-CCSID
)
WS-UTF8-CCSID
)
DELIMITED BY SIZE
INTO WS-UTF8-STRING
WITH POINTER WS-XML-UTF8-LENGTH
END-STRING
SUBTRACT 1 FROM WS-XML-UTF8-LENGTH
What this code does is string the UTF8 representation of the EBCIDIC string into another variable. The WITH POINTER clause will capture the new length of the string + 1 (+ 1 because the pointer is positioned to the next position after the string ended).
Using this method, you should be able to know exactly how long second string is and use that string with the exact length.
That should remove the unwanted #s.
EDIT:
One thing I forgot to mention, in my case, the # signs were actually EBCDIC low values when viewing the actual hex on the mainframe
Use inspect with reverse and stop after first occurence of #

INTEGER() of a space character(s)

Does anyone know why INTEGER(" ") is zero in Progress 4GL?
The result is same even if you pass empty string to INTEGER() function. What could be the theory around this? Please help
I have gone through the documentation but couldn't find anything about this.
It's possible that the INTEGER() function does trimming of the input data.
This simple example shows signs of trimming:
DISPLAY INTEGER("1") = INTEGER(" 1 ").
Displays yes
The spaces around the 1 is really not affecting the outcome of the conversion above leading me to think that INTEGER does trimming. Same result for:
DISPLAY INTEGER(" ") = INTEGER("").
I have no real idea as to why INTEGER("") returns 0 and not ? like for instance INTEGER("hello"). I guess it's just a matter of definition.
"Why" is a religious question...
I believe that the 4GL is probably treating a blank string like it would an empty integer fill-in. (Keep in mind that " " is equal to "" in the 4gl.)
Try this:
define variable i as integer no-undo.
i = 2.
update i.
Type a space bar. Notice how the value goes to zero?
"" is a default value for character. If you define a char variable and do not specify INIT value, it will be "". 0 is a default value for integer. So INTEGER("") is very similar to integer with default initial value, which is 0.

Behavior of Scalar::Util::looks_like_number in Perl

I am trying to find out if an input is number or string. I came across looks_like_number and cannot understand the values it returns.
use warnings;
use Scalar::Util qw(looks_like_number);
my $name = 11;
print looks_like_number ($name);
This code prints 1 if $name contains a string and a static number if $name contains an integer (i.e. 4352 for each integer).
I am using Perl on Windows.
You forgot to ask a question! Here are two possibilities.
Why doesn't it always return the same value for true?
Why not? It returns a true value as documented. It makes no difference which true value it is.
What is the value returned?
If the scalar contains a string, it uses grok_number which has specific document return values.
The type of the number is returned (0 if unrecognised), otherwise it is a bit-ORed combination of IS_NUMBER_IN_UV, IS_NUMBER_GREATER_THAN_UV_MAX, IS_NUMBER_NOT_INT, IS_NUMBER_NEG, IS_NUMBER_INFINITY, IS_NUMBER_NAN (defined in perl.h).
Otherwise, it uses
SvFLAGS(sv) & (SVf_NOK|SVp_NOK|SVf_IOK|SVp_IOK)
You can't tell which of the two was used, so you can't ascribe meaning to the value, which is why it's undocumented.
Don't rely on the exact numerical value. This is an abstraction leak, which the latest version of Scalar::Util (1.39) fixes. What is important is simply the truth of the result, not its exact numerical value.
See bug https://rt.cpan.org/Ticket/Display.html?id=94806
This is what the documentation says:
looks_like_number EXPR
Returns true if perl thinks EXPR is a number. See "looks_like_number" in perlapi.
The link to perlapi in this quote is not really helping us a lot unfortunately:
Test if the content of an SV looks like a number (or is a number). Inf
and Infinity are treated as numbers (so will not issue a non-numeric
warning), even if your atof() doesn't grok them. Get-magic is ignored.
I32 looks_like_number(SV *const sv)
In my case, your code will return an integer that is not 0, which is true.
I got 4352 when I used 11.
When I used '11' I got 1.
All of these are true, so that works.
When I put 'test' or 'foobar' I got 0, which is not true.
I never got a 1 for anything that did not look like a number.
I tried '1e1' and it printed 4, which is a true value, and the input looked like a number in scientific notation.
So, I'd say it always returns something true if Perl thinks the input looks like a number, though I do not know what exactly that true value represents. I cannot confirm that it also returns true with a name.

Perl autoincrement of string not working as before

I have some code where I am converting some data elements in a flat file. I save the old:new values to a hash which is written to a file at the end of processing. On subsequence execution, I reload into a hash so I can reuse previously converted values on additional data files. I also save the last conversion value so if I encounter an unconverted value, I can assign it a new converted value and add it to the hash.
I had used this code before (back in Feb) on six files with no issues. I have a variable that is set to ZCKL0 (last character is a zero) which is retrieved from a file holding the last used value. I apply the increment operator
...
$data{$olddata} = ++$dataseed;
...
and the resultant value in $dataseed is 1 instead of ZCKL1. The original starting seed value was ZAAA0.
What am I missing here?
Do you use the $dataseed variable in a numeric context in your code?
From perlop:
If you increment a variable that is
numeric, or that has ever been used in
a numeric context, you get a normal
increment. If, however, the variable
has been used in only string contexts
since it was set, and has a value that
is not the empty string and matches
the pattern /^[a-zA-Z][0-9]\z/ , the
increment is done as a string,
preserving each character within its
range.
As prevously mentioned, ++ on strings is "magic" in that it operates differently based on the content of the string and the context in which the string is used.
To illustrate the problem and assuming:
my $s='ZCL0';
then
print ++$s;
will print:
ZCL1
while
$s+=0; print ++$s;
prints
1
NB: In other popular programming languages, the ++ is legal for numeric values only.
Using non-intuitive, "magic" features of Perl is discouraged as they lead to confusing and possibly unsupportable code.
You can write this almost as succinctly without relying on the magic ++ behavior:
s/(\d+)$/ $1 + 1 /e
The e flag makes it an expression substitution.