|
Post by MUEH on Apr 6, 2017 13:00:10 GMT -5
When a File is converted to M-Edit by issuing MEDIT in EDIT session following happens on first file . 1. If 1'st file is modified =FILE> it's not changed to =FILE* and therefore changes are not saved by SAVE cmd . 2. Even if no change is made and CAN is done 1'st File EDIT fails with File already open in this Tab . ( only FM Tab is open ) Handle Viewer shows that File (RWD) for Path remains open . ( compared to not Converted Edit session ) . SPFLite must be ended to get Problem solved . 3. D(etach) of first File results in Crash . I am not shure if this is a Problem since Doc shows that MEDIT wil convert EDIT to M-EDit session but it is Recomended to open M-Edit in FM by M cmd . Therefore to create working M-Edit session the only way would be M cmd in FM . I like that Powerfull MEDIT cmd . Thanks
|
|
|
Post by George on Apr 7, 2017 12:04:58 GMT -5
MUEH: Hmmm, converting the tab from a simple edit to a MEdit session is supposed to be handled.
When you issued the MEDIT filename, was it for the 2nd filename (as it should be) or the existing edit filename (which I thought would be rejected)?
I'll have a look at this.
And yes, I agree, MEDIT is extremely useful, especially when a large program is stored in multiple INC files, and you want to make some global changes. I can remember in the old mainframe days working on some programs that were in 40-50 modules. I'd have given my eye teeth back then to have a MEdit type support.
George
|
|
|
Post by George on Apr 7, 2017 21:23:50 GMT -5
Indeed. Robert deserves full credit for MEdit , I may have coded it, but it was all his idea.
|
|
|
Post by George on Apr 10, 2017 13:18:30 GMT -5
MUEH: OK, both MEdit problems found and corrected. The current state of the modified flag was simply not being migrated to the revised internal MEdit structure.
The lockup of the filename was basically a glorified typo, it was enqueing on the newly added MEdit filename at the point where it should have been the existing filename.
George
|
|
|
Post by MUEH on Apr 21, 2017 14:19:24 GMT -5
George: Installed 8.5.7110 . Problem 2 is fixed but Problem 1 (edit file1;medit file2 and change to file1 it doesn't change to =FILE*) is not fixed . Line cmd D(etach) removes now only =FILE> line . Primary cmd CAN terminates complete SPFLite . Thanks
|
|
|
Post by George on Apr 22, 2017 11:41:41 GMT -5
MUEH: OK, the Detach error I never even noticed in your original post - my total oversight. As to problem 1, I just tested the dist. version and you're right - not fixed - - I KNOW I fixed and tested this - OK, Back to the drawing board. George
|
|
|
Post by George on Apr 23, 2017 12:39:27 GMT -5
MUEH: I may have had a version-itis problem at my end. I downloaded and reinstalled the version on the web site and the modified problem is working correctly. Make sure you're running 8.5.7110.
I will go now and check out the Detach problem.
George
[UPDATE] OK, the Detach is another Oops! in the conversion from a single edit to an MEdit session. I guess this just has not been done by many (if any) users. Detach is fine if the MEdit session is started from FM.
The CAN exiting SPFLite I cannot reproduce, do you have specifics as to your sequence of events?
Gerge
|
|
|
Post by MUEH on Apr 23, 2017 13:47:29 GMT -5
George: Dowloaded from SPFLite Site but get old 8.5.7110 version . Same download size and chm and exe date 20/04/2017 . Installed it to empty path . Will try tomorow again . CAN problem occures only if converted File1 is modified ( change cmd or overtyping ) . Change to file2 only gives no Termination of SPFLite on CAN of M-Edit . Thanks
|
|
|
Post by George on Apr 24, 2017 9:46:46 GMT -5
MUEH: There was never more than one version of 8.5.7110 posted. (i.e. no 'corrected' version)
I tried variations of modified / unmodified / altering file 1 / altering file 2 / etc. and CAN works fine for all of them.
What's your setting in Options => File Manager => Close SPFLite with last tab? (Just guessing here)
George
|
|
|
Post by MUEH on Apr 24, 2017 14:07:52 GMT -5
George: FM Setting Close SPFLite with last file tab is not on . SPFLite seems to end abnormal but without Crash Msg since on new start FM Displays File Path/Name C:\ instead of last used FLIST Recent Files . Installed 8.5.7110 to standard dir's and CAN Problem is Permanent Reproducable when Converted File1 was changed . Don't know why it is not reproducable on your side .
|
|
|
Post by George on Apr 24, 2017 15:39:45 GMT -5
MUEH: OK, I've managed to duplicate the problem. Somehow it makes a difference if the modified state is set before or after the conversion to MEDit state. Now I can go track it down. Thanks for being patient. George [UPDATE] This may be a while. What I had failing consistently now seems to go into hiding when I try to peer a little closer. Adding some debugging code to zero in on where it's failing simply makes everything work perfectly. And all this time I was taught that computers were repeatably consistent. G.
|
|
|
Post by George on May 4, 2017 14:07:58 GMT -5
MUEH: I've been trying this periodically, but can't get a failure I can chase. Are you still getting this consistently?
George
|
|
|
Post by MUEH on May 4, 2017 14:59:07 GMT -5
George: CAN Problem is permanent . As a test case i do edit dos.macro in FM medit cls.macro change macro MACRO all can
|
|
|
Post by George on May 5, 2017 12:05:55 GMT -5
MUEH: Can't fail it. Can you send me
SPFLite.INI MACRO.INI MACRO.AUTO (if it exists) dos.macro cls.macro
Maybe with all the exact same files I can get this thing to crash. Just send to support@spflite.com
George
|
|
|
Post by MUEH on May 5, 2017 14:45:28 GMT -5
George: Sent 7z file of SPFLite path . Png file contains screen shot . Note that DOS.macro (file 1) was changed but =FILE> line is not changed . Are you testing with a fix for this Problem ?
|
|