|
|
Post by Jo on Jun 23, 2020 18:16:05 GMT -5
RELOAD on a Browse-session helps to easily test my XFORM Macro (Thanks George)
PROF EDIT can now change all variants of IMACRO and XFORM. (Thanks George)
Now I have a problem to set any of them OFF via commands "IMACRO OFF" or "XFORM OFF" , i.e. IMACRO OFF says it's OFF, but isn't, XFORM OFF says it's OFF, but isn't. Maybe its the way my IMACRO works: It uses SPF_Shell to execute an external Rexx which creates a temp clip-file, then uses SPF_Post_Do to open a CLIP tab with "CLIP _clipfile". The (CLIP)-tab uses PROFILE DEFAULT, which had IMACRO NONE and XFORM NONE when starting my tests. Now there is "IMACRO myname OFF" in the DEFAULT-Profile, but still "IMACRO myname ON" in the CFG-Profile. Mystery for me, and with "File Manager" "Configs" I can change/correct that.
2. on my wish-list: when Filewatch detects an external file change, and I answer YES to reload the file, XFORM is not executed, instead the file is read by SPFLITE as a normal ASCII file. I've used Georgs XFORM XCFG and browse SPFLite.CFG - the next browse on any file triggers the change. I think, XFORM READ should be executed in this case.
3. on my wish-list: colorization as defined in the associated .AUTO -file is not done when XFORM is in use. It would be nice to have it.
4. is a point I already found in the early discussion (Robert/George): SAVEAS currently does not call XFORM WRITE, but I think it should. CREATE and REPLACE will save the data as formatted by XFORM READ and now on screen, which is fine and I like that. But when I started with a "(X) View" session, I cannot SAVE, just SAVEAS, so it would be fine, when XFORM WRITE would take care of my modified data and reformat it. Or, maybe, allow SAVE on an "(X) View"-session, so the programmer can decide what to do. Hm, I think I like this idea.
Jo
|
|
|
|
Post by Jo on Jun 23, 2020 19:41:43 GMT -5
Robert, thanks for your reply. Now I see, I was not clear on point 2.
Point 2. Yes, it would be fine, when reload on Filewatch would do the same as a RELOAD command. Unfortunately it does not. You may try it easily with Georges XCFG macro: Create a CFG-profile with XFORM XCFG ON, then go to Browse the active SPFLITE.CFG file. You see profile-names. Then browse another file or select any profile in the Configs-tab. The Filewatch-prompt comes up, say YES and be surprised.
Point 3. "normal" is relative :-) The file is nice when colored, and XFORM adds some additional text and slightly reformats/realigns the text. When the color is lost now, it is harder to find the things ...
Jo
|
|
|
|
Post by George on Jun 24, 2020 12:34:17 GMT -5
OK, testing IMACRO OFF or XFORM OFF works fine here. i.e. If I have XFORM XRW ON, the XFORM is invoked. If I do an XFORM OFF, it switches to XFORM XRW OFF, and opening the file ignores the macro as it should. I can invoke from FM using /ON or /OFF line commands. Similar results with IMACRO, all looks fine. I also did the IMACRO invoking a CLIP session with SPF_Post_Do, worked fine, the default Profile was not altered.  ?? As for SAVEAS, no, XFORM won't be invoked. When we get into the subtleties of doing a SAVEAS to a possibly different file-type, meaning a different Profile comes into play, there's no way I'm going to support that. A FileWatch re-load will now do the load using the XFORM macro. George |
|
|
|
Post by George on Jun 24, 2020 15:56:27 GMT -5
Robert: No, I don't remember agreeing to that. Show me.
There is a lot of totally 'grunge' coding to do this, I am not convinced it's worth it. This is just more 'clutter' coding, we have too much of that already. There are just too many hidden interactions, like the recent change to handle missing Profiles, works like a charm - and mucked up something else - and right now, I can't even remember what that problem was.
I just have to stop reacting to all these "wouldn't it be nice if ... " type requests. They're coming in non-stop and my poor brain just can't manage them any more. I want this thing stabilized. We said we'd back out of this constant update mode, and yet we're still at it. It has to stop.
I want this next release to go out, once you finish the XFORM tutorial, and then I really want to shut down changes.
I'm sorry guys, but I simply have to back out of this more.
George
|
|
|
|
Post by Jo on Jun 24, 2020 16:51:02 GMT -5
Robert, George, I understand, that SAVEAS with XFORM is not an easy way and I would suggest not to allow it.
But what about SAVE with XFORM, even an Browse, View or RD-Only ? The Macro can decide what to do, disallow the XFORM SAVE or whatever.
Jo
|
|
|
|
Post by George on Jun 25, 2020 9:09:18 GMT -5
Robert:
For SAVEAS, I could weasel out because I said I'd 'look at it'. I looked. It's still a mess. Remember SAVEAS is a complex function as it has to do the save itself and then rename and re-establish everything about the tab based on the new name, Profiles, AUTO colors etc.
I will look again on the basis that the file-type cannot be allowed to change.
Jo: Opening up BROWSE, VIEW and RO files to SAVE is a real extreme example of what I referred to a 'clutter code'.
It means opening up and allowing SAVE for those guys in the command table, and then going on a hunt through the code for all the places where a new test now has to be added to prevent SAVE. i.e. IF NOT XFORM-MODE THEN Do-Not-Continue (with an error message of course) followed by some bail out code to get out of the routine back through possibly several nesting procedures back to the command line.
As I am prone to say - "Sheesh! If you were going to change the file, why are you even in BROWSE or VIEW?"
Alternative:
CUT the entire modified VIEW session
CANCEL
Re-Open in Edit via XFORM
Enter D/ on line 1
PASTE in the original session
Do the SAVE
|
|
|
|
Post by George on Jun 25, 2020 12:48:16 GMT -5
Robert: OK, SAVEAS for XFORM is now working. Interesting in that during testing it showed up a weirdness in the FileWatch routine due to the different handling of XFORM WRITE. WRITE is operating in a different thread (all macros operate in a separate thread so a looping macro can be killed, and not bring down SPFLite).
For a while I thought I was experiencing time travel, I had things happening in seemingly impossible combinations.
George
|
|
|
|
Post by George on Jun 25, 2020 15:48:01 GMT -5
Robert: Yeah, this was really weird. If I just loaded a file and did a SAVEAS, no problem.
If I did the same, using XRW.MACRO to read/write the file, every time I did a SAVEAS, I immediately got a "modified elsewhere" message on the next (Enter).
And debugging showed the Directory read to see what had changed, was happening BEFORE the directory read that save the initial FileWatch values.
Unusual debugging session, to say the least.
George
|
|
|
|
Post by Jo on Jun 26, 2020 3:30:46 GMT -5
now on v2.2.20177:
1.) George, yes, IMACRO ON and OFF, XFORM ON/OFF all work fine. In nearly every combination. Just this one case ... I'll nail it down on some rainy days.
2.) Filewatch reload works fine with XFORM. Thanks !
3.) .AUTO Colorization is gone when XFORM XRW ON, color comes again when XFORM OFF. (still on my wish list :-)
4.) SAVEAS now works without any Problem ! Good job, thanks !
Jo
|
|
|
|
Post by George on Jun 26, 2020 9:05:06 GMT -5
Jo: OK, I've activated AUTO colorization, I guess if it gives weird results, just turn HILITE AUTO OFF.
George
|
|
??