bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 23, 2015 4:08:43 GMT -5
I have found that I can highlight (change colour of background) text with a FIND or CHANGE command but is there a way to change the colour of the text itself via one of these commands?
If that is possible, is there a way to extend the area of colour change to affect all text on that line? ie if a line contains the string 'xyz' then don't just change the string to 'xyz' but change all text on that line to be red.
|
|
|
Post by George on Jan 23, 2015 13:28:12 GMT -5
bryman: There's no built in way to mark the whole line when a found string. However a short macro can do it. Here's a sample, you'd probably have to tweak and add some more to it to get a real working copy, but it's a start. It does a single FIND and marks the whole line in Red. For repeat finds, Find ALL etc. it would have to be more involved of course, but cobbling together this plus several examples from the Macros Help file and samples it shouldn't be too hard a job. Stuff this in your MACROS folder and issue the command 'FCOLOR string'
George
' FColor.MACRO ' if Get_Arg$(0) <> "" then if SPF_Cmd("FIND " + Get_Arg$(0)) = 0 then Set_Clr_Line(Get_Find_LPtr, REPEAT$(Get_Line_Len(Get_Find_LPtr), "R")) else Halt(Fail, "Cannot find " + Get_Arg$(0)) end if end if
|
|
|
Post by George on Jan 23, 2015 13:28:20 GMT -5
bryman: There's no built in way to mark the whole line when a found string. However a short macro can do it. Here's a sample, you'd probably have to tweak and add some more to it to get a real working copy, but it's a start. It does a single FIND and marks the whole line in Red. For repeat finds, Fine ALL etc. it would have to be more involved of course, but cobbling together this plus several examples from the Macros Help file and samples it shouldn't be too hard a job. Stuff this in your MACROS folder and issue the command 'FCOLOR string'
George
' FColor.MACRO
'
if Get_Arg$(0) <> "" then
if SPF_Cmd("FIND " + Get_Arg$(0)) = 0 then
Set_Clr_Line(Get_Find_LPtr, REPEAT$(Get_Line_Len(Get_Find_LPtr), "R"))
else
Halt(Fail, "Cannot find " + Get_Arg$(0))
end if
end if
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 23, 2015 16:52:09 GMT -5
Robert: Sorry if I have caused confusion by trying to keep my initial query as short as possible.
I had already found the help description of +RED to highlight certain character strings (thank you) but that parameter changes the colour of the background of the found text to red, not the text itself. I wondered if I had missed an equivalent command parameter to specify that the foreground colour should change rather than the background, such as ++RED. One can't use -RED as that already has a different meaning.
George: Thanks for confirming that there is no built-in facilty to change the colour of the whole line when an included text string is found. I did not think there would be but was just hopeful and thought it worth checking as that would save me having to write/enhance a macro. I am finding so many useful built-in extras that I would hate to spend lots of time reinventing the wheel, particularly with my rusty skills.
Thanks also for the example. That is such a help, for general coding information as well as for this particular situation. I can follow what code is doing but starting from scratch needs a whole new level of expertise/familiarity. Similarly, the examples in the Macros Help file are invaluable.
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 23, 2015 23:17:57 GMT -5
Oh dear! Things are getting a bit messy regarding these colours. I would appreciate some further help (in addition to the standard documentation).
Having turned highlighting on for a text string, how do I turn it off? I do not understand the underlying logic for searches/changes. Some specifications are very confusing. Sometimes the list of colours defines the search criteria and sometimes the change specification.
F 'text' red --- will find the text only if it is highlighted in red. F 'text' red blue --- will find the text only if it is highlighted in red or blue. F 'text' red +blue --- will find the text only if it is highlighted in red and will then change it to blue.
I am often unable to search for one colour (or several) and change it to another because I get an error message . . . "cannot specify both positive and negative color searches." But one can be for the search and the other for the change!! For example:
F 'text' -red +red --- find non-red and change to red. F 'text' -std +std --- find non-standard (ie any highlighted) and change to not highlighted. F 'text' -std +red --- find any highlighted and change to red.
The search can be either positive or negative but the change can only be positive.
Via massive trial and error, the only way that seems to work is . . . F 'text' red blue green yellow +std Surely there is an easier way than that?
If I try to do this with a CHANGE command then I must still specify FROM and TO strings, even if I only wish to change the highlighting. Again, positive and negative colour specifications are not allowed in the same command. Or am I now thoroughly confused and need to have a lie down in a quiet, darkened room?
|
|
|
Post by George on Jan 24, 2015 14:19:01 GMT -5
Robert: Glad you wrote the explanation above. Frankly, I'd have had to review the Doc. before tackling an answer. But yes, you're right, it can take a bit of RTFM to get things straight in your mind. But once mastered, it is quite a powerful function. George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 24, 2015 19:14:53 GMT -5
Thanks guys, that is a GREAT help. I had read the documentation but that allowed me to veer away from the true path. Please can the documentation be tweaked a little to include a couple of comments from Robert's above reply?
1. Search colour specifications are either simple (eg RED) or negative (eg -RED), not both. 2. Change colour specifications are always positive (eg +RED).
I had (mis)understood the documentation to mean that -STD +STD is an invalid combination. I had also tried RESET but that did not remove the colour. I now know that I need to use RESET COLOR. I thought that you had misunderstood my request to change the foreground text colour rather than the background paper colour. I had not realised that there were other options which I could use to control/vary that.
I think this is a case of the documentation is fine for those that know and need a reminder but missing a key point or two for someone new that is trying to understand initially.
I am still experimenting to see how best to use this colour facility but I think it will be extremely useful. My previous use of ISPF (20+ years ago) was using a monochrome (green on black) 3270.
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 27, 2015 5:13:22 GMT -5
I am not saying there is anything actually wrong in the documentation, just nothing to stop me heading off on the wrong thought process. You can't anticipate that as you don't know how I was approaching what I wanted to do, without me telling you. I just hope that we can save anybody else from doing something similar.
The documentation is getting large and the thought of searching for a specific answer is rather daunting if not immediately obvious from the section headings. A couple of further questions come to mind following my tests with George's suggestions.
1. Can the colour option definitions be modified from within a macro, or does that have to be done manually before the macro is run? Probably not but just checking whether definitions can be pre-defined. 2. My macros run successfully when entered as Primary Commands but not when invoked from within another macro as SPF_Cmd statements. Do I have to do anything other than place all macros in the same folder?
If this is in the documentation, just point me at it. Don't spend a lot of time explaining here. Thanks.
|
|
|
Post by George on Jan 27, 2015 11:01:46 GMT -5
bryman:
Color definitions can not be altered from within a macro, only through the Options dialog. Just curious, why would a macro want to?
Macros cannot call other macros via SPF_Cmd. It gets just way too involved. Command line calls macro process, which creates a thread and loads thinBasic and establishes links to all the SPFLite functions, then calls thinbasic and passes it the macro's code in-memory, thinBasic interprets code and calls SPF_Cmd code to pass a command line. Now we're back at step one again. Managing nested primary commands and threads and their associated data areas is just more than my poor brain can cope with.
As to where in the Doc it says you can't call a macro from a macro? I had a look and can't find it. Yes I know, that proves the Doc. is not searchable easily.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 27, 2015 20:51:13 GMT -5
George: Thanks for confirmation. No specific reason for changing colour formats on the fly. I just wondered if different combinations might be more appropriarte in certain circumstances and didn't want to be dependent on separate user involvement. Sometimes a red background can look too heavy if there are several instances in close proximity. Also, yellow does not show up well on white so inverse black on yellow might be better, etc. I like the use of 'traffic lights' to convey extra meaning but it is not always easy to anticipate how things may end up looking.
Pity about not being able to invoke one macro from another. I had no idea how complicated that might be. Don't feel bad. I shall just have to cut and paste the expanded macro code into each place that needs it. A slight inconvenience for me but nothing compared to what you might have to implement!
Robert: Thanks for specific reference. I have trawled forwards and backwards through the documentation trying to get familiar with all I need to know and was getting a bit punch drunk. I now remember looking at that section and deciding straight away that it was too detailed for an initial familiarisation. I should have taken it more slowly.
|
|
|
Post by George on Jan 28, 2015 11:37:40 GMT -5
bryman: Robert: Yes HnD does support indexes, but as you said, going back in and adding all those keyword references is daunting. I started it a few releases back, but after doing a few items it turns out you really have to plan out your Index/Keyword structure properly beforehand. If you don't, you end up with a big mushy mess that really isn't helpful. Realizing that, and being my basic lazy self, I backed out of the create-an-index project. It would be certainly worthwhile, I've found myself floundering trying to locate something. But the effort ...... Ick!
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 28, 2015 17:22:02 GMT -5
Hi George, I would hate to exclude you from this conversation so here is an update on how I am getting on with your suggestion for changing the colour of a matched line.
The code works well to find and change text strings in lines which are spaced apart. However, it does not work so well with adjacent lines. Is the LPtr incorrect for consecutive matches after the first? What might I be overlooking or is there a bug?
SPF_Cmd("FIND FIRST 'text' +RED") do while Get_RC = 0 Set_Clr_Line(Get_Find_LPtr, REPEAT$(Get_Line_Len(Get_Find_LPtr), "R")) SPF_Cmd("RFIND") loop
produces . . .
000010 text rest of line1 000020 text rest of line2 000030 different contents in line3 000040 text rest of line4
Sometimes I even get line 3 changed to all red when there is no match!
Please don't say RTFM (but I am prepared to if I have missed something else).
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 29, 2015 4:38:54 GMT -5
Thanks for your comments Robert but I am now even more confused.
I did read the manual and without knowing all variables/conditions that can be tested, I based my code on the documentation section "Use the FIND command to locate text lines to process" within "Working with The Interface", together with one of the sample macros, RM.MACRO, written by George. I did not work my way through all of the samples before trying something that I thought would be simple. Why would LPtr not refer to a data line in this situation?
It seems that I need to go back and read everything again. Much of it is way beyond what I need for a 'simple' initial foray. I had thought that my example would be an easy introduction to this topic. Even with your comments, I don't understand how my code can give rise to the unexpected results obtained when consecutive lines are matched.
|
|
|
Post by George on Jan 29, 2015 16:24:16 GMT -5
bryman: Robert: The value returned from the SPF_CMD function is the return code from the command issued, not SPF_CMD itself. It is returned as the value from the function, and also in a subsequent Get_RC. So the return code indicates the result of the FIND/RFIND command. (all this is as spelled out in the SPF_Cmd() documentation. Now as to your problem. I cut pasted your macro code and tried it and it seems to be fine. I changed 'text' to 'fred' and ran it against one of my normal testing files, here's what I see in an attachment. Maybe you can post your data and macro for us to play with. George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Jan 29, 2015 19:19:49 GMT -5
Thanks for your offer, Robert, but I am not looking for either you or George to code or debug my macros. If I am going to write my own macros then I need to understand how to do that correctly. However, guidance would be very much appreciated.
I tried your TESTRC macro and (of course) it performed exactly as you predicted.
I therefore inserted an extra test (after the DO WHILE) into my macro that was listed in an earlier post. If Get_Find_LPtr = 0 then Halt End If
That didn't seem to make any difference to the result.
By halting after succesive FIND/RFIND statements I see that LPtr is not just the line number. After the first FIND, LPtr has a value of the line number plus 3. After the RFIND it is line number plus 4 and then plus 5. That is where the first consecutive "text" match is found and the next RFIND also has LPtr value of line number plus 5. However, the colour changed for the line after the previous match, even though there was no match in that line! ie . . .
(LPtr = 4) 000001 .text rest of line1 (LPtr = ?) 000002 .different contents of line2 (LPtr = 7) 000003 .text rest of line3 (LPtr = 9) 000004 .text rest of line4 (note first character is not changed to red) (LPtr = ?) 000005 .different contents in line5 (LPtr = ?) 000006 .different contents of line6 (LPtr=12) 000007 .text rest of line7
The value of LPtr was only determined when matches occurred.
I hope that makes sense and that I have not made any errors in the reporting.
|
|