EFT - what am I doing wrong, please?

Stefan, you have a knack for creating conundrums. Let me put on my cogitating hat and see what I can come up with.

1. You do remember that you cannot "drag" a profile, right? These are Configuration entries, which are stored in the SQLite database. Any .INI files you have will NOT be used as profiles. That's the old, OLD way.

2. Why an empty file? If I understand your explanation right, it sounds like the file you copied WAS empty. It that correct, or not? If it were NOT empty, you should have seen a complaint that the profile INI_WSV was not found. If you didn't, this may be a bug. I don't believe it should have been silent on this matter.

3. The extra line that you don't normally see? Perhaps you have not been observant. The ==EFT> line has been there for some time. It is there to show you that you are operating under an EFT, and it shows you the one that matched the file name in question.

4. You said, "and the AUTO file related with this edit tab is INI.AUTO, and not the INI_WSV.AUTO I expected."

How do you know that is the auto file in effect? How do INI.AUTO and INI_WSV.AUTO differ so that you know which is which?


In looking at the Help, it is a little vague about how it goes about finding an AUTO file. But, I created a macro called AUTO.MACRO that I use to edit the auto file for a given edit file. It's like this:


' AUTO.MACRO
' This macro will open the .AUTO file being used in the current session.
'
IF Is_FM THEN Halt(0, "AUTO command must be issued from an Edit session")
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)



Maybe this will help you.

The short answer is, I am not seeing anything especially wrong with what you're doing. I don't see any EFT usage errors here.

R

I just did a test on a .MACRO file. In the edit session, I issued an AUTONAME ? to see what it's auto file name was, and it returned NONE. I have an EFT entry of MACRO = BAS, and I have Profile: BAS on the status line. And, my MACRO file is being colorized according to BAS rules.

I suspect there is some bug (?) when EFT is in effect, the AUTONAME logic is not respecting the NONE value, which is supposed to respect the default <profile-name>.AUTO.

The behavior doesn't make sense to me.

BTW, I have to say that using AUTONAME NONE on a file like MYFILE.BAS to mean the auto file is BAS.AUTO just seems wrong. Why can't the actual name be used here - AUTONAME BAS - instead of NONE? I find this very confusing.

R

Guys,

I missed the AUTONAME parameter altogether.
I appreciate that it is intended to 'override' the normal (default) effect where SPFLite automatically uses an xxxxx.AUTO file to display the data, WHEN...
a) a  'xxxxx'.AUTO file exists AND
b) 'xxxxx' is the same as the file-type/extension OR the same as the profile name assigned by EFT

If so, it seems to me we need 3 settings for AUTONAME.
1) AUTONAME DEFAULT   to allow the normal/default process to take place
2) AUTONAME ooooo      to instruct SPFlite to use a particular ooooo.AUTO
3) AUTONAME NONE       to prevent any AUTO file being used

Option (1) AUTONAME DEFAULT should be the 'default' setting in all Profiles.

Stefan,

The empty-file issue is a puzzle, Something is clearly not right here, AKA seems to be a bug. Time for a George intervention.

George,

IIRC, I *did* voice concerns about the AUTONAME syntax, because NONE doesn't really convey what is actually going on.

Since my last post, I have been giving this some thought. Right now, this is your syntax:


AUTONAME

   AUTO-filename | NONE | ?

Operands

AUTO-filename
   The name of the AUTO file to be used with the current Profile
NONE
   Removes any existing AUTONAME value
?
   Display the current status of the setting.


I feel that having an AUTONAME Profile option at all misleads the user, because "NONE" doesn't mean "none" the way other uses of "none" are used in SPFLite. I believe that AUTONAME should not exist in its current form. Rather, it should be an option of HILITE, since the xx.AUTO file controls how files are highlighted.

This is how I would picture an improved HILITE to address this:

HILITE {
   [ ON | OFF ]
   [ AUTO [ name | * ] ]
   [ FIND ] 
   [ ? ]
}

Here, 

   HILITE AUTO name = AUTONAME  name

   HILITE AUTO * = AUTONAME NONE

And for clarity, "name" cannot be ON, OFF, AUTO or FIND.


In the Profile display, if AUTO never was set with a 'name', you'd show AUTO *

Perhaps the existence of 'name' could be determined because it's none of the other keywords. When HILITE was used without the 'name' or * specified, you would see that neither of them are present. You'd only need * to shut off an existing 'name' option.

I realize that changing the syntax of AUTONAME, now that it's implemented, would be a problem, and adding more operands to HILITE complicates it.

Based on your earlier reaction to this feature, I don't expect you to change it now. But, this is my sincere opinion.

R

Robert: I've left it as it was - a separate primary command AUTONAME, with 4 possible values:

• ?    -  Display current setting of AUTONAME
• *    -  Set AUTONAME to the actual Profile name
• xxx -  Set AUTONAME to a specific xxx.AUTO filename
• NONE - Set AUTONAME to NONE. i.e. colorization will be turned off as if no AUTO file exists