I have a macro working in KM 75.1 and I am trying to find out why a part is not working in 75.0

The code in the macro is as follows:

_Adblockplugin_rules {
macroinfo=_("Edit the rules file");
$cmdline = getSecureExtensionHandler("txt");
$acfg_File=$ARG."."."txt";
$__path=getfolder(ProfileFolder)."\\".$acfg_File; 
$__data=readfile($__path);
$__data==""?&_Adblockplugin_FileNotFound:exec(sub("%1",$__path,$cmdline));
}

That code is called from this menu item:

    setmenu($_adA, macro, "View/edit rules", "_Adblockplugin_rules(adblock)", 1);

I correctly obtain the file when using KM 75.1, but nothing at all happens when it runs in 75.0.

The difference seems to be the code needed in main.kmm.

The code being called in main.kmm is this in 75.1:

function getExtensionHandler($ext) {
  return _getExtensionHandler($ext, "open");
}

function getSecureExtensionHandler($ext) {
  return _getExtensionHandler($ext, "edit");
}

The code being called in main.kmm is this in 75.0:

getExtensionHandler{
# use for text files
$__desiredAction="open"; &_getExtensionHandler;
}
getSecureExtensionHandler{
# use for script files
$__desiredAction="edit"; &_getExtensionHandler;
}

Is there a simple change that I can make so that the macro will run in both KM versions?

Hmm... the older calls a macro (which I'm well familiar with from older versions), the other a "function" (very unfamiliar to me so far)
Of course it's possible to use both methods, after checking if the first version left $cmdline empty yet.

But makes me wonder - are all old macros using those getext-modules broken now?

You are right. $cmdline is empty in KM 75.0. I just set it three lines above in my macro.

Now I have to find where it is being reset.

OUFF... Did a quick test with one of my old macros - and it still works!
Then tried 5 syntax variations involving macros and functions - all worked!!
?miracle? ==> completely confused....

HA - found it :cool:
The miracle is worked in compat75.kmm

==> to have it working in ALL KM-versions, simply use the good ol macro syntax

_Adblockplugin_rules {
macroinfo=_("Edit the rules file");
$__path=getfolder(ProfileFolder)."\\".$ARG.".txt";
$__data=readfile($__path);
if ($__data=="") &_Adblockplugin_FileNotFound;
else {
$ext="txt"; &getSecureExtensionHandler;
exec(sub("%1",$__path,$cmdline));
}}

Thanks siria,

Your idea works. This is now my code:

_Adblockplugin_rules {
macroinfo=_("Edit the rules file");
$__path=getfolder(ProfileFolder)."\\".$ARG.".txt";
$__data=readfile($__path);
if ($__data=="") {&_Adblockplugin_FileNotFound;
 } else {
 $ext="txt"; &getSecureExtensionHandler;
 exec(sub("%1",$__path,$cmdline));
 }
}

_Adblockplugin_logs {
macroinfo=_("View the log file");
$__path=getfolder(ProfileFolder)."\\".$ARG.".log";
$__data=readfile($__path);
if ($__data=="") {&_Adblockplugin_FileNotFound;
 } else {
 $ext="log"; &getExtensionHandler;
 exec(sub("%1",$__path,$cmdline));
 }
}

That is fixed, but brings me to another question. What is the difference between get "getExtensionHandler" and "getSecureExtensionHandler"? I had assumed that the secure would let the user change and save the file while the other would not let the file be changed. However it seems that I can edit and save both the rules and the log. The fact that a user can change the log is not too important. Perhaps it is a function of Notepad.exe that 'open' and 'edit' as $__desiredAction does not change anything.

No it has nothing to do with write-protection or anything.
The "secure" in the name is quite misleading, no idea why it was named such.
The difference is simply that one uses the program you defined for your system as the "open" command, and the other what you defined as "edit" command for that filetype.
For most filetypes exists only an "open" command anyway, but e.g. html-files have an "edit" version too. The open-command calls a browser, the editor some other tool. Perhaps also different for pictures, a viewer and an editor.

PS: the extension $ext you send to this macro needs not necessarily be the same as the file-extension. For example we could use $ext="ini" to look up the default editor for ini-files, then use its default program to open a kmm-file, hoping the chances are higher it may open in a program with syntax highlighting or so.

Anyway, getext just opens what's defined in the users OS for a given filetype. Modern systems have gotten awfully obfuscated, but there's a very handy and popular filetypes-manager by nirsoft.

Thanks again, siria,

Now I must wait some time. When the minimum interval is one day for an automatic, testing the automatics takes some time.

I guess I should use the time to put the _() translation in for all the text presented to the user. I never claimed to be a wordsmith, so I better check also the readability of the text that I hurriedly stuffed in the macro during the design.

I have some time off next week so really late this month, if I get the 'go ahead' from Dorian, maybe I can present this work.

Years later...
Somewhere in the forum it was mentioned (long ago) that the KM-Debugger has a prob with the COMPAT75-Macro, and disables it? That would kill some important helper-macros.
No idea if that was ever fixed (or where that debugger-thing is now to be found ), but wanted to find a combined way that's using in OLD KM the *Macro* and in NEW KM the *KMM-Function*

____Macros for OLD KM:
$ext="kmm"; &getExtensionHandler;
exec(....$cmdline....);

____Macros for NEW KM75.1+:
$cmdline=getExtensionHandler("kmm");
exec(....$cmdline....);

____Macros for ALL-KM:
$ext="kmm"; $cmdline=""; $_x=getExtensionHandler($ext);
$cmdline ? 0 : $cmdline=$_x;
exec(....$cmdline....);

Seems to work in KM154....KMG74, interestingly without any errors.
In newer KM in theory too, but can't test myself currently.
Just wanted to note this somewhere for All-Version-Macros.