|
|
Post by George on Jul 14, 2013 11:52:14 GMT -5
Hi, I've corrected a few small bugs reported via email, and will probably put out another minor maintenance release this week.
So rather than report one right after the release, if you've spotted any little 'niggles' (or big ones), now the time to report them so they can be corrected and incorporated in this upcoming release.
George
|
|
|
|
Post by Stef on Jul 21, 2013 12:25:48 GMT -5
Hi George - Three of my niggles...
(1) BNDS... Lets say I have a file wider than the screen so I can't see left < and right > bounds on the BNDS line but I wish to change them. Why do I need to replace the existing < & > with a blank to move the bounds? Why can't I just type the new < and > where I want them and have SPFLite accept those rather than the existing ones?
(2) I would love an option to specify that all trailing blanks are considered "real" blanks during the edit session. This would allow the use of commands like C " " "!" all 40 40
Lines shorter than 40 bytes would be lengthened to suit. If the profile is Variable length records, trailing blanks could/should be removed before SAVE.
(3) I use LOCATE primary command to position a specific line at the top of the display. Works great if the chosen line isn't already visible but doesn't scroll the screen if it is already in view.
All in all, it's a fabulous product and still improving. I'm looking forward to trying out the new macro facility - I miss the ISREDIT API a lot.
|
|
|
|
Post by George on Jul 21, 2013 13:22:46 GMT -5
Hi Stef, Thanks for your feedback.
1) Your wish is granted. This is already included in the next release. You must still remove/move any >> (max) indicators manually, but altering < and > should be just as you requested.
2) This is a real problem area. Changing the way this works affects far more than you would expect. As long as you have PRESERVE OFF in the file's Profile, a bypass would be to temporarily lengthen all lines using a PL line command. i.e PLLnnn on the top and bottom lines to pad all lines to nnn size. The trailing blanks would be removed on Save processing.
3) Hmmm, yes this is not consistent with how ISPF handles LOCATE. We'll have a look at altering LOCATE. In the meantime, the next release has added a macro function which can help. Save the following as LL.MACRO in your \MACROS folder (or use some other name than LL)
' ll.macro
if Get_Arg$(1) <> "" then
Set_TopScrn_LPtr(Get_LPtr(Get_Arg$(1)))
end if
and when the next release is out an LL [lno] command will do what you want.
Thanks again for the comments.
George
|
|
|
|
Post by George on Jul 22, 2013 10:02:20 GMT -5
This is not as simple (never is) as just fudging things so a FIND will 'successfully' find strings past the end of the line. A successful find establishes pointers to the found string that every other command which supports string searches may or may not be dependent on for further processing. This is a long list of commands: CHANGE, COMPRESS, EXCLUDE, FLIP, JOIN, NDELETE, NFIND, NEXCLUDE, NFLIP, NSHOW, SHOW, SPLIT, TAG. Just determining the implications for each of these commands and deciding what is the 'correct' handling would be exhausting mentally.
We can't just extend lines at will on a successful 'find'. With PRESERVE ON we'd be altering the file by simply doing a FIND command, not a good idea. As I said, not simple.
George
|
|
|
|
Post by George on Jul 22, 2013 10:48:56 GMT -5
You're right, it's never easy. But, there could be some things that could be done to simplify the process. To give this idea a name, let's call it the "column auto-extension" facility. 1. The syntax of the command is just a matter of deciding how to do it. Unless you have a better idea, I like the dash approach on the columns: 1-40. --- You do like breaking parse routines don't you. A NO to this option. 2. To avoid column positioning issues, you could restrict the use of auto-extension to when ALL is used. The entire line must be involved. --- There's nothing to gain from this, ALL or not, the problems are the same. 3. You mention, "We can't just extend lines at will on a successful 'find'. " That's correct. You would only extend the *real* line on a successful change. --- But the problem is that CHANGE (and other commands) are coded to expect data to already exist at the 'found' locations. Their code is just not set up to cope with pointers to non-existent columns. And the primary search routine, which is widely used by commands (even those that do not support string searches) does not know, or need to know, what command is calling it. So it is not set up to customize it's actions based on which command it is working for. We have somewhat a chicken and the egg scenario. 4. Not mentioned elsewhere, but obviously the case, is that "extension" only involves blanks. The original example wanted to change a blank to a non-blank. In fact, that's the ONLY time this idea would work, is that the find string must either be just blanks or have trailing blanks. Otherwise, extending a line with blanks would not accomplish anything; you'd never find the search string. Perhaps this fact could be used to simplify the search. You would have to validate that the search string was "findable" under those conditions, and then perhaps (I *did* say PERHAPS) you could adjust your search logic so that the implied line extension was done in the compare routines rather than as a representation of the true data line. --- You know my reaction to 'adjust your search logic'. I was forced to do that when we put in the SPLIT/JOIN commands and was this || close to chucking the whole thing after a couple weeks of frustration. I don't need to go there again. And what about the special cases, with RegEx, or special picture literals with [ and ] codes, use of LEFT RIGHT operands, and on and on. This rapidly evolves into a quite major undertaking, which is why we've chickened out in the past. Ok, not WE but ME. George |
|
|
|
Post by George on Jul 22, 2013 13:21:39 GMT -5
If we used something like EXTEND, I'd prefer it to be a new Profile option. You could have EXTEND ON only if PRESERVE OFF/C was set. And turning PRESERVE ON would also set EXTEND OFF. (They would be incompatible) This would be far the simplest implementation since all thats needed is a change in the search routine, there would be no impact on command syntax or processing done by other commands. It's the most transparent solution.
George
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12 
|
Post by Fredashay on Jul 30, 2013 17:59:58 GMT -5
You're gonna hate me, George. I think I found another bug in V7...
If you place C on a line to copy it, then max to the top, then type F FOOBAR on the command line to find a line, it doesn't find the line but instead says Bottom of Data Reached.
If you type F FOOBAR again, it finds the line with the word. But when you type A on the line, the clipboard has been erased and it tells you have a Pending Source Line Range Command.
|
|
|
|
Post by George on Jul 31, 2013 9:36:42 GMT -5
Fred:
At first I thought, yes, odd bug. Checking out some line/primary command tables everything seemed set correctly to allow scrolling via the FIND command while line commands are pending. But it obviously wasn't working.
After a bit of experimenting with command variations, it was the old forehead smack!
Adding flexibility sometimes comes back to bite you.
The FIND command, along with many other primary commands, was extended to accept what the syntax describes as 'line-range-operands'.
'Line range operands' are things like .FROM .TO or .20 .30 to mark a range of lines to limit the search range. A handy feature.
BUT
The line-range-operand support also allows the line range to be pre-marked via line command markers rather than specifying the range as primary command operands. And guess how the line range is marked - yep, by C/CC line commands.
So when you issued the FIND command with a single line marked with a C, the command dutifully searched that 1 line range and of course did not find the string. But in doing so it 'ate up' the C line command. Next your FIND retry was successful, and you entered the A line command, but there was no longer a pending C.
Now we have a 'what to do now' problem. Back a few versions ago, when line-range-operands were introduced, line ranges for use by primary commands had to be marked with a new U/UU line command (USE). But that affected good old standard primary commands line CUT, CREATE, REPLACE etc. which used to use the C/CC line commands. This wasn't exactly a popular change, and we backed off the U/UU and went back to C/CC.
So I can explain the 'bug', but right now I'm not sure what to do with it.
George
|
|
|
|
Post by George on Jul 31, 2013 11:05:56 GMT -5
Robert:
Although re-introducing U/UU blocks seems to be a way out of this. I wreaks havoc in the line command parser. Right now, line commands are categorized as one of three types, Source - CC, MM etc.; Destination - A/B, O, H etc.; and Immediate - I, N, R, D etc.
Adding UU splits the Source range category up, we'd have some like UU valid for all primary commands, but not line combos, CC valid for some primary, but not other primary, and valid for line combos. This alters the line command table definitions to add the new category, and the primary command table to identify not only type of line command supported (Source/Dest) but now to identify what class of Source.
You know the grief the line command routines have caused in the past, this is an area I'd like to avoid. Since the whole problem revolves around the FIND/NFIND command class, this is definitely a 'mull it over' carefully. Maybe there's some other alternative, adding U/UU back is not my first choice.
George
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12
|
Post by Fredashay on Jul 31, 2013 16:55:52 GMT -5
Well, I'm sure the two of you will figure it out...that's what programmers do, lol...
In the meantime, I still think this is an awesome editor that's so much easier to use than any of the other programmer's editors I've tried over the years :-)
And yes, I tried SPFLite 4 for a while a few years ago, but it was way too buggy....no offense, George.
BTW, do you have a version for Linux or planning to do so?
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12
|
Post by Fredashay on Aug 1, 2013 17:20:28 GMT -5
Oops. I think I just found another bug... Well, I don't know if this is a bug or if this is how you intend it to work but...
When I type I as a line command, it inserts a pending line. If I then type text and press Enter, in turns the text into an actual line and then creates another pending line underneath that one. But if I type a space, the line goes away. I don't have a mainframe handy at this particular moment to verify this, but I believe if you do this on the mainframe, it saves the blank line there and creates another pending line underneath it.
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12
|
Post by Fredashay on Aug 2, 2013 17:34:22 GMT -5
v7.0.3185
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12
|
Post by Fredashay on Aug 2, 2013 18:13:22 GMT -5
Yup! I'm typing the spacebar on the first data position of the line and pressing enter.
|
|
|
|
Post by George on Aug 3, 2013 12:50:42 GMT -5
Fred: I've also tried this as well and it seems fine. Robert and I have tried it on several older versions as well, no problem. What version are you using, and maybe if possible, could you provide your SPFLite.INI file just in case this is somehow dependent on a combination of settings that neither Robert or I use.
George
|
|
Fredashay
Freshman Member
Noob writing a Q&A site in PHP and MySQL.
Posts: 12
|
Post by Fredashay on Aug 3, 2013 13:17:20 GMT -5
I seem to have two INIs.
This is SPFLite.INI:
[Screen]
LastScrX=-8
LastScrY=-8
ScrWidth=135
ScrHeight=41
CursBlnk=1
HRuler=1
VRuler=0
Banding=0
CursNorm=20
CursInsert=100
FontPitch=12
FontName=Lucida Console
KBHelp=0
cTxtHi=255
cTxtLo=65280
cLinNumHi=16777215
cLinNumLo=16776960
cErrMsg=255
cBGRound=0
cBGRound2=1184274
cStatFG=16777215
cStatBG=8421504
cPFKFG=65535
cPFKBG=16512
cMarkLine=5197615
cTabMod=12632256
cITabBG=1677215
cTabNMod=10485760
cBlueBG=14599344
cGreenBG=8388352
cYellowBG=13499135
cRedBG=4605695
cBlueFG=0
cGreenFG=0
cYellowFG=0
cRedFG=0
[General]
MRFList=
LastPath=inc
ABeepFlag=1
VBeepFlag=0
UniqFlag=0
FMOpFlag=0
FMExt=0
FMSize=1
FMDate=1
FMTime=1
FMFullSize=1
DProfFlag=0
CdelFlag=1
UseRecycle=1
BrowseWarn=0
FMHelpFlag=1
MinRetrieve=3
CmdChr=;
ROpenLast=0
Allow2DMouse=0
NatChars=0
CharSet=!"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¬¢£€
WebCheck=0
WebLastVers=7.0.3185
WebLastDate=01-01-2001
Notify=2
FindWord=0
RecentCtr=30
FMLCmdWidth=5
QuickRenum=50000
DefDataShift=2
SubmitCmd=SPFSUB.BAT ~S
SubmitDir=
CMDFlags=/K
RUNFlags=/K
LastDirOpen=2
$LastProfUpdate=130728@15:46:39.69
CustomClr=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[FManager]
Recall=
DefDir1=C:\apache2\htdocs\ClockPie\www
DefTypes=*.INC;*.PHP;*.INI;*.TXT;*.PAS;*.C;*.H;*.BAS;*.HTM;*.CSS;*.JS;*.XML
DefSort=NAMEUP
ScrlAmtc=HALF
[System]
Build=7.0.3185
[Keyboard]
KBScrollH=0
KBScrollV=0
InsMode=1
InsReset=1
[Mouse]
AutoScrl=2
This is SPFLiteCfg.INI
[General]
Retrieve=
MRFList=
[Screen]
LastScrX=5
LastScrY=0
Here's a little more detail:
If I type two or more spaces on the inserted line, it reacts as if I typed text and creates the line. It only removes the line if I type just one space. So I just have to remember to type two spaces to insert a blank line. That works for me. So don't spin your wheels fixing this just for me :-)
|
|
