|
|
Post by George on Jul 20, 2024 10:56:36 GMT -5
This thread will contain the latest Beta release following the V3.1.24198 production release. Betas will contain all the latest bug fixes, as well as early releases of new features. If you download and use one of these Betas, you should take precautions to be able to back off should it prove unstable. I will try to provide, with every version, any information that may affect switching to the Beta release. When a new Beta completely replaces previous versions, the download link for the previous beta versions will be removed. If you are running the latest production release, this Beta can simply be swapped in place of the production EXE. Beta version: V3.1.24248CHANGES- Correct an error in handling messages from an IMACRO. They were being erased immediately from the message line, and issuing a RELOAD command would trigger a loop.
- Enhancements to the macro file attribute functions: Get_Filexxxx$ to work with CLIP, SetEdit and EFTEdit session more reasonably.
- Changes to the BACKUP command for special sessions (Clip, SetEdit and EFTEdit). The filetype will be set to their type (CLIP, SETEDIT or EFTEDIT) so that the correct profile will be used if opened for Edit directly.
- BACKUP of a Named CLIP session will now include the NAME of the clip file in the backup name.
- Correct handling of the Post_Do command queue. Add correction to fix re: Comments in the DO file.
- Add a new macro function Get_TabNum which will return the active tab number.
- Extend AUTOBKUP support to the CLIP, SET and EFT tabs.
- Additional changes to BACKUP/AUTOBKUP. SET and EFT backups will now properly save the correct 'before' data. CLIP will use the proper timestamps for named CLIP file backups. AUTOBKUP will not back up named temporary CLIP files (those with a leading _ character).
- Additional tweaks to BACKUP of CLIP, SET and EFT sessions.
- Enhancements to the macro file attribute functions: Get_Filexxxx$ to work with CLIP, SetEdit and EFTEdit session more reasonably.
- Correct handling of RETRIEVE/CRETRIEV/RETF commands.
- Corrected handling of command retrieval in File Manager, it was not properly adding all commands to the Retrieve stack.
- Correct handling of a Profile override on the Windows Command line, it was basically being ignored.
- Consolidate multiple internal tables of CFG file variables into one combined table to simplify maintenance.
- Remove the ASSERT option from the TAG command. This was an option which challenged most users to understand, alternative options of TAG provide the same function, so ASSERT has been removed.
- Correct filtering in the new combined Line-Range-Operands module.
- Correct error in master parse table affecting FM selection of Read-Only files
- Add support to master parse table to allow specification of 'ignorable' keywords. This will reduce nuisance error messages which occur when a keyword is specified which is valid but just not supported for the commaand (usually because it is redundant or otherwise not needed). An example would be X ALL 'ABC' NX - the NX
- Adjust macros Get_Find_..... as per the discussion in the latest forums.
- Correct line range support in the general search routine.
- Correct handling of special lines (Tabs, Mark, Mask etc.) so that if they are deleted after making a change to the line, the change is properly 'thrown away'.
- Add a new Macro function Is_Available(filename) to test if a file is 'in use' anywhere. It will return a value as follows:
0 - The file exists and is available
1 - The file does not exist
2 - The file exists and is in use in an active SPFLite tab
3 - The file exists and is locked by some other Windows process. - Allow dropping of a folder onto the SPFLite screen. It will be opened in File Manager.
DOWNLOAD: For members: SPFLite3.3.1.24248.exe (516.5 KB) For non-members: SPFLite3.3.1.24248.EXE For non-Members, comments should be emailed to : support@SPFLite.com RE: Beta 3.1.24202 -- or whatever the version is -- Or better yet, become a member, as it says in the news, it costs nothing, you get to post on the forum, and you will not be bothered by any emails from us. [/span] |
|
|
|
Post by Stefan on Aug 2, 2024 3:37:40 GMT -5
George, I did a 'clean' install of the current production version of SPFLite3 v24198, only keeping the original CFG. Currently I'm running v24213beta. I notice there's a mismatch between SPFLite and CFGMAINT. If you export the CFG, you see messages... CFGMaint - Table: PDEFAULT, Entry: UNDOLEVELS=10 IS Obsolete / Invalid, Dropped
CFGMaint - Table: PDEFAULT, Entry: FOLDFLAG=0 IS Obsolete / Invalid, Dropped
CFGMaint - Table: PDEFAULT, Entry: NUMTYPE= IS Obsolete / Invalid, Dropped
... for every profile. OK - no drama.
I then imported the above, corrected export file and figured I'd have a clean CFG going forward. And I had, but only briefly.
Start SPFLite3, and open a file for editing, then close down SPFLite3.
Re-run the CFGMAINT export and you'll see message... CFGMaint - Table: PDEFAULT, Entry: UNDOLEVELS=10 IS Obsolete / Invalid, Dropped
... for the DEFAULT profile and the profile for whatever file type you opened.
So SPFLite is putting UNDOLEVELS back into profiles even though that entry is obsolete.
|
|
|
|
Post by George on Aug 2, 2024 7:53:36 GMT -5
Stefan: Odd. I'll have a look.
George
[UPDATE]
There are several tables, one in CFGMaint, and a couple tables and inline code in the main program. I did a full match between them all and of course UNDOLEVELS popped out. But there were several other minor mismatches as well that needed correction. That's been done.
It would be nice if they could all be combined into one master "does it all" table but the tables amongst them contain both VARPTR and CODEPTR entries making that a real problem, since those data types have to be created by the compiler. It might be possible in a single EXE, but having something common to both SPFLite3.EXE and CFGMaint.EXE seems impossible.
George
|
|
|
|
Post by Robert on Aug 9, 2024 11:57:46 GMT -5
George, would a carefully crafted #INCLUDE file solve the problem?
R
|
|
|
|
Post by George on Aug 9, 2024 12:14:41 GMT -5
Robert: I explored that, but it needs MACRO help, and PB Macros have a big failing over good old ASM macros, you can't examine and conditionally 'do stuff' based on macro operands.
But I have managed to package them up in a single Object, but the CODEPTR and VARPTR requirement still means some external code in any EXE that uses them. The CODEPTR isn't much (about 16 lines) but the VARPTR stuff takes a lot more, one for every OPTIONS variable.
But it's done and seems to be working OK, with minimal changes to the calling code.
George
|
|
|
|
Post by mueh on Aug 20, 2024 0:25:40 GMT -5
Hi George !
Installed 24232 and got data loss problem on SAVE when x all;find some lines or x aaa all is done. ( no problem when x line cmd is done ) .
Only NX lines are saved .
Another Problem when f. e 'X A all' is done . ( and A occures multiple times in line's ) the Nr of excluded lines in msg is now Nr of A found .
Thanks for reimplementing :\tagname
|
|
|
|
Post by George on Aug 20, 2024 8:41:20 GMT -5
MUEH: Thanks. That's bad. I'll get on it.
George
[UPDATE] Big oversight on my part.
The X/NX, U/NU and :Tag filtering was combined with the normal line-range-operands testing. That's where the :\tag was resurrected.
However, the routine which establishes line ranges for SAVE etc. didn't handle the newly added criteria.
Corrected in 24233.
[/UPDATE]
|
|
|
|
Post by Robert on Aug 20, 2024 10:19:36 GMT -5
Mueh: I tried your FIND A ALL on 232.
Here is my data:
ABC ABC
ABC ABC
ABC ABC
ABC ABC
ABC ABC
ABC ABC
Command: FIND A ALL
Result: CHARS A found 12 times in 6 lines
Seems to being doing the right thing for me.
R
|
|
|
|
Post by George on Aug 20, 2024 11:39:11 GMT -5
Robert: FIND is fine, EXCLUDE is not. Do X ALL ABC you get "12 lines excluded"
George
|
|
|
|
Post by mueh on Aug 20, 2024 11:59:34 GMT -5
Hi Robert ! I didn't report a problem where find fails . George: SAVE is solved but there are 2 more Problems with 24233 . If you do X A all on roberts file it shows msg 12 excluded lines . In fact there are only 6 lines but 12 matches for A . IF you do X A;X A;X A it should exclude 3 lines but it excludes only 1 line . additional msg shows 3 excludes done . No problem up to 24225 .  |
|
|
|
Post by George on Aug 20, 2024 13:20:33 GMT -5
MUEH: Regardless of 3 "X A" commands working previously, is SEEMS correct. Without qualifiers, it becomes ALL and keeps finding the 1st line.
It really should be "X A NX", but NX isn't allowed. It seems NX should be assumed, like ALL is assumed.
Seems merging the X/NX and U/NU into the line-range has way more side-effects than expected.
George
[UPDATE]
Not quite what I thought, but it was a missing flag setting. There's one routine that handles all the Misc. EXCL, FLIP, SHOW etc. commands and it simply sets a bunch of flags and falls into a common search routine.
I'll post a fix tomorrow AM.
[/UPDATE]
|
|
|
|
Post by Robert on Aug 20, 2024 14:33:52 GMT -5
George: you're right, I did Find not Exclude. My mistake.
Mueh: you can't say X A NX because X only operates on UNexcluded lines. (Why would you want EXCLUDE to operate on excluded lines?? They are already excluded...)
R
===> quite right, Stefan, it was a typo - a pretty bad/dumb one at that :-((
R
|
|
|
|
Post by Stefan on Aug 21, 2024 3:33:54 GMT -5
Mueh: you can't say X A NX because X only operates on excluded lines. (Why would you want EXCLUDE to operate on excluded lines?? They are already excluded...) Robert
I'm sure your claim to mueh is a typo. The command X (as in EXCLUDE) actually only operates on UNexcluded lines.
It always irritates me that SPFLite is overly picky and prevents users from using a construct (NX in this case) because it is illogical, when there is abolutely no harm in allowing it. We are all people and most of us do not aspire to being Mr. Spock.
Issuing an illogical command is easily done, for example, when you retrieve a previous FIND <whatever> NX command and just change the command name to X.
So a command like X <whatever> NX is not wrong, just superfluous because it requests what would have happened anyway. And a command like X <whatever> X is also not wrong, just pointless/illogical.
Why should I be admonished via error message for a superfluous operand and be required move the cursor along the line to remove it and press <ENTER> again, when it does no harm? A reply message like 'Operand NX ignored. String <whatever> found n times in n lines' would be a perfectly adequate reminder.
|
|
|
|
Post by Stefan on Aug 21, 2024 3:58:06 GMT -5
MUEH: Regardless of 3 "X A" commands working previously, is SEEMS correct. Without qualifiers, it becomes ALL and keeps finding the 1st line.It really should be "X A NX", but NX isn't allowed. It seems NX should be assumed, like ALL is assumed. ... George,
Sorry, but I think you're mistaken and mueh is right.
The command X <whatever> should not (and did not used to) imply the ALL operand.
So a command sequence of X A ; X A ; X A should find three separate lines, each containing the letter A, because the 2nd search for A starts from the cursor position of the A-line found by the first search, and so on. At least that's how it works on version 3.1.24225 and before.
If the ALL operand were implied, every line containing letter A would be excluded - not just one line.
|
|
|
|
Post by Robert on Aug 21, 2024 8:38:20 GMT -5
Agree. EXCLUDE has never implied ALL. With no qualifier, it implies NEXT, just like ISPF does.
R
|
|
