In making my correspondence file, I see how to add prefix and suffix elements to a value - For example, If i want to print
-200 = 98%
where 98 is the value and -200 and % are the prefix and suffix respectively. (It is bolded here just to highlight what i want to print)
My correspondence element looks like this
<<HasData(<<TEST_RESULTS.M200>>,-#200 = <<TEST_RESULTS.M200>>%)>>
Works fine and gives this formatted output
What I want to do is print something like this:
PP= , -200 = 98%
How do I specify that comma??, I can get the PP =, to print but can't seem to get that desired comma to print. I tried putting it in direct - no joy, I tried "," no joy, tried "","" still no joy.
<<HasData(<<TEST_RESULTS.M200>>,PP = , -#200 = <<TEST_RESULTS.M200>>%)>>
My result is simply
It "breaks" on that comma delimiter, thinking it is a control character instead of a literal? Looks like the comma by itself is reserved for code control.
I meant :
.... can get the PP = to print, but can't seem to get that comma or any of the remaining information/data to print.
There is a function specifically designed to add a prefix and/or suffix around a field. They will only be added if the field evaluates to true, in others words there is an implied Has data.
It is the DelimitData function. To see syntax and usage examples in gINT goto Help ...functions booklet and find DelimitData. or just search for it.
Commas are part of most functions syntax so if they are part of the prefix for example surround the prefix in quotes. Here is a very generic example based on what you showed.
<<DelimitData("PP=, -200 = ",<<TEST_RESULTS.M200>>,%)>>
Not sure how PP relates to the M200 field, but I am strictly speaking on syntax only.
MISSING RESOURCE: VerifiedBy Art Koenig
You're the man! I had looked at the DelimitData but missed its structure.. I certainly did not even catch the implied HasData aspect. Thanks for that for sure too. As to the conflation of items .. yes, I have a user that was wanting such a mongrel of PP data and -200 data in a comments field ( because THAT is what his government client wanted), and after experimenting I will gently counsel that code with database features can do superhuman things BECAUSE of an apparent-to-the-consumer rigid architecture - and that from the database side of the "kitchen rules", you just can't go putting spoons in the knives drawer. Spoons go in the spoons drawer, and knives go in the knives drawer. I will also let him know that I understand that while the human mind can do certain things that code can never accomplish, that for now if the result is via a code solution,then they will need to try and think more along the lines of how a database "thinks".My solution is going to be a new field for incoming PP data, and a new table for incoming -200 data ,and then, if they want to copy and paste then their fingers will be doing all that - and not me.Thanks Again