|
Post by mueh on Apr 15, 2024 13:06:48 GMT -5
Hi George ! Installed 24106 . SORT 6 .9 .zl fails with Illogical SORT operands . If end-col is specified no problem . Thanks
|
|
|
Post by Jo on Apr 15, 2024 16:59:34 GMT -5
"CHANGE ?" results in "HELP CHANGE" instead of showing the CS/DS (Column Shift / Data Shift) mode.
Jo
|
|
|
Post by George on Apr 16, 2024 8:58:50 GMT -5
Jo: Yes, those multi-mode commands are a pain. I guess if there's a simple display answer it should always take precedence over the full HELP display. Corrected
MUEH: Well, I did say SORT had the most complicated syntax. Turned out to simply be a missing ITERATE in one of the code branches. Corrected.
Yet another fix release coming.
Thanks again to both of you.
George
|
|
|
Post by mueh on Apr 17, 2024 1:02:52 GMT -5
Hi George ! Now at 24107 lvl SORT Crash or my original Problem was that SORT was NOOP ( Msg SORT complete but no sort occured ) if FIND is done before SORT . Here the screen shot of permanent problem SPFLiteCrash.2024-04-1707-51-01.txt (465 B) To reproduce enter FIND aaa followed by SORT 11 . If RES cmd is done between FIND and SORT no problem occures . Thanks
|
|
|
Post by George on Apr 17, 2024 9:17:59 GMT -5
MUEH: Another parse Oops. SORT dopes most of it's own parsing because it has so many positional parameters, and all other commands are positional independent, which is what the new parse code supports fully. But the main search routine is used by SORT, and THAT routine is dependent on the data areas in the new parse code.
I know, that positional/non-positional format difference is a pain, but we can't just alter the SORT syntax at this point.
However, it turns out this is fixed by a simple call to an existing parse reset routine by SORT.
George
|
|
|
Post by Jo on Apr 18, 2024 4:14:31 GMT -5
SUBMIT in a modified VIEW-tab submits only part of the file. I open a VIEW session, then used FIND and F5, then modified a line and enter SUB. Resulted in only 2 lines submitted. These lines, that were found with FIND and F5. Jo
|
|
|
Post by George on Apr 18, 2024 9:44:02 GMT -5
Jo: Hmmm another one to track. Thanks.
Found it. Unfortunately a reset function did not get called if there were NO operands on a command. The call was incorrectly placed a few lines AFTER an exit test rather than BEFORE the test.
24109 posted with correction.
George
|
|
|
Post by mueh on Apr 22, 2024 2:11:34 GMT -5
Hi George ! Have a Profile with IMACRO mtest OFF . When a file is Modified elsewhere and Popup reply is reload then Imacro mtest is called . SUB FileChangeNotification() doesn't check it the same way as METHOD InitaFile(quick AS LONG) AS LONG IF UCASE$(MacName) = MacName THEN ' Is macroname Uppercase? (ON) does . It's no V3.1 Problem Thanks
|
|
|
Post by George on Apr 22, 2024 9:16:49 GMT -5
MUEH: Thanks. I've corrected it, along with a similar omission in the MEdit support.
George
|
|
|
Post by mueh on May 5, 2024 0:55:21 GMT -5
Hi George! V3.1.24124 Hex string in Find Change e.t.c are treated as character string . find x'20' doesn't find Blank it finds characters '20' . Thanks
|
|
|
Post by George on May 5, 2024 8:30:38 GMT -5
MUEH: Thanks, I'm sure it one of those 'tested', then further changes to someting else mucks it up.
George
[UPDATE] Yes, I was correct. During the old parse, the literal type was stored as a number indicating the type.
I thought, why convert it to an equated number, just use the original entered character value. So I altered the code and the Equates to the new character values.
And stupidly set the $OpXStr value to "H" instead of "X". Duh!
I'll post a corrected 24126 version.
[/UPDATE]
|
|
|
Post by mueh on May 8, 2024 6:22:58 GMT -5
Hi George ! Another Parse error at 3.1.24127 lvl . LOCATE :DASD fails with msg "Operand: :DASD, exceeds the maximum allowed Tag References" Thanks
|
|
|
Post by mueh on May 8, 2024 7:44:09 GMT -5
Hi George ! Have :DASD set to several Lines . UU :dasd cmd gets msg "No Lines found" at 3.1.24127 lvl . REVERT :dasd has same problem . If Tagname is in upercase it works . At 24069 lvl it works and sets User Line Status . Thanks
|
|
|
Post by George on May 8, 2024 8:58:58 GMT -5
MUEH: Another Oops in the Parse definition table. It basically said - no :tags for LOCATE. I had to create the tables from scratch, and used the HELP file to define the syntax. Help shows TAG (as a keyword) and 'tagname' as an operand - and I missed the 2nd. I'm sure it seems a bit odd for so many Oops errors to have crept in, but it was quite a chore to get the table created without any errors. Just for a FYI here's what it looks like. ParseModel.txt (14.51 KB) Corrected in 24129. George
|
|
|
Post by mueh on May 8, 2024 9:28:43 GMT -5
Hi George ! Installed 3.1.24129 . Locate is solved . Maybe you missed second problem i added just when you wehere logged on . if :tagname is entered in lower case for Uline Revert Find Exclude Show and maybe others lines are not found . .label can be used in lower case in cmd's . Thanks
|
|