Extra carriage return when passing text information

[Arny]

I’ve got a puzzling problem when ‘setting’ a text field through the use of “LeftValues” & “MiddleValues”. I’m trying to move multiple fields of information from a master table to a secondary table.

 

    I’ve concatenated several fields contained in my master table [containing both text and numeric information] into a global text field. I then copied this text field in the master table and pasted it into another global text field in my secondary table [ex: gtext].

 

   I then used the field ‘set’ function to assign the values from the global text field into specific fields in the secondary table using the “LeftValue & MiddleValue” functions.

The numeric fields were set with

    ‘Set Field {field A}; GetAsNumber(MiddleValues(gText);2;1) – and were correct.

 

The text fields were set two different ways, neither of which worked

    ‘Set Field {field A}; GetAsText(MiddleValues(gText);2;1)

    ‘Set Field {field A}; (MiddleValues(gText);2;1)

In both cases the text fields added a carriage return.

 

I displayed the global text fields during the script process and they don’t show any evidence of an imbedded carriage return. It only seems to appear during the final ‘Set’ request in the script where the data is being transferred from the global text field into the secondary field

 

Is there a way to avoid this or perhaps another function that will ‘strip’ the unnecessary carriage return.

[eos]

The LeftValues() and MiddleValues() both add an extra CR by themselves, which you have to strip out, e.g. by Left (myResult ; Length ( myResult ) - 1 ).

 

GetAsNumber() strips the CR (since a number field only consists of one single line), but GetAsText() doesn't.

 

But since you seem to need only one value at a time, use GetValue(), which does NOT add an extra CR:

Set Field [ field A ; GetValue ( gText ; 2 ) ]

Note that you actually don't need two global fields, because you can access global fields from anywhere without a relationship; even better might be to hold your data in a $global to parse out.

 

I then copied this text field in the master table and pasted it into another global text field in my secondary table [ex: gtext]

 

You may also want to avoid using Edit script steps which are somewhat fragile (and overwrite your Clipboard); use either Set Field [ MasterTable::gTemp ; MasterTable::someOtherValue(s) ] before you go off to the the other table, or use Set Variable to take your data with you.

 

EDIT: Please update your profile (or Lee will come and get you!  ) to reflect your FM version and OS.

[Arny]

Thanks for the help . . I'll try the variable procedure and see what happens.

 

Happy Holidays

[Arny]

OK, I tried using the variable approach without much success . . It seems that the only way a $$variable will work is if the tables are related. I was hoping to minimize the numbers of relationships between tables by simply passing information through the clipboard.

[eos]

 It seems that the only way a $$variable will work is if the tables are related.

 

No, a variable has nothing to do whatsoever with relationships; its scope (accessibility) is determined by its type: $ (local) within one script, $$ (global) within one file (can also used outside of scripts, e.g. on a layout).

 

If you need to pass data from one script to another, a $$ would be one method (script parameters or global fields are others); if you're working within one script (even after returning from a sub-script), you can simply use a $. (The main difference is that a $$ persists after ending a script, so you need to "clean up"; a $ on the other hand vanishes when the script ends.)

 

What doesn't work is using a $$ across several files, because there is no application-wide variable ($$$, anyone?). Do you have different tabled or actually different files?

 

That being said, you can continue using the global field (which, as described, also doesn't require a relationship), but I recommend using the Set Field step instead of copy and paste.

 

Maybe first get GetValue to work so you get the expected results, then you change script steps. Better not change too much in one go.