DataMystic

I have another simple FLL that makes a space-formatted file into something usable by Excel. Very FAST . I need to pick up three bits of information from the contents and at the very end, add them back into the header. I could painfully extract all the text surrounding it and delete, but it's much easier to do an EasyPatternbut the problem I have is the only way to actually use @prodCode that I know of is to send it to a subfilter. That means that all the filters I have created have to be subfilters which I've done (with the pattern now including the entire file): Processing now takes about ten times longer (EDIT: 0.6s before, 9.3s after via trial run testing; 15 times slower). It seems you call the @varName a global, but it's not really global from what I can tell. It only applies to that filter and subfilters. Is there a true Global that uses an EasyPattern? Capture Text appears to essentially provide a CONST definition scheme -- which my quick test appears to bear true.

Am I missing something?

Well, it looks like I was misinformed. There is some global nature to the vars. I now have the EasyPattern filter command removing the found text and I can reference the vars created. HOWEVER, that reference only applies to the subsequent file processed. WTF?
Abbreviated from the log:
file A is opened
3 replaces done in file A for this:(Action: remove)... other stuff happens, then at the end, I have either this or this (both behave the same)File A is written to a new .txt file.
File B is opened.
6 (!) Replaces done for the EPtn code (there's only one line with that data).
The header IS added to file A with nothing for the var text.
The header IS added to file B with the data from file A. Now you get a sense of my WTF.
File C has 2 replaces done. File C has header data from file B.

If it matters any, the EPtn code is the very first line to run and the add header is the very last thing to run.

Have you gone through the TextPipe tutorial?

Each file runs through each filter independently - you cannot rely on the order of things being done. At the time the add header filter is 'given' the start of the file to work on, the EP match has not yet occurred, hence the empty match.

To force all EP matches to occur first, you need to include them inside a subfilter.


As for the 6 matches, turn on prompt on replace and you will see where it is matching.

DataMystic Support wrote:Have you gone through the TextPipe tutorial?

I started to but it was painfully basic.

DataMystic Support wrote: Each file runs through each filter independently - you cannot rely on the order of things being done. At the time the add header filter is 'given' the start of the file to work on, the EP match has not yet occurred, hence the empty match.

I'm expecting each file to have independent processing but have the filters run in order. It appears that's not the case. If so, IMHO, putting numbers on the filters in the middle pane is misleading GUI. It would seem beneficial to make the processing ordered,too.

Since at least some of it is ordered, a solution might be an icon on the right pane that indicates it processes out of order (shown when that filter is selected in the middle pane).

DataMystic Support wrote: To force all EP matches to occur first, you need to include them inside a subfilter.

I finally ended up doing that and though it's a tad fugly, it works. It was fugly as I had to prevent the needed text from being clipped by the fixed-to-delimited change that happens after all the garbage has been removed.

DataMystic Support wrote: As for the 6 matches, turn on prompt on replace and you will see where it is matching.

Thanks. I'll give that a try as it's rather baffling yet intriguing.

Much love to Australia.

Hi Bill,

The filters are definitely processed in order. Order is crucial, as shown in the tutorial (despite it being basic, it's a concept often overlooked).

However, you cannot rely on the order of processing between filter X and filter X+1. For efficiency, TextPipe hands around chunks of text and you cannot rely on either the size of tet or the timing of when the chunks of text are handed off (other than by forcing complete processing of a section, which is inefficient).