Having a Problem Replacing a String's Content

[KeithW]

Greetings,

Maybe it too many late nights, I don't know but I have spent a longer time than this should take to accomplish.
I am using WinBatch 2020A for reference.

The attached file has the wbt script, an input file & the extenders I am using so you can drop the 3 zips into any folder
unpack and follow along...  I can post the wbt file but it is over 100 lines and I figure if you are interested you will
want to see the whole thing, not just an extract.

I am trying to simply reformat some dates... in the input file which is really a simple CSV file... the dates are in
yyyymmdd format.  Where the revised file is going it expects dates in mmddyyyy format and is pretty picky about
having things the way it wants them.

The first date field is at column 46-53, 8 columns with a comma before and after as it is the 10th field out of 43 fields
on the data line.  The next field as well as the 13th & 16th fields are also dates and all need the same treatment.

When I get to a date field, I extract the date (StrSub) send it to a Subroutine to be flipped, get it back and stuff it
back into the data line, EXCEPT the "," (comma) after it gets crunched somehow.  Then end result is the line
starts off as:
,,xxxxxxxxxxxxxxxxxxxxxxxxxx,20200423,20200423,xxxxxxxxxxxxxxxxxxxxxxxxxxxx

and ends up as:
,,xxxxxxxxxxxxxxxxxxxxxxxxxx,0423202020200423,xxxxxxxxxxxxxxxxxxxxxxxxxxxx

no that isn't a typo, it is the comma that is missing between the two dates, it was there
originally but not after processing that field.  I am using the extract same parameters in sub-string
processing to return (insert - StrInsert() ) that I used to extract the data in the first place but
now with the "," gone the StrScan does not find the next field.

To see  the error up close there is a DEBUG placed to where you need to be after the header is parsed.
When DEBUG activates you can look at the value of the "Line" variable... col 46 about 3/4s of the way to
the right in the field.  Two (2) "Nexts" will show you the flipped date, Three (3) more "Nexts" will show
you the updated "LINE" with the crunched trailing "," comma.

The calling Area in the wbt  is lines 183-185   The Subroutine is at  224-226 ... what am I missing?


Keith

[kdmoyers]

I checked it out, ran the test code, hoping I'd see something obvious.  Pretty complex flow of logic there!
I didn't see it, but my instincts tell me it's just a good old fashioned bug in there somewhere.
I may look again later today if I get time.

[kdmoyers]

I suspect unicode vs ascii problems.    Even simple operations on that LINE variable act funny.

I tried replacing

Code (winbatch) Select Expand

Line = StrInsert(line,field,"",cbeg,cend-cbeg+1)
with

Code (winbatch) Select Expand

lineA = ChrUnicodeToString(line)
fieldA = ChrUnicodeToString(field)
Line = strsub(lineA,1,cbeg-1):fieldA:strsub(lineA,cend+1,-1)
which seemed to address the immediate issue.  You might have unicode issues all over the place though.
-Kirby

[td]

Haven't looked at the script but if you load a text-based file as Unicode the WIL string functions will automagically recognize and handle the contents appropriately.

[KeithW]

I suspect this file is coming from a MainFrame or Large Unix Box as it has only LF line endings
so there is no telling what they file is other than a PITA and over the years always has been.
It just seems to get more unruly as tie goes on...too big to load into Excel and fix and the
end use program has issues with the file too unless everything is spot on and to do that I
have to run conversions on it like this.

[KeithW]

I loaded the original incoming file,  the first completed (albeit incorrectly) reformatted file and the Demo File I included with the script for this issues into UltraEdit (my fav editor choice) and all three files appear to be ASCII and while UE will gladly convert these file to UTF8 or 16 it does not see these as UniCode files to be converted to ASCII.

[ChuckC]

For values 0 thru 127, ASCII, ANSI Latin 1 code page and UTF8 are essentially the same 8 bit binary pattern.  What happens with values 128 & higher varies after that.

[td]

Not that it matters to this topic but when I use the term Unicode in my previous post I was referring to UTF-16.  If a file is UTF-8, you need to let WinBatch know by using the ChrSetCodePage function so it can correctly convert text.

[td]

I loaded the original incoming file,  the first completed (albeit incorrectly) reformatted file and the Demo File I included with the script for this issues into UltraEdit (my fav editor choice) and all three files appear to be ASCII and while UE will gladly convert these file to UTF8 or 16 it does not see these as UniCode files to be converted to ASCII.

You may have already sorted out your problem and to be honest, combining a code dump with and not using the best tool for debugging WIL scripts (WinBatch Studio debugger) can be the cause of some eye-rolling and/or clicking of tongues.  But a quick inspection of your script indicates that your problem appears to be the result of a misunderstanding of the StrInsert function.  You might want to consider using StrOverlay instead. Otherwise, your script is well documented which is a good thing..

[KeithW]

td,

Not sure bout your reference regarding WinBatch Studio debugger as I included the .wbt script, with debug(1) inserted where it needed to be and the series of steps (NEXT commands) and comments to place you where to see what you needed to see to demonstrate the problem, how much more was I suppose to do?

You are correct about using the StrOverlay, thank-you, I thought I had tried that at one point in time although I could be mistaking as I can tell you more about what I did in the 1960s & 70s than I can about last week, but that is another topic all of its own.  This is why all my scripts are documented, again thanx, as I sometimes look at a script initially and say "who was smokin' what to write this" and then I read the right side column and go oh yeah, that what this does....

Keith

[td]

Not sure bout your reference regarding WinBatch Studio debugger as I included the .wbt script, with debug(1) inserted where it needed to be and the series of steps (NEXT commands) and comments to place you where to see what you needed to see to demonstrate the problem, how much more was I suppose to do?

The WinBatch Studio debugger makes identifying bugs much easier and more efficient than using something like the "Debug" function.  Add a breakpoint or two (WBS has two ways to set them) and often problems almost report themselves in the Watch window. But to each their own...

[KeithW]

OK, I understand your point now....

Thanx,
Keith

[KeithW]

TD,

Can Breakpoints be stored in the file over multiple editing sessions or are they only for the current session?

Keith

[kdmoyers]

There is a special magic BREAKPOINT command word that only works when running under the debugger and is otherwise ignored.  If you place that in your code, it will of course be remembered.

[td]

Yup. Set one or more visual breakpoint which exists for the length of the WBS session or add  "breakpoint" statements to your script which last until you remove them.

[KeithW]

Thanx,

The Docs/HelpFiles were not totally clear what to expect.

Keith

[kdmoyers]

In the dim days of Fortran !V computer programming, putting a special instruction in your code was the only kind of debugging offered!  I still do it that way half the time, forgetting how easy the debugger makes things.  We also wore bear skins and killed our bugs with stone axes.

[KeithW]

True, I am sill guilty of placing Message statements all over my code to verify results...
Strip or comment out my when it functions properly... old school.

[td]

Thanx,

The Docs/HelpFiles were not totally clear what to expect.

Keith

The help file for WBS is brief but clear enough. A help file can only do so much.  It is best to take the approach is to just try them and find out what happens.  I haven't unintentionally reformated a hard drive yet...