|
|
Post by George on Nov 29, 2022 10:36:19 GMT -5
If you have a ZIP file or folder in your AUTO folder, then YOU placed them there, not SPFLite install.
As to using
AUTO EDIT default\bas.auto
to edit another AUTO from another Edit session, what's wrong with just EDIT, which opens a file selection popup in the AUTO folder for you to select the other AUTO file you want to Edit.
And the simplest way to edit the AUTO file for a current Edit is a small macro.
' AUTO.MACRO
' This macro will open the .AUTO file being used in the current session.
'
IF Is_FM THEN Halt(FAIL, "AUTO only works in non-FM sessions")
USES "File"
DIM ProfName AS STRING value Get_Profile$("NAME")
DIM PathName AS STRING value Get_INI_Path$
DIM FileName AS STRING value Pathname + "AUTO\" + ProfName + ".AUTO"
DIM FileID AS LONG value 0
'----- If AUTO file doesn't exist, create an empty one
IF File_Exists(FileName) = 0 THEN
FileID = File_Open(FileName, "OUTPUT")
File_Close(FileID)
END IF
'----- Open an existing AUTO file
SPF_Post_Do("EDIT " + $DQ + FileName + $DQ)
halt(0)
|
|
|
|
Post by Stefan on Nov 29, 2022 10:45:55 GMT -5
I once had a go at an AUTO file for PowerBasic.
It still isn't finished, but I observe that many of the entries 'do not work' correctly when it comes to colorising SPFLite Source files.
Oh, don't get me wrong, I populated it from SPFLite source code, so the most relevant keywords are there, except they don't work.
It all went wrong one day after I had added more of the PowerBasic language components, for example a bunch of %constants, etc.
Suddenly the bred-and-butter colorisation went haywire.
The issue, as far as I can tell, could be that my PBASIC.AUTO file has well over 20000 entries and is around 1.8meg (and counting) in size.
Perhaps that's a bit more than SPFlite can digest in an AUTO file list? Or maybe it takes too long to paint the screen? No idea, I haven't checked the code.
I also prefer to have separate AUTO files for different BASIC dialects. For instance the list of SPFLite macro call (e.g. SPF_CMD(), etc) have no business being in the VBA basic file.
So I rather not confuse myself calling apparently perfectly coded routines or keywords which simply don't work.
Maybe the right way to go would be some kind of #INCLUDE capability for .AUTO files. Thhen one could build up an AUTO file using approriate component lists for each (in this example, BASIC) dialects.
Combined wih separate INCLUDE files for difference BASIC modules, this would also help to keep the list of entries down.
No point parsing a bunch of statements and constants from, say the Windows Dialog 'module' when the code doesn't make any such calls.
|
|
|
|
Post by George on Nov 29, 2022 10:57:24 GMT -5
Stefan: Well if you've got over 20,000 entries, you must be putting in one huge number of Windows API functions and equates. My PB AUTO file is only a couple thousand, and it does my needs quite well. Attached: Does a 20K one cause problems? Not that I'm aware of, but what I found in doing mine was that it is extremely easy to introduce duplicates, and if dup entries have different color values it sure makes things look like the lookup is wrong. You may want to review that possibility. George Attachments:BAS.auto (59.11 KB)
|
|
|
|
Post by Stefan on Nov 29, 2022 11:37:15 GMT -5
Alas, the duplicates issue is addressed by my AUTOCLEAN.MACRO
It basically changes the first two bytes of any duplcate entry to ';;', effectively commenting them out I've not been doing anything with the PowerBasic AUTO list in ages (as in several SPFLite releases ago), but I do recall that some 'known' keywords were not colorised, or were colorised incorrectly, sometimes even inconsistently depending on context in the code statement.
Thanks for the BAS file. I think I'll just replace mine with yours.
|
|
|
|
Post by George on Nov 29, 2022 11:54:10 GMT -5
If you see anomalies, let me know. I'm not AWARE of any failings, but that's not saying a lot.
George
|
|
|
|
Post by Stefan on Nov 30, 2022 10:45:46 GMT -5
George, I had a dodgy SETEDIT.AUTO file, in that it contained duplicate entries. It worked fine (no complaining NOTE lines) when used to open the SET session. For some reason I had a file call somename.SETEDIT and when I loaded that, I received Alerts about dusplicate entries. Not a biggie, but it looks like AUTO-file-validation is not applied when opening the 'special' sessions.
Thx for the comments in SET sessions
|
|
|
|
Post by George on Nov 30, 2022 12:47:25 GMT -5
Stefan: Not sure what you mean about AUTO file validation. The ClrLoad routine, which is the only place AUTO file data is loaded, does the validation, there are ne exceptions.
George
|
|
|
|
Post by Stefan on Dec 1, 2022 6:08:56 GMT -5
George,
I do not presume to disagree with your explanation or the code... but try this...
Save your SETEDIT.AUTO file with a deliberate entry duplication. Issue the SET command The SET-EDIT session opens - no entry duplication report from AUTO-colorisation
Take any normal file you like and rename it so it has a filetype of .SETEDIT Load it into SPFLite The Edit session opens and you see duplicate entry warnings from AUTO colorisation
A classic case of "In theory there is no difference between Theory and Practice, but in practice there is"
|
|
|
|
Post by George on Dec 1, 2022 11:11:31 GMT -5
Well, I was partly right, the errors WERE being detected, but ClrLoad itself doesn't insert the messages, it leaves that for the caller to do. And the new code for AUTO support in those special tabs missed that.
Good catch. I'll update the Beta.
George
|
|
