Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Remove single quote from names and address with string map
- This topic has 12 replies, 5 voices, and was last updated 15 years, 1 month ago by
Jim Kosloskey.
-
CreatorTopic
-
October 21, 2008 at 6:06 pm #50401
Sam Craig
ParticipantTrying to remove single quotes from addresses and names and replace it with nothing. Seemed simple enough using the following string map command. set last_name_mod [string map {‘ “”} $last_name]
This command works fine if there are no spaces in the field I am checking.
Like name O’Keefe becomes OKeefe.
But, in an address with spaces, it removes whole words.
Example: 123 Beech’nut lane^beech^FL becomes 123^beech^FL
Any ideas or experience with this issue?
Thanks,
Sam
-
CreatorTopic
-
AuthorReplies
-
-
October 21, 2008 at 7:03 pm #65976
Mike Grieger
ParticipantI believe you tcl works the way you want. The problem you are seeing is probably due to how you are returning your data from the proc… likely not treating it as a list? -
October 22, 2008 at 12:07 pm #65977
Sam Craig
ParticipantThanks for reply Mike….. But, using this code inside a translation and only working with one of the sub-fields in the xlt.
Doing a copy using the following code:
Source field = 0(0).PID.00114(0).[0]
Then in the Pre TCL box have the below code:
set last_name [lindex $xlateInVals 0]
set last_name_mod [string map {‘ “”} $last_name]
set xlateOutVals $last_name_mod
Destination field = 0(0).PID.00114(0).[0]
This should eliminate having to “deal” with the list in the whole field
0(0).PID.00114(0)
Anyone have any other ideas???
-
October 22, 2008 at 12:15 pm #65978
Sam Craig
ParticipantBut, in an address with spaces, it removes whole words. Example: 123 Beech’nut lane^beech^FL
Returns: 123^beech^FL
I even removed all the spaces in my test data and it removes just the single quote fine.
Example test data: 123Beech’nutlane^beech^FL
Returns this: 123Beechnutlane^beech^FL
So, it seems to be something with the spaces.
Any ideas or experience with this issue?
Thanks,
Sam
-
October 22, 2008 at 1:43 pm #65979
Michael Hertel
ParticipantChange set xlateOutVals $last_name_mod
to
set xlateOutVals
Humor me…. 😛 It can’t hurt to try…
-
October 22, 2008 at 3:06 pm #65980
Sam Craig
ParticipantMichael, you are a SUPER GENIUS!!!!!!!!!!! If you were here, I would give you a hug and a kiss.
😀 Or, at least take you to lunch.
It works!!!!!!!!!!!!!!
Thanks so much for the help.
I can put the hair back that I have pulled out trying to get this “simple” code to work.
Again, THANKS,
Sam
-
October 22, 2008 at 3:51 pm #65981
Jim Kosloskey
ParticipantSam, Hopefully you have learned (the hard way but sometimes that is the best way) in an xltp type proc to always treat the in and out lists as lists.
Not doing so can and typically will cause issues.
email: jim.kosloskey@jim-kosloskey.com
-
October 22, 2008 at 4:13 pm #65982
Michael Hertel
ParticipantMike Grieger is the one you should take to lunch first. Quote:This
eliminate having to “deal” with the list in the whole fieldshouldLike Jim said, this is a learning curve.
As Judge Judy says “woulda, coulda, shoulda…”
-
October 22, 2008 at 7:21 pm #65983
Michael Hertel
ParticipantJim, I got to thinking about this. I thought, several people get scolded about this and why not just change the template to reference a return for xlateOutList instead of xlateOutVals. So I looked at the template and saw xlateOutList was already there.
Can you tell me what the difference is? Why don’t we return xlateOutList instead?
Code:######################################################################
# Name: __MODULE_NAME__
# Purpose:
# UPoC type: xltp
# Args: none
# Notes: All data is presented through special variables. The initial
# upvar in this proc provides access to the required variables.
#
# This proc style only works when called from a code fragment
# within an XLT.
#proc __MODULE_NAME__ {} {
upvar xlateId xlateId
xlateInList xlateInList
xlateInTypes xlateInTypes
xlateInVals xlateInVals
xlateOutList xlateOutList
xlateOutTypes xlateOutTypes
xlateOutVals xlateOutVals
} -
October 22, 2008 at 8:03 pm #65984
Jim Kosloskey
ParticipantMichael, There are three lists for the inbound and outbound sections of an Xlate Action (COPY for example)
xlateInList is the list of the Data element Names in the inbound side (for example if one specified a COPY of @my_temp_variable to @your_temp_varianble), the xlateInList would be a list of one element that element would have the value @my_temp_variable. The xlateoutList would be a single element list with the single element having the value @your_temp_variable. Those are the
email: jim.kosloskey@jim-kosloskey.com
-
October 22, 2008 at 8:15 pm #65985
Michael Hertel
ParticipantThanks for the explanation! -
October 23, 2008 at 8:24 am #65986
Robert Kersemakers
ParticipantThanks for the explanation, Jim. I never knew this; always used xlateInVals/xlateOutVals. Let’s see if I understand correctly with xlateOutList. By changing the contents of this list, can you dynamically change the outbound field where your values are put?
Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
-
October 23, 2008 at 12:09 pm #65987
Jim Kosloskey
ParticipantRobert, If you are using xpmstore in your xltp proc then yes.
As a matter of fact, before the IF Action was available, we used a generic if proc (xltp) that I wrote in the Xlates.
Among other functions, that proc allowed one to change the address path wherein a data item could be used in place of the %xn repetition counter and the proc would replace the name of the data item in the address path with the value of the data item – 0(0).1(@my_cntr).XXX(0).fld# would change the @my_cntr in the address path of the contrived preceding example to the actual value of the data item (let’s say @my_cntr has the value 1 – 0(0).1(@my_cntr).XXX(0).fld# would become 0(0).1(1).XXX(0).fld#).
That is accomplished by changing the appropriate xlateOutList entry.
Note that you then are not restricted to using the ITERATE counters or absolute number in an address path . I have asked that Cloverleaf(R) be enhanced to allow the use of any valid data item including temp variables, and inbound or outbound fields in the address paths. It is on the list of things requested.
One caveat – apparennty if a temp variable is not referenced before a proc tries to access it, the lists get out of sync. That is the xlateInList has the entry for the data name but the xlateInVals does not – so if one data item is in the inbound side and that data item is a temp variable and that temp variable is not ‘initialized’ then there will be one entry in the xlateInList and zero entries in the xlateInVals. This causes a difficult to debug situation.
Hence I always try to initialize all temp variables I am using in my Xlate right at the beginning of the Xlate (a very good programming practice learned in the ‘old school’). That way I should not get bit by the caveat expressed above.
email: jim.kosloskey@jim-kosloskey.com
-
-
AuthorReplies
- The forum ‘Cloverleaf’ is closed to new topics and replies.