|
Post by Stefan on Dec 5, 2022 8:51:43 GMT -5
Guys,
Am I being daft or did this cease to work with FIND and CHANGE?
I quite often issue a primary command sequence like this.... CHANGE ALL "ABC" "DEF" ; LOCATE nnnn
where 'nnnn' is the line number at the top of the page where I would like to be afterwards, often, but not always, the same as the current page.
This used to work really well. In fact, it still does work really well when used with other commands, like
EXCLUDE ALL "%RGB" ; LOCATE nnnn
But with FIND and CHANGE (possibly others too, I haven't tried them all!) the first command is executed and the second one appears to just get lost.
I'm conscious that the primary command separator is a semicolon, which happens to be the 'comment' character for SET-EDIT also now. Coincidence?
|
|
|
Post by George on Dec 5, 2022 10:26:58 GMT -5
Hmmm, I tried it with 22194 - doesn't work there either. I'll have a look.
George
|
|
|
Post by George on Dec 7, 2022 13:22:07 GMT -5
Stefan: OK, now that I'm getting to this, it's going into "Silly Mary Ellen" mode because Daddy's watching.
I can't get it to fail, either the latest Beta or the Production version. Do you have a consistent failure example?
George
|
|
|
Post by George on Dec 7, 2022 13:34:31 GMT -5
(only mildly confused)
So .. it is now working? Or have I misinterpreted?
George
|
|
|
Post by mueh on Dec 8, 2022 4:46:13 GMT -5
George: Looks to me if LOC Line nr is lower than the Cursor set by FIND/CHANGE/EXCLUDE loc is a NOOP . Seems that LocNext is done . Is following code in LocSearch correct ? IF IsLfFirst OR IsLfAll THEN ' If FIRST/ALL then start as the top LocLine = 1: LfClear(%LocFirst): LfSet(%LocNext) ' Remove so we do it just once END IF ' even a find xxx;LOC :TAG FIRST is a NOOP when Tag is before the found line . Thanks
|
|
|
Post by George on Dec 8, 2022 10:56:25 GMT -5
MUEH: a) Thanks for the hint, got me on the right track. b) However, the LocSearch code IS correct (in fact in this scenario, LocSearch is not even used) c) Error was in CurSetReq, and the error may account for a variety of other bad cursor positioning cases. d) Fix consists in changing one line - from using variable "A" to using variable "B" - your challenge for the day. George
|
|
|
Post by mueh on Dec 8, 2022 13:36:22 GMT -5
Thanks George . 22342 solved the LOC NOOP problem . When saving my new (Empty) test file by end of SPFLite i discovered obscure data loss problem . Problem occures only when Empty file with Label and Tags as shown on same line is saved . Tag :T is on line 2 6 10 and label .A on line 2 and .B on line 6 . The saved file has the first 4 lines lost . No Problem when create or saveas is done . is there different code used during termination to save file ?
|
|
|
Post by George on Dec 8, 2022 15:06:43 GMT -5
Robert: Yes, maybe (New) is better than (Empty), but it's another of those 'here, there, and everywhere' type changes.
MUEH: I'll have a look. Do you mean the data lines themselves are missing? or that the STATE saving of Label and Tag info is missing?
George
|
|
|
Post by George on Dec 8, 2022 16:16:07 GMT -5
Robert: I already have two utilities Flatten.EXE and UnFlatten.EXE. When I want to edit the SPFLite source in one SPFLite session, I run it first, it creates an SPFLite.Flatten file to be edited. When I'm done, UnFlatten puts it all back to the normal individual files. Both run in basically a 'blink'.
The only change to the source needed is to alter all the #INCLUDE statements of stuff like API headers to include the ONCE KW. If ONCE is coded, the Flatten program will NOT expand it in the output file, it just leaves it as a normal #INCLUDE statement. Gad! Last thing you need is a couple hundred thousand lines of API headers.
If you'd like them, I'll send them. They'd need tweaking as they are set up internally with specific SPFLite filenames.
George
|
|
|
Post by mueh on Dec 9, 2022 2:23:17 GMT -5
George: The first 5 Data lines where missing . When saving to a file with STATE ON you get
|
|
|
Post by mueh on Dec 9, 2022 2:31:52 GMT -5
George: Since 22337 there is a problem that LOCATE doesn't set .ZLOC . ON sample file issue LOC 2 . f ' ' 1 .ZLOC results in Line reference .ZLOC is undefined Thanks
|
|
|
Post by George on Dec 9, 2022 11:11:40 GMT -5
MUEH: I cannot get any data loss with your scenario. I tried SAVEAS - worked. I tried SAVE - worked. I tried END, replied Yes to the SAVE prompt - worked. George
|
|
|
Post by George on Dec 9, 2022 11:32:53 GMT -5
MUEH: Oops, another of those - fix problem 'A', miss something, and create problem 'B'.
Corrected for the next Beta.
George
|
|
|
Post by mueh on Dec 9, 2022 12:10:43 GMT -5
George: The Data loss problem during END when saving Data get's complicated . First i thought it's permanennt but then i couldn't reproduce it . Here a detailed test scenario which you shoul repeat maybe 10 times . Put following test data into CB . then open NEW file and issue PASTE cmd to get Data fron CB . issue following cmd to set tag and labels . tag :T 2;tag :T 6;tag :T 10;line ".A" .2;line ".B" .6 Enter .C label on line 4 manualy (must be done otherwise i didn't get error) Press pfk3 for end Click on SAVE and enter file name to save it . view the file and you should see the the records 1-4 are lost . If you can't reproduce i will give up .
1 2 3 4 5xxx 6 7xxx 8 9xxx 10
|
|
|
Post by George on Dec 9, 2022 13:41:33 GMT -5
MUEH: Well, I went through this about 8-9 times, being careful to follow your steps exactly.
In all cases no lines were dropped and the .C label was saved correctly on line 4.
Let's leave it till somehow we magically stumble on the scenario that triggers it.
George
|
|