|
Post by Stefan on Jan 21, 2021 19:22:17 GMT -5
George,
Ok. Downloaded SPFLIte22.exe (BTW: why are we back to ...22? Shouldn't it be SPFLite23?)
This version says v2.3.21021 in the title bar
Test data looks like this (LNOTE lines added by macro to show actual logical and physical line lengths.)
LNOTE> LINE STATS: _____LOGICAL______ _____PHYSICAL_____ _________PROFILE_________ LNOTE> MinLen: 32 at Line 1 100 at Line 1 MinLen: 100, NoPreserve LNOTE> MaxLen: 66 at Line 2 100 at Line 1 Lrecl: 0 =COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9 000001 TEST data - MINLEN is set to 100 000002 A single A in col 2 - next line is all blank 000003 000004 A A A A A A A A eight 'A ' starting in col 2 000005 A A A A A A A A eight 'A ' starting in col 1 000006 AaAaAaAa eight 'A's starting in col 1 000007 AaAaaAaAa eight 'A's starting in col 8
1st test: CHANGE " " "" ALL 1
Deletes a single blank from column 1 on lines 2,3,4 and 7 only. rest of each line shifts one column to the left. Perfect. No loop. No crash.
Reload the data
2nd test: CHANGE "A" "" ALL - not so good.
Removes all 'A's on lines 1,2,3,4 and 5. All good on these lines, but...
Removes only 4 'A's on lines 6 and 7. The sequence of the remaining upper & lower case As shows only every other A was removed, exactly as Robert said.
I agree with Robert that the issue comes from the fact that the data replaced by <null>, ie deleted from the line, makes the rest shift to the left by the length of the <fndstr>.
I reckon the only way to correctly handle that case may be to search from the end of the line to the front of the line when the <chgstr> is <null>. ..OR..
always search the original line and build-up a new version in parallel, which will replace the original line when no more hits can be found.
I think both are probably mega-invasive changes to the existing logic.
By the way... On 3 of my tests it worked correctly! Guess what. I had and old and a new SPFLite session running and tested in the wrong window! Easily done!.
|
|
|
Post by Stefan on Jan 22, 2021 0:53:59 GMT -5
George,
It's 5:50 AM and I can't sleep because I have this thought in my head which won't go away...
Further to my previous post that noted that alternate 'A's were not being changed... You said the new line reads sCol += IIF(LEN(lclChg) = 0, 1, LEN(lclChg) - 1) ' Adjust continue search colThe '- 1' was confusing me, But if you need 'sCol' to be one byte less that I expected, the new line should most probably be...
sCol += IIF(LEN(lclChg) = 0, 1 - 1, LEN(lclChg) - 1) ' Adjust continue search col
...to avoid skipping alternate 'A's when 'lclChg' is of zero length.
Fingers crossed!
OK, back to bed for the last hour before breakfast.
|
|
chaat
Sophomore Member
Posts: 59
|
Post by chaat on Jan 22, 2021 2:23:54 GMT -5
Stefan, in the second test that you mentioned, lines 6 & 7 only contain 4 "A" characters (upper case A).
perhaps you could show your lines after the change command so we could see the result. To me I would have expected only 4 "A" characters to be changed to nulls in both lines 6 & 7.
I'm assuming that the Find and Change commands are case sensitive, then they are working as expected. If they are not case sensitive, then it appears to not be working correctly.
|
|
|
Post by Stefan on Jan 22, 2021 4:19:11 GMT -5
Chaat, Lines 4 to 7 before and after CHANGE "A" "" ALL . the command is NOT case sensitive, ie both the A's and a's should be changed.
Before
=COLS> ----+----1----+----2----+----3----+----4----+----5----+ 000004 A A A A A A A A eight 'A ' starting in col 2 000005 A A A A A A A A eight 'A ' starting in col 1
000006 AaAaAaAa eight 'A's starting in col 1 000007 AaAaaAaA eight 'A's starting in col 8
After
=COLS> ----+----1----+----2----+----3----+----4----+----5----+
000004 eight ' ' strting in col 2 000005 eight ' ' strting in col 1 000006 aaaa eight ''s strting in col 1 000007 aaAA eight ''s strting in col 8
|
|
|
Post by Stefan on Jan 22, 2021 7:08:41 GMT -5
Sorry Robert - I think I stuck my reply in the thread you opened for the revised MINLEN under Suggestions.
My use case (described in MINLEN post under Suggestions) is not necessarily a MACRO issue. I tend to crash the app just editing stuff.
But you're right to consider the MACRO perspective.
The basic thing here is that as long as the MINLEN padding does NOT happen every time a line is changed, there's no issue and thus no reason to ban a <null> ("") target string. So I reckon you proposed revisions to MINLEN plus removing the padding process from the 'write data back after change' routine would avoid the endless loop.
I haven't yet given up on the fix George proposed which I amended slightly last night.
|
|
|
Post by George on Jan 22, 2021 11:59:25 GMT -5
Robert: Not sure about the link. Just downloaded it again (3rd time) and tested it. It still does your X X X X correctly, but of course now fails Stefan's AaAaAaAa test, so the matter is moot.
I'm at the point now that the answer is simply
a) Kill MINLEN altogether b) Kill CHANGE commands with Null change strings when MINLEN>0
My vote is b) since MINLEN does provide some usefulness, and the prevention of Null changes can be worked around. Most important is to prevent the Loop/Cancel happening.
I'm not going back in and continue fiddling with this. Even if I did get it to work with our test cases, there could be other side effects introduced in other commands.
Anyone want to set up exhaustive test cases for SPLIT/JOIN? Me neither.
There will also be no re-design of the whole process, so we can forget that.
So we're done here. I'm going to put in the b) option
George
|
|
|
Post by George on Jan 22, 2021 13:08:49 GMT -5
OK, here's a version with no 'fix' for the loop, just a new validation to prevent a possible looping Change command from being entered. George SPFLite23.exe (483 KB)
|
|
chaat
Sophomore Member
Posts: 59
|
Post by chaat on Jan 22, 2021 15:01:05 GMT -5
George, is there a potential issue with the following assuming MINLEN > 0 c 'abc ' 'abc' all where the line is as follows abc... where . is a space and MINLEN=6 I've not tried this but logically it would seem like it is functionally trying to replace a blank by a null. I'm beginning to wonder if it might be easier to just ignore the MINLEN in the find / change logic and instead only apply it when doing a "save" command.
|
|
|
Post by George on Jan 22, 2021 15:05:48 GMT -5
chaat: No, there is no problem with that.
If the find-string is a blank (or multiple blanks) AND change-string is null ("") and MINLEN > 0 then it will be rejected.
All others proceed as before.
George
|
|
|
Post by Stefan on Jan 25, 2021 7:46:05 GMT -5
George, SPFLITE23.EXE (v.2.3.21022) as posted Jan 22nd 6.08pm This is a specific and effective circumvention. It prevents the user from entering a command that can lead to them having to terminate the entire application. Hopefully, that's the end of this issue.
Thank you for your patience and persistence.
|
|
|
Post by George on Jan 25, 2021 10:01:06 GMT -5
Stefan: I wish I could have found a 'fix' that didn't break other actions, but ... As I said in some other post, preventing the loop/cancel has to take priority. Thank you for all the helpful tests you provided.
George
|
|