Text File Process: defining the variable's Elements?

[terrypin]

In this simple example the user is prompted for a text filename and each line of it is then displayed.

 

The variable holding each line is %tEachLine%. Its definition in the Properties window requires Elements, the size of the array. But this seems ignored. If I set it to say 3 and my file has 10 lines, all are correctly displayed by the macro, whereas I expected it to fail after 3.

 

Variable Set String %Filename%: Prompt for a filename

Text File Begin Process: %Filename%

Text Box Display: Display for each record

Text File End Process

 

<VARIABLE SET STRING Option="\x08" Destination="%Filename%" Value="Choose any text file"/>
<TEXT FILE BEGIN PROCESS Filename="%Filename%" Start_Record="1" Process_All="TRUE" Records="1" Variable="%tEachLine[1]%"/>
<TEXT BOX DISPLAY Title="Display for each record" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang2057{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 Filename\\f1  = \\f0 %Filename%\r\n\\par %tEachLine[1]%\r\n\\par \r\n\\par \r\n\\par \r\n\\par \r\n\\par }\r\n" Left="823" Top="708" Width="278" Height="200" Monitor="0" OnTop="TRUE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>
<TEXT FILE END PROCESS/>[/b]
[b]

 

--

Terry, East Grinstead, UK

DemoTextProcess.mex

[Cory]

I think you expect that each line will be propagated to a different element but that’s not how it works. Each time it will propagate the variable you defined in the repeat regardless of element. To do that you would need to do something like the revised macro attached.

 

However if hits is your goal then there’s a more efficient way using the Split command. See the other macro in the attached file to see how that works.

DemoTextProcess.mex

[terrypin]

Thanks Cory. Yes, that's what I did expect. For some reason I thought it used an array variable, but clearly I was wrong.

 

So, on the remainder of your reply, no, my goal is just to achieve the result in the simplest way with the fewest commands. Which is what my original does.

 

Your method using split would look like this if fully coded to match the original, 9 lines instead of my original 4.

 

Variable Set to ASCII Char 10 to %LF%

Variable Set to ASCII Char 13 to %CR%

Variable Set String %Filename%: Prompt for a filename

Text File Begin Process: %Filename%

Variable Modify Integer %C%: Increment

Variable Set String set %Temp% to the contents of %Filename%

Split String "%Temp%" on "%CR%%LF%" into %tEachLine%, starting at 1

Text Box Display: Display for each record

Text File End Process

 

Can you suggest the sort of application that might need that additional complexity please?

 

--

Terry, East Grinstead, UK

[Cory]

I’m kind of sorry I made the suggestion now given your snippy condemnation of my bloated code

 

Look, when you get into the advanced processing of files and text you will always need a few non-printing characters. At the beginning of almost every macro I write is carriage return, line feed, and tab. They are indispensable and generally used dozens of times in each of my macros. As a side note I noticed that in VB.NET they have a few predefined constants for a few non-printing characters and these are included. I mention this to further weight the validity of my practice. So creating the characters doesn’t add anything for me. Perhaps one could count the declaration as the inverse of the number of uses

 

Plowing thru each line of the text file is 4 commands using your method. With mine it’s 2. This of course discounts code that would be common to both like prompting the user for a file name. I don’t even understand the code you wrote and that is not how mine would look. I provided you an example of how mine. Or maybe I misunderstood the original premise. I mean why are you injecting what I wrote into your code? My code completely replaces your code with the exception of the prompt for a file name.

 

And for what it’s worth I disagree with the metric of fewer lines of code is better. Very often more lines are better and I often inflate my code to increase performance or clarity. I used to compact them as much as possible but I started to find when I had to come back a year or more later to revise the code was very difficult to understand again and much more difficult to modify. Now I write my code as if someone else would be modifying it later. However the point is moot here because my method does not increase the lines of code form 4 to 9 as you suggest.

 

On the issue of performance I grabbed a list of 500k account numbers for a recent project and added a stopwatch function to both macros. Your method took 13.242S on average and mine only 1.617S. And reading in the file to variable was only 100mS. So no more lines of code and it’s faster Though I am surprised how quick the text file process command is. 13 seconds is pretty quick for half a million records.

[terrypin]

First, I had no intention of being 'snippy'. On re-reading, I still can't see where you're coming from on that.

 

You answered my main question straight off, setting me straight on the Text File Process not using an array variable as I'd mistakenly thought. The rest was a side issue. I wasn't expecting a competition! Just trying to grasp in what application you'd use your method.

 

What was it you actually ran? The one you posted before was obviously not immediately runnable, unlike mine. I had assumed my expansion of it was correct, but there's obviously a misunderstanding somewhere. Maybe you could post the full macro you used on that large test file please. That might clear up any confusion.

 

Have a good weekend

 

--

Terry, East Grinstead, UK

[Cory]

As I recall all that was needed to be added to my code was to prompt the user for the file name. After that set a variable to the contents of the file, then split that on CRLF. That's it. No text process command or other looping necessary.

[terrypin]

As I recall all that was needed to be added to my code was to prompt the user for the file name. After that set a variable to the contents of the file, then split that on CRLF. That's it. No text process command or other looping necessary.

 

OK, thanks, I think the penny has finally dropped here. And actually, your six line macro included the prompt also:

 

Variable Set String %Filename%: Prompt for a filename

Variable Set to ASCII Char 10 to %LF%

Variable Set to ASCII Char 13 to %CR%

Variable Set String set %Temp% to the contents of %Filename%

Split String "%Temp%" on "%CR%%LF%" into %tEachLine%, starting at 1

Text Box Display: Display for each record

 

Sorry I was a bit slow to grasp what you meant.

 

--

Terry, East Grinstead, UK

[Cory]

Good for you!

 

To me it's 2 lines versus 4 because as I mentioned I usually already have CRLF and setting the file name is common. It's also faster and more elegant IMHO. After all one can remove a hex nut with a pair of pliers but a wrench would be proper. I think if you are processing any kind of text and you start declaring CR and LF at the beginning of your macros you will find many uses for them.

 

As an aside I had made one variable CRLF as an End of Lone variable but I found several instances where having them separate was advantageous. EG finding the position of the LF in a bunch of text is often more advantageous than the position of CRLF in that it eliminates an increment of the pointer.