Remove single quote from names and address with string map

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Remove single quote from names and address with string map

  • Creator
    Topic
  • #50401
    Sam Craig
    Participant

    Trying 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

Viewing 11 reply threads
  • Author
    Replies
    • #65976
      Mike Grieger
      Participant

      I 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?

    • #65977
      Sam Craig
      Participant

      Thanks 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???

    • #65978
      Sam Craig
      Participant

      But, 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

    • #65979
      Michael Hertel
      Participant

      Change

      set xlateOutVals $last_name_mod

      to

      set xlateOutVals

        Humor me….  😛  It can’t hurt to try…

    • #65980
      Sam Craig
      Participant

      Michael, 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

    • #65981
      Jim Kosloskey
      Participant

      Sam,

      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

    • #65982
      Michael Hertel
      Participant

      Mike Grieger is the one you should take to lunch first.

      Quote:

      This should eliminate having to “deal” with the list in the whole field

      Like Jim said, this is a learning curve.

      As Judge Judy says “woulda, coulda, shoulda…”

    • #65983
      Michael Hertel
      Participant

      Jim, 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
      }

    • #65984
      Jim Kosloskey
      Participant

      Michael,

      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

    • #65985
      Michael Hertel
      Participant

      Thanks for the explanation!

    • #65986
      Robert Kersemakers
      Participant

      Thanks 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

    • #65987
      Jim Kosloskey
      Participant

      Robert,

      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

Viewing 11 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
5,042
Forums
28
Topics
9,200
Replies
34,023
Topic Tags
267