|
|
Post by mueh on Nov 4, 2018 4:29:49 GMT -5
Hello George: Have another V10 Problem . After res Color is done Color of 1'st find Setting red is cleared on 2'nd find . As a CRCMV issue reset FIND before 3'rd find which keeps now yellow Color . ;reSet color find ;fiNd MCMD: all +red ;fiNd DASD all +yellow ;reSet find ;fiNd muretr 1 +green Attached C1 file has cmd's 2'nd Problem is if Colored String starts at col1 (muretr in green ) and enter is done with Cursor not at col1 Highlightning is not reset for col 1 .  c1 (134 B) Thanks for V10 . |
|
|
|
Post by George on Nov 4, 2018 14:53:50 GMT -5
MUEH: You sure have a knack for exposing the obscure bugs. Congrats, you found another one. RESET COLOR was not cleaning up after itself quite well enough and left data around which confuses future color operations. Corrected.
George
|
|
|
|
Post by George on Nov 6, 2018 10:34:51 GMT -5
Robert: Don't feel bad, it took me a bit to get it. Had to try several sequences of the sample commands till I saw what was going on. Basically, once you do a RESET COLOR, future color operations are mucked up because RESET didn't clean up some Global variables after it was done.
Easy to fix once you grasp what's happening.
George
|
|
|
|
Post by mueh on Nov 13, 2018 3:37:43 GMT -5
George: Used now +Color in Change command and it seems that all Color's having White FG do not Color .
Change string1 string1 all +red
has Nothing to do with changing to same string ( avoids confusion when i repeated cmd with yellow Color)
Also you should try PFK6 rchange which changes Color to some other Color.
PFK5 Find is correct .
Should'nt CHANGE work the same as FIND ?
Reading the Doc for RESET i also noticed that CHANGE Operand Function is not documented . ( Existed already in 8.5 and reset's CHG in Line cmd )
|
|
|
|
Post by George on Nov 13, 2018 10:48:56 GMT -5
mueh: Remember that when you do a Find/Change and add a color, it interacts with the new support for FIND/FIND ALL which highlights ALL the occurrences of the string. Highlight does a color inversion. Do a RESET FIND and all is well (at least in my testing here).
Maybe this highlighting ALL like ISPF did is not a great idea with the color support. ISPF didn't have that type of collision.
The RCHANGE is definitely broken. Looks like it's saving a color index out by one (just a guess right now)
I'll check into these.
George
[Update]
OK, found it. Got caught by the old programming trap, I used an arithmetic formula when I should have used a Boolean one. The old plus/minus is NOT the same as AND/OR. Gotta be careful with that when bit flipping, sometimes both ways will work, sometimes not.
George
|
|
|
|
Post by mueh on Nov 14, 2018 12:29:26 GMT -5
George: Sorry for another Problem . When line cmd R99999 is issued the file get's Color . RES COLOR destroyes Data before repeat .   _ UNDO results in Crash . V10 Features like DO and 15 Colors are great . |
|
|
|
Post by George on Nov 14, 2018 14:44:42 GMT -5
MUEH: I'm not sure what to do with this one. Repeating a line 100,000 times triggered a loop warning on my system, I replied OK to let it continue, but then got an unresponsive window. I tried closing, which brought back the window with weird colors like yours. At that point I just cancelled the edit session.
Obviously, something went wrong with the large repeat function, but frankly, I'm not going to try and trace it because it takes such an enormous number to trigger it. Honestly, no way I could debug something with that kind of trigger requirement.
George
|
|
|
|
Post by George on Nov 15, 2018 11:03:35 GMT -5
Robert: Repeat already does the allocation only once, but there's still the work of replicating the data and attributes. I can't think of any reason why a large number would cause any problem other than the length of time. There's no limits on maximum file size, we certainly know of users who've loaded over a million lines. I did that regularly for a while when I was doing the optimizations umpteen releases ago.
So this failure is a real mystery.
George
|
|
|
|
Post by mueh on Nov 15, 2018 11:32:09 GMT -5
George: Just for info .
Don't realy need that large amount of repeat . Tried to create a file to see if Line Count in Status is not truncated after reduce of font size for 100000 Lines.
No error in 8.5 . R99995 works in V10 but next R1 causes the error .
I can live with the Problem .
|
|
|
|
Post by George on Nov 15, 2018 11:40:14 GMT -5
MUEH: Thanks for the addition info. If that's repeatable, I'll have a good chance of finding it.
George
|
|
|
|
Post by mueh on Nov 15, 2018 12:06:11 GMT -5
George: Yes it is repeatable but i made a mistake . R99993 works and if i do an R1 again the file is colored ( even line is 1 Char in length )
Thanks for you Patience .
|
|
|
|
Post by George on Nov 15, 2018 13:49:54 GMT -5
MUEH: Found it. Simply a glorified typo. I'll have to get out a correction release quickly, this would affect all files over 10,000 lines. Why 10,000? That's simply the default initial size of the text storage areas. The error was in the routines for expanding the text areas, The areas get expanded and several pointer variables need to be updated at the same time to match the new location of the expanded data areas. The color attribute pointer was getting basically destroyed.
George
|
|
|
|
Post by mueh on Nov 20, 2018 10:22:54 GMT -5
George: Saw another V10 Color Problem . SAVE command Colors COL 1 of each line with +Color of last find cmd . Destroyes Color if Color in COL 1 is different and i want to continue after SAVE . REPLACE and CREATE have no Problem . Could you also look at 2'nd Problem of page 1 in this thread which is more cosmetic but has to do with COL 1 . Thanks for best Editor available .  |
|
|
|
Post by George on Nov 20, 2018 14:26:17 GMT -5
mueh: OK, I'll try to get to both. It's been quite busy personally lately, family birthdays and anniversaries, and I have some minor surgery coming up, and that means tests, blood work, etc. We'll get there.
George
[Update]
OK, the one that misprints the Command line has been found/corrected, on to the next.
George
|
|
|
|
Post by George on Nov 20, 2018 16:56:07 GMT -5
MUEH: OK, this coloring of column 1 was quite weird. The older SPFLite versions used a generalized search routine, but in reality it was only used by FIND and CHANGE. Many versions ago, we added support for a large number of other commands to use search operands (like FIND and CHANGE do) to allow 'filtering' of their actions. It was relatively simple, and with only a few tweaks, the generalized search routine handled it all well.
Even simple commands like SAVE ended up using the generalized search routine.
But buried deep in the search code was some old code that needed to know if the running command was FIND. Since it was only used by FIND/CHANGE (Hmmm - Right!) it performed colorization for any non-CHANGE command. Bad, bad coding. It should have been reversed and only done it for FIND.
So the bad coding has now been corrected, all seems a lot better. Fun one to track down.
But please, quit finding these things! No, really, I wish more users reported stuff like this instead of living with it. I may curse a bit tracking it down, but it's MY code I'm cursing.
George
|
|
