|
Post by Stefan on Jun 17, 2024 7:52:12 GMT -5
George, There's two issue with MEDIT (I think) in v3.1.24265beta and 3.1.24168beta and possibly previous betas also. (1) A crashy looking error... - Pick your favourite filepath in FM - Make no line selections but instead enter MEDIT as a primary command and press <ENTER>. Version 3.0.24091 replies with message " No file(s) specified" - all good. Version 3.1.24168 pops up... Untrapped Error #9 (subscript/Pointer out of range) has occurred following execution of R31EE4 Press OK to continue, Cancel to terminate. The session is recoverable via <OK>, but after this kind of error, I never trust SPFLite not to stumble over something else later.
(2) MEDIT has acquired nasty habit of saving all the various files' data into EVERY one of those files. I've spent quite some time trying to figure out what triggers it to go wrong, but I have not isolated the issue yet.
- load a bunch of files from the same folder into MEDIT - start changing stuff - enter SAVE
Sometimes it's fine and the files you changed get saved. Sometimes it goes wrong and saves all the data into every one of the files.
I'll update here if/when I can fathom what triggers the error.
|
|
|
Post by mueh on Jun 18, 2024 1:46:39 GMT -5
Hi George and Stefan ! (1) A crashy looking error... Version 3.0.24091 is also not good as it should prompt for filename . Prompt was done in V2.7 .
Version 3.1.24168 pops up... ( they also occure if you issue MEDIT in EDIT session if no filename is specified ) I think the huge amount of popup's occure because this V3.1 Betas are compiled with DEBUG ON to find more errors . If you spefiy a filename on MEDIT ( either valid or invalid ) no popup's occure . If the missing prompt is solved there should be no more problem .
(2) MEDIT has acquired nasty habit of saving all the various files' data into EVERY one of those files. Stefan: If One file in MEDIT is modified SAVE should write all files unless SAVE COND is used as shown in DOC .
Hope this helps
|
|
|
Post by Stefan on Jun 18, 2024 2:09:10 GMT -5
Mueh. Thanks, I had forgotten about SAVE COND.
However, that's not the problem
I have an MEDIT session with 26 files. Let's say I change 3 of those files. I enter SAVE
ALL 26 files are saved, and ALL 26 files now contain the data from EVERY file. Following the SAVE, I have 26 identical files each one containig ALL the data.
This doesn't happen every time, so something I'm doing while editing is causing the MEDIT file separation to be lost.
|
|
|
Post by mueh on Jun 18, 2024 2:34:26 GMT -5
Hi Stefan ! Yes it occures also permanent on my system . Also when only modifying data . ( no delete of lines ) . Thanks
|
|
|
Post by Stefan on Jun 18, 2024 4:52:45 GMT -5
George,
Mueh is correct.
(1) I load 3 files into MEDIT (2) I change data on one line of file 1 (3) I issue SAVE
All 3 files are saved and all 3 files now contain the same data - everything from all three original files.
If I do the same but issue SAVE COND instead in step (3), only the changed file is saved BUT it contains ALL the data from all three files. The two 'unedited' files remain unchanged.
|
|
|
Post by George on Jun 18, 2024 9:38:33 GMT -5
Guys: MEdit save has been fixed. MEdit was all working fine (at one point) but as it typically happens, fixing some other bug altered the way the WriteFile function handled line ranges, and MEdit did not get re-tested after that fix. My bad.
The no operand MEDIT is also fixed, when I enlarged the max # of filenames to fix MUEH's problem of not enough capacity, it also let the 0 case slip in. DIMing a table from (1 to 0) doesn't sit well with the compiler.
George
|
|
|
Post by mueh on Jun 19, 2024 3:27:37 GMT -5
Hi George ! Installed 24170 and SAVE in Medit session is solved . MEDIT without filename results in msg "MEXIT requires at least 1 filename operand" ( Note MEXIT in txt ) when it should prompt for filename according to DOC . Thanks Found another Problem . When converting Edit session to Medit by issunig MEDIT filename the two =FILE> lines show now both the same file . This error is not new and occures since 23253 . Thanks
|
|
|
Post by George on Jun 19, 2024 9:35:39 GMT -5
MUEH: MEDIT / MEXIT - at least I was close, only 1 letter out. ![:P](//storage.proboards.com/forum/images/smiley/tongue.png) -- Corrected. I revised the whole MEdit startup to eliminate a bad design choice in the past, it was making the process of adding in a filename prompt messy. I hadn't noticed MEdit was also supposed to prompt with no operands. Also corrected the =FILE> entry when switching a normal Edit into a M Edit. Next Beta. George
|
|
|
Post by mueh on Jun 19, 2024 13:46:10 GMT -5
Hi George! Installed 24171 . Medit prompt and =FILE> same file are now solved . There is a problem when converted MEDIT session is terminated that the EDIT Filename is left open . This prevents this file from reopen . No problem if first file is already medit opened .
Also the Title is not reflecting the file when positioning the cursor to another's Medit file data .
V3.0.23169 is the last perfect Medit working level No need for new version today . Thanks
P.S. A debug window is also opened logging the cmd with 24171.
|
|
|
Post by George on Jun 19, 2024 14:36:38 GMT -5
MUEH: OK, I'll try and clean up these last items.
[UPDATE] OK, the first one is corrected, the file is not left 'open' incorrectly.
The problem with the title - ?? It seems to be working fine in 24171.
George
|
|
|
Post by Stefan on Jun 20, 2024 1:54:57 GMT -5
George, This is a personal observation, so feel free to ignore it as others may disagree. But while you're in MEDIT, I wonder if the =FILE> <filename> separator lines could be made a more prominent with a bit of padding. This would help when scrollong right for instance.
Similar (but not identical) to the excluded lines placeholder, e.g. =FILE> <filename> .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
|
|
|
Post by George on Jun 20, 2024 10:12:04 GMT -5
Stefan: I'll check to see if it can be added when displayed. Don't want to change the storage as it uses the normal text area and lots of file routines access it directly.
Check next beta (24172), see if it looks ok.
George
|
|
|
Post by Robert on Jun 20, 2024 11:04:23 GMT -5
George, I think if you changed the display of the =FILE> line so it was white letters on red background, it would stand out better. That's the colors we use for things like KB Recording and PowerType on the status line.
R
|
|
|
Post by George on Jun 20, 2024 12:12:52 GMT -5
Well, make your choice. ![](//storage.proboards.com/3714814/thumbnailer/drJrqabQcxHRAeNvrijZ.png) ![](//storage.proboards.com/3714814/thumbnailer/yGtBFlhIgoiNeNSGhqlA.png)
|
|
|
Post by Robert on Jun 20, 2024 14:52:51 GMT -5
I like my white-red colors better, but I don't think the dot-dash stuff is needed
R
|
|