|
Post by George on Jan 30, 2015 11:32:02 GMT -5
bryman: Robert:
First off, Robert - I am NOT wrong on the SPF_Cmd() RC handling, what the Doc says is correct. Also , a) I verified what the code does and b) ran the following test. Here's the test macro:
' FColor.MACRO
'
SPF_Trace(on)
DIM i as NUMBER
i = SPF_Cmd("FIND FIRST 'fred' +RED")
SPF_Debug("FIND i=" + format$(i))
if i = 0 then
do while i = 0
Set_Clr_Line(Get_Find_LPtr, REPEAT$(Get_Line_Len(Get_Find_LPtr), "R"))
i = SPF_Cmd("RFIND")
SPF_Debug("RFIND i=" + format$(i))
loop
end if
And here's the resultant trace:
SPF_Trace$(1) RC=0
SPF_Cmd(FIND FIRST 'fred' +RED) RC=0 CHARS 'fred' found
FIND i=0
SPF_Debug(FIND i=0) RC=0
Get_Find_LPtr() RC=0
Get_Find_LPtr() RC=0
Get_Line_Len(4) RC=0
Set_Clr_Line(4, RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR) RC=0
SPF_Cmd(RFIND) RC=0 CHARS 'fred' found
RFIND i=0
SPF_Debug(RFIND i=0) RC=0
Get_Find_LPtr() RC=0
Get_Find_LPtr() RC=0
Get_Line_Len(5) RC=0
Set_Clr_Line(5, RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR) RC=0
SPF_Cmd(RFIND) RC=8 Bottom of data reached
RFIND i=8
SPF_Debug(RFIND i=8) RC=0 As you can see, 'i' which is the return value from SPF_Cmd() properly returns 0/8 depending on the success of the FIND/RFIND; it does not always return zero.
As to the LPtr returned from FIND, it will ALWAYS point at a data line because, by it's very design, FIND/RFIND only look at Data lines, there is no need to test the line type of the line returned by FIND/RFIND.
bryman: I would create a very small test data file, and insert SPF_Trace(ON) at the beginning of your macro code. I'm sure doing this will pop out where the error is.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 30, 2015 20:15:31 GMT -5
Sorry if I have introduced errors in my reporting but I was just trying to keep things uncluttered by giving a simple example when my test was rather more complex. In my test data file, there were some excluded lines and that accounts for the varying values of LPtr. I didn't realise that excluded lines would be significant. When I went back and ran the simple test data, as described previously, everything worked beautifully.
In fact, the presence or otherwise of excluded lines is of crucial importance. I am having difficulty identifying exactly what the conditions are but I am able to change the result just by excluding the display of certain data lines before running the macro !
I do not specify "x" or "nx" anywhere so does this indicate an error in the FIND command or setting/retrieval of LPtr?
For instance, run the macro (searching for "BODY") against the following test data file . . .
0 TEST1 1 BODY text 0 TRLR 1 TEST2 1 BODY text 0 TRLR
and it should result in . . .
0 TEST1 1 BODY text 0 TRLR 1 TEST2 1 BODY text 0 TRLR
That is what I am looking for but note what happens if the following commands are processed before rerunning the test . . .
SPF_Cmd("RESET STD") SPF_Cmd("X ALL") SPF_Cmd("FIND ALL '0' 1")
The result is . . .
0 TEST1 1 BODY text 0 TRLR ------------------------ < 000001 > 1 BODY text 0 TRLR
In TEST1, the FIND is successful but the rest of the line does not change colour. Instead, the following line is changed where there is no match!
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 31, 2015 5:54:20 GMT -5
Robert, the macro is listed in post dated 11:22am on 29th Jan except I have changed search string from 'text' to 'BODY'. The data file is as listed with results, just before your post.
I have run lots of different macros and data file combinations which has made it difficult to isolate the simplest combination which illustrates the problem. However, I believe that the above posted versions of the macro and data file/results should let you see what happens immediately. I could enhance the macro as suggested by George but was hoping that he would be better able to try that himself. I keep getting called away to do other things and then having to re-orientate my thoughts when I return - hence the big gaps between replies.
|
|
|
Post by George on Jan 31, 2015 12:36:01 GMT -5
Robert: Good debugging. The LPtr vs Line Number thing is always tough to describe. But without the LPtr idea, we couldn't have provided access to all the misc. line types (like NOTE etc.) in the macro language.
Re: your other comments:
1. Since the macro will change lines to red where FRED is found, there is no need for the +RED option. That doesn't hurt but it's unnecessary since you are overriding the color anyway.
>> Yes, true.
2. If FRED appears more than once on the same line, RFIND will find that, and then the whole line will be (re)colored to the same color all over again.
>> Also true, but that internal overhead will never be seen or noticed.
3. For the debugging aspect, it sure would be nice if the value returned from an SPFLite-supplied function was displayed, and not just the RC.
>> Maybe, but most times the RC and Message are sufficient. If really needed then SPF_Debug() can be inserted, but I think that will be rare.
4. Even if this macro works, it doesn't explain the user's problem. He still needs to show us what he is doing so we can provide a definitive answer.
>> Nothing like the actual samples and specific step-through.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 31, 2015 17:20:07 GMT -5
George, Robert, thanks for your help in investigating this strange situation. Initially, every time that I created a simpler environment for investigation, the results changed and confused any definition of what was going wrong. I have now taken Robert's advice and moved the exclusions to after the main macro processing. Not as intuitive and arguably less elegant but it does seem to work.
I first started using SPFLite to look at large files, possibly hundreds of thousands of lines. Scrolling backwards and forwards using something like Notepad was a real pain in the ****. I remembered from decades ago the ease with which ISPF could exclude any unwanted lines and bring the apparent size of a file back to more manageable proportions so was delighted when I found SPFLite.
The large files that I am using consist of possibly thousands of 'sections', each having hundreds of lines. My first thought was to write my own editor/reader which would scan the file to create an 'index' of headers, one for each 'section', and allow the user to link to a new window for each 'section' which would contain the lines for that 'section'. Although simple in concept, I knew that might (would?) get much more involved when actually being developed. To be honest, I don't need to look at such files very frequently so any such development would really be done for the challenge and satisfaction rather than any real cost/benefit justification.
SPFLite was a much easier route to take and my use of colours is to break up the long files into 'sections' for ease of viewing and navigation. Initially, 'unwanted' lines are excluded but I needed the 'section' seperators to stand out even when other adjacent lines are uncovered. My consideration of dynamically altered (reassigned) colours was just in case I found it advantageous to identify further details and needed more than 4 colours.
I still don't have the direct link ability that I was originally envisioning but I think that ISPF used to have a label facility for similar jumps. I will read the documentation to see if anything similar exists in SPFLite. Meanwhile, standard FIND commands will achieve the same.
Thank you for producing SPFLite and bringing back so many happy associated memories.
|
|
|
Post by George on Feb 1, 2015 12:30:52 GMT -5
Robert: If you think LNum and LPtr can be combined, lets hear it. It would probably 'break' existing macros I fear.
George
|
|
|
Post by George on Feb 3, 2015 12:38:14 GMT -5
bryman:
After reading Robert's suggestions on revising LPtr/LNum handling, which would be a major revision to macro support, I realized that the problem you were experiencing with Get_Find_LPtr is really, plain and simple, a bug. Regardless of X'd lines or not, it should return the correct LPtr. So I will be correcting this.
This does not eliminate the more general problem of a macro doing something else which might invalidate an LPtr, but it will remove the cause of the majority of these incidents. I will post something here when a correction version is available.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Feb 4, 2015 23:51:10 GMT -5
Thanks George, but don't bust a gut just on my behalf. I have a work-around by not excluding until after the lines have been coloured. Not the most elegant of actions but it works. Please handle any higher priority items first.
|
|