I was trying to make a script that must run when the page has been loaded and looks like doesn't work.

I mean, does this works?:

macroname{
injectJS("jscode");
$JSdoit = "the js function to run";
&hndlDocs;
}
$OnLoad = $Onload."macroname;";

Looks like can't run. Why?

Note: yes, the names of hndlDocs and JSdoit are different in newer versions, I'm just using the old declaration (0.x 1.x) that are the same functions.

Hard to tell... you may have to post the whole thing for others to test...
Unless it's just the spelling error in your second OnLoad, is it only here or copied directly from the macro?
But basically injecting JS OnLoad works, have used such macros myself.
Does it work if you call it normal, not OnLoad?

PS: Do you have an editor with kmm code highlighting? Couldn't live without it, and kko's version (Scite) still has the best layout, have it just modified a bit with newer strings. Although the prog itself has a horrible handling.

But frankly I have TONS of probs with injecting scripts *groan* For one thing, since KM1.6 they don't work anymore line-by-line, but often simultaneously, for example if I toggle a setting that's needed for the script, and after injecting want to toggle it back, nothing happens - it was toggled back BEFORE the script even started!! Drives me crazy, can only workaround it with an alert-box as a break in between.
And KM17 even has a bug with injectJS. Only works with open(javascript..), but that can't return variables and has no build-in JS toggle.
Which KM version are you using?
And countless probs with the scripts itself.... urgh, better stop now :-(

Just wondering... you are not only injecting one script, but directly afterwards are injecting another with another method? I'd have to look up the details for that way in main.kmm, but am sure you already did that yourself

Ah, and guess the encoding for macros should always be utf-8, another fave trap...
Then again, only needed if exotic characters are in it, otherwise doesn't matter?
There are so many reasons why something may not work, ouff...

And does the Error console say anything??

And just in case, it's better to put the whole code into a variable first, then inject only the variable....
(I'm going to edit this post a hundred times, remembering more possible reasons every minute )



Edited 4 time(s). Last edit at 09/03/2014 07:54PM by siria.

Yes, the code fires correctly when doing with an accelerator.

Indeed the OnLoad works with macro language code, but not with this injectJS (this or any other).

Anyway, test it for yourself (because you are better in macro language). It is an approach to that "requested" (demanded) top bar in fullscreen when someone came to the forum requesting a Chrome-K-meleon GUI like.

Also, one question, is it possible to fire macro language code within a JS code (".somecode.") or call macro language functions and use JS variables in that macro language?

I'm using K-meleon 74 RCu3.

Anyway, you maybe need to touch something as the &hndlDocs or JSdoit declarations and because I made somethings towards the accelerator call:

injectbar.kmm

EDIT: I uploaded a version where I tested if I could run macro language from the JS code, that is the variable $somecode. Ignore it. It just was a test, not part of the actual JS function.

EDIT2: where is the editor? I usually do by open close of KM error "catching".



Edited 2 time(s). Last edit at 09/03/2014 08:31PM by JohnHell.

Quote
JohnHell
Also, one question, is it possible to fire macro language code within a JS code (".somecode.") or call macro language functions and use JS variables in that macro language?

Don't I wish... Not to my knowledge, but perhaps a developer can figure out some trick?

The one thing that is possible in KM1.6 (and hopefully again in 74?) is to return a variable by using $_x=injectJS(".... return ..."); Then this value can be used again in following macro actions.
Syntax example:
$_code="(function(){var x=navigator.vendorSub; return x;})()";
$_vers=injectJS($_code);
alert($_vers,"test injectJS return");

-----

Looking at your code, the syntax highlighting shows a prob:
At the end of the long code block, there's a " too much.
It should end with ....input_1); }".$somecode);
-----

I'd absolutely put the code into variables before injecting it
-----

You're using:
$JSdoit = "destroykmbar();";
&hndlDocs;

but the 74 main.kmm spells it so?
$JS_doit
&JS_hndlDocs

-----
When using injectJS and jshndldocs it's "normally" not necessary to toggle JS explicitely, that's automatic. Although just recently noticed, sometimes it may still be necessary, depending from the script. Ah that was when I just attached a script as src-file to a html-page, the attaching works without toggling but then the attached script needed extra permission again!

-----
Not sure, but you may have to experiment more with that injecting construction. Just wondering, why do you split the code? Has it something to do with frames or such? Then again, for frames there is (was?) some extra function. Am not quite sure if you don't possibly confuse something there? injectJS IS already the command to inject, not just the code which is injected with jshndldocs. That are two completely independent and different ways to inject code.



Edited 1 time(s). Last edit at 09/03/2014 09:12PM by siria.

Quote
siria

Looking at your code, the syntax highlighting shows a prob:
At the end of the long code block, there's a " too much.
It should end with ....input_1); }".$somecode);

As I said above that was a test, a tried to insert a macro language function through a $somecode variable with a macro language function. That worked but with the alert tested... I don't know further.

Quote
siria
You're using:
$JSdoit = "destroykmbar();";
&hndlDocs;

but the 74 main.kmm spells it so?
$JS_doit
&JS_hndlDocs

Yes, I know, but I carried the old macros (indeed I have a file called old macros for reference and use) with the old declarations. This is because confused me a lot the way were declared from that change.

But the code itself is the same in both, just changes the name, nothing else.

But in cause you doubt it, I already used $JS_doit and &JS_hndlDocs and does the same, that is nothing onload, if I call it with an accelerator, no problem.

Quote
siria
When using injectJS and jshndldocs it's "normally" not necessary to toggle JS explicitely, that's automatic. Although just recently noticed, sometimes it may still be necessary, depending from the script. Ah that was when I just attached a script as src-file to a html-page, the attaching works without toggling but then the attached script needed extra permission again!

This one needs it. I guess it is because I'm using the DOM create and remove elements.

Quote
siria
Not sure, but you may have to experiment more with that injecting construction. Just wondering, why do you split the code? Has it something to do with frames or such? Then again, for frames there is (was?) some extra function.

What do you mean by split :-? If you mean by the check of fullscreen status, it is necessary because they are actually independent. Yes, maybe I could inject all in a whole and then just call the function to destroy elements. But I find clearer the other way without mixing things. Also it "resets" the JS in some way, at least in my mind...

Quote
siria
Am not quite sure if you don't possibly confuse something there? injectJS IS already the command to inject, not just the code which is injected with jshndldocs. That are two completely independent and different ways to inject code.

Probably, as I reused the code from some macros, maybe that is the reason.

Could you please post an example?

I really have a mix on my head with all those $JS_doit, $JS_func, $JS_last, $JS_fail and hndlDocs (and hndlDoc) when the actual injection is made by injectJS.


EDIT: but I forgot to ask, did it work for you onload?



Edited 2 time(s). Last edit at 09/03/2014 09:35PM by JohnHell.

Quote
JohnHell

Quote
siria
It should end with ....input_1); }".$somecode);

As I said above that was a test, a tried to insert a macro language function through a $somecode variable with a macro language function. That worked but with the alert tested... I don't know further.

No you misunderstand, the prob is not $somecode, it's the unclosed ." behind it.

$JS_doit / &JS_hndlDocs
Seriously, if you ARE making this macro for KM74, and for another person, don't you think it would be time to finally use the current spelling? And even if the old still works for you, but I wouldn't bet my head that it works 100% the same. And there is just no reason for using it, it's only confusing for the rest of us to have different spellings.

Quote
JohnHell
What do you mean by split :-? If you mean by the check of fullscreen status, it is necessary because they are actually independent. Yes, maybe I could inject all in a whole and then just call the function to destroy elements. But I find clearer the other way without mixing things.

Guess we're really talking chinese here No I didn't mean the pref-toggles etc, just the JS code itself. Of course your scripting knowledge is about 1000x better than mine, which is nearly zero, but wouldn't it be possible to append this tiny separate part:
"gokmbar();";
in the same line as the big script block, as part of it? Then also you wouldn't need the jsdoit and jshndldocs at all.
For an example look in my previous post above: A variable for the code, then injectJS($_JHcode) - that's ALL that's needed! The alternative via jsdoit etc. may have other advantages, but frankly, too complicated for me as well, struggling hard with the simplest JS.

Must admit I haven't tried that macro yet, so far only looked at the code, and in case you wanna try it, have finally uploaded kko's editor, with my little updates. Look in the extensions forum, my last post in the javascriptia thread. With that editor you can see at the color coding that there's something missing in the long script block. Which is the unclosed " after the $somecode.

Believe me I'm not good at all in scripting. I was all this afternoon trying to make work all the DOM manipulation and so on and just only in a normal html file, not inside K-meleon, that is crazy because all code must be in one line

About the somecode ending... no... it is ok. This is a sreen capture of mediafire (I didn't know Mediafire was going to show the file as text Sorry for that). Maybe 1.6 not showing the edge of the MediaFire viewer?

Quote
siria
$JS_doit / &JS_hndlDocs
Seriously, if you ARE making this macro for KM74, and for another person, don't you think it would be time to finally use the current spelling? grinning smiley And even if the old still works for you, but I wouldn't bet my head that it works 100% the same. And there is just no reason for using it, it's only confusing for the rest of us to have different spellings.

You are right, but, do you know what I found while I tested in between my last reply and yours...? that the newer is doing very weird things.

I tried to use the separate $JS_func (used by the new &JS_hndlDocs) to include the code and looks like you can't have inside $JS_func various "function functionname(){}" declarations as only the last one is recognized and I need various.

The old &hndlDocs doesn't have that problem and I guess it is because of the function() declaration at the beginning of the new &JS_hndlDocs.

Damn it.

And still onload doesn't work.

Quote
siria
but wouldn't it be possible to append this tiny separate part:
"gokmbar();";
in the same line as the big script block, as part of it? Then also you wouldn't need the jsdoit and jshndldocs at all.

Yes, and not. I was following the use of $JS_doit to set there the function to run.

If I'd leave that function at the end of the code it would run yes or yes... maybe you are right... following your next explanation.

Anyway, it is to start it... mmmmm.

Quote
siria
For an example look in my previous post above: A variable for the code, then injectJS($_JHcode) - that's ALL that's needed! The alternative via jsdoit etc. may have other advantages, but frankly, too complicated for me as well, struggling hard with the simplest JS.

Ok, so you suggest to just use injectJS (with the code directly input or through a variable) and forget the jsdoit, the hndldocs and so on?

To me is also weird. Do you understand why I don't follow the standard?

For me is crazy.

I'd try Scite later or tomorrow, I'm tired of this coding this afternoon. My head is going to explode if I continue

Not really, the 'standard' as you call it really is much simplified, without all that confusing jsdoit etc. It works exactly like a bookmarklet - all code in one line, and just start it with a click (=1 command, injectJS). And well possible it can handle multiple functions.

You'll better understand the prob with the unclosed " behind $somecode tomorrow when looking at it with the editor. The thing is that $somecode is a variable, not text itself. Variables must NOT open another unclosed " behind, if the variable is the end of code.

For testing complicated scripts I have a tip: You can use e.g. $_JHcode=readfile("d:\\KM\\test.js") and put the whole script file elsewhere, this way it can keep the line-breaks while experimenting and doesn't need browser restarts. Later when the macro is finished you can copy the 1-line-script inside the kmm again.

PS: Just a few days ago JamesD has posted a macro "localdocs". A manual including macro syntax and commands etc., find it very handy to have it in the Help menu



Edited 2 time(s). Last edit at 09/03/2014 11:31PM by siria.

I know just about nothing with regards to JS. I made some changes in your injectbar.kmm file. I now see "aaa" and "bbb" at every OnLoad. I have no idea what the JS is to do. Nothing happens to my display. I hope this helps.

https://dl.dropboxusercontent.com/u/1522294/injectbar.kmm

Ok, that helped me to find the bug. It was in the old macro file where there was a bad $OnLoad declaration, by my side, not carried along time, when I tried to fix an error.

The declaration was wronly made as "$OnLoad = "macroname;";" instead "$OnLoad = $OnLoad."macroname;";".

But the fun is that now that macro was useless...

Who would knew.

Anyway, JamesD, that's the point actually. But forget about $somecode. I shouldn't upload that file.

Try this macro and load this same page being in fullscreen (if not wouldn't fire but I'm going to bed now so I'm not going to fix it, but I'm seeing why wouldn't work as I would like).

injectbarra.kmm (now I set the link to be downloadable)

Now... find where is the magic It's almost invisible.

Yes, the messages did not come from injectJS but from the setting of the somecode value. I woke in the middle of the night and thought, "Why am I seeing both? I have an IF THEN ELSE situation."

What are you trying to have happen when loading a page while under fullscreen mode?

Quote
JamesD
I woke in the middle of the night and thought, "Why am I seeing both? I have an IF THEN ELSE situation."

Great - now you made me wondering the same! Did you find an explanation for it??? And where in the world do the definitions for $jscript and &JSToggle come from??

PS: from little js I understand, not much more as yours, your kmm does nothing else because you commented out the tiny code snippets in the jsdoit, instead append them to the line in injectjs. The code in the bigger js-blocks is just defining a js-function (like we define a macro) and the tiny code snippet is firing it (like we fire a macro). Or such :cool:

Quote
siria
Great - now you made me wondering the same! grinning smiley Did you find an explanation for it???

The two alerts come from the lines where they are set as a value in the variable.

Nothing happens from the injectJS() line. I have got to study the $JS_doit item. I am going to use this code from main.kmm as a guide.

# Parameters for JS_hndlDoc(s) (set those you need before calling the macro):
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
JS_hndlDocs{
# $JS_doit takes the code to be executed in the context of each frame
# $JS_func is the right place for functions and global variables (e.g. when you want to count something over all frames)
# $JS_last is the right place for finishing actions (e.g. when you want to alert what you have counted over all frames)
# $JS_fail is the right place to handle errors that may occur when accessing a frame (Gecko prevents cross-site scripting)
$FlipFlip = false;
getpref( STRING, "capability.policy.default.javascript.enabled")=="noAccess" ? $FlipFlip=true : 0 ;
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
injectJS("(function(){".$JS_func.$_JS_urlencode."function hndlFrm(w){try{with(w.document){".$JS_doit."}}catch(e){".$JS_fail."}for(var j=0,f=w.frames;j<f.length;j++)hndlFrm(f[j])}hndlFrm(window);".$JS_last."})()");
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
}

I think I must put the js code in $JS_func rather than injectJS, and put the trigger in the $JS_doit. I would then call JS_hndlDocs to inject/run the code.

Do you think that I am on the right path?

You are going around in an endless loop. Stop, please

I can't promise of using the newer variables but stop trying to dig of just a name definition difference.

I'm used to the old way. 8 years are 8 years. I'm, also, as Dorian, about 10 years around here.. Actually I'm here since 2003 according the search results... I don't know why but I knew there were more years.

$jscript was the old way was named the current $pref_JavaScript for javascript.enabled preference. As well as &JSToggle is the same as the new &pref_ToggleJavaScript.

Name definitions, just name definitions.

Who cares what name it has? And, what if I created a new variable with another random name? (I usually do the coding in spanish (variable names in spanish) and then post here in english , yeah, scary)

You already understood that that macro section was to check the javascript status


Anyway, I signed up for a geocities.ws web space to show what this javascript code does. Again, don't pay attention to all strange things such as "asdf" text, as are mostly test and tests and more tests.

http://www.geocities.ws/jothache/kmeleonbarracreatelementos.html
Move the mouse to the top of the page. Better if you are in fullscreen.

Important: diable or rename the kmm I uploaded before visit the page because it won't work because of a collision of name/tag/id definitions.





Edited 7 time(s). Last edit at 09/04/2014 02:18PM by JohnHell.

OK, JohnHell.
Now that I can see it, I understand what you are doing. You have the code in that site, but you want to inject that same code to any site at the OnLoad event.

Have we proved or disproved that inject() works at the OnLoad event?

I could see nothing at first and then I remembered that I run CAPS with a Javascript default of 'NoAccess'. Once I had clicked the flag to red and reloaded you site, it worked.

Let me know if there is anything I can help with.

Quote
JamesD
OK, JohnHell.
Now that I can see it, I understand what you are doing. You have the code in that site, but you want to inject that same code to any site at the OnLoad event.

Have we proved or disproved that inject() works at the OnLoad event?

I could see nothing at first and then I remembered that I run CAPS with a Javascript default of 'NoAccess'. Once I had clicked the flag to red and reloaded you site, it worked.

Let me know if there is anything I can help with.

Yep, we proved it works. That bad declaration was blocking whole OnLoad for other macros.

No more help now

I'll try if I can run macro functions within javascript code, what I doubt and nothing else. I remember that in an old macro was possible to assign to a javascript variable some text passed with a another macro variable or text. I can't recall exactly. But functions are other level.

I guess that when you make a ".whatevermacrocode." the parser executes that code, even if it is not its time in the whole javascript code.

I'll test it to confirm.

This is the reason I told to secretman (in the @/&% topic requesting a new GUI) it wouldn't really work. And even I said I wouldn't do, it was an idea surrounding and I'd have to give a little try Also because doing this I could learn the most used commands with AJAX, the createElement, removeElement, appendChild and so on (to forget again, as I'm not a webdev and if you don't practice...).

Quote
JamesD

Quote
siria
Great - now you made me wondering the same! grinning smiley Did you find an explanation for it???

The two alerts come from the lines where they are set as a value in the variable.

Oh... *lightbulb* Thanks, had completely overlooked THAT, and probably wouldn't have realized it myself anytime soon!!

John, one of my two issues with your legacy KM1.1 variables (aside from the stubbornness without reason ) is that they aren't defined anywhere! The current ones are defined in main.kmm. But the old names are nowhere to be found, and that's a mystery to me - why do they still work?? Are they perhaps still included in some binary file? Or do you and James perhaps just carry around some old macros that restore them? Would they also work in brandnew installs or not?
Since I'm writing macros myself and occasionally take a look at the code of others, I just like to know what I'm doing and understand what works and what not and why.

Quote
JohnHell
I'll try if I can run macro functions within javascript code, what I doubt and nothing else. I remember that in an old macro was possible to assign to a javascript variable some text passed with a another macro variable or text. I can't recall exactly. But functions are other level.

Yeah passing text INTO a script is very easy.
And in KM1.6 it's even possible to pass a js-variable back into a macro variable (if one knows how to handle that "return" thing in js).
The trouble is really to call a whole macro from inside a js code. Not something like "alert", which can also be interpreted as js-code, but a fully independant macro with a random name.



Edited 2 time(s). Last edit at 09/04/2014 07:19PM by siria.

Quote
siria

Quote
JamesD

Quote
siria
Great - now you made me wondering the same! grinning smiley Did you find an explanation for it???

The two alerts come from the lines where they are set as a value in the variable.

Oh... *lightbulb* Thanks, had completely overlooked THAT, and probably wouldn't have realized it myself anytime soon!!

John, one of my two issues with your legacy KM1.1 variables (aside from the stubbornness without reason ) is that they aren't defined anywhere! The current ones are defined in main.kmm. But the old names are nowhere to be found, and that's a mystery to me - why do they still work?? Are they perhaps still included in some binary file? Or do you and James perhaps just carry around some old macros that restore them? Would they also work in brandnew installs or not?
Since I'm writing macros myself and occasionally take a look at the code of others, I just like to know what I'm doing and understand what works and what not and why.

That's a good number of questions and point me to talk about something else that I thought to talk, if not here, in the local files help thread by JamesD. But here will keep cleaner his thread.

Do they still work? No, they are macros that, for an unknown reason, where redefined. I don't know now in what version. In 1.1.x or 1.5.x, or maybe earlier. Why it was changed is mistery for me.

Where are they? In a macro file. Not binary at all. Let's say it is as the main.kmm in current releases. I don't think they worked for JamesD. What worked for JamesD was the webpage example I posted above, if I'm not wrong.

NOTE: FROM HERE THERE IS A RANT, YOU ARE WARNED

And now, coming to what I want to talk..., why the macro definitions were changed?, Who decided it?, why decided it?

(The answer is obvious set basics for newcomers, don't get me wrong).

Those questions and answer left me with a full hand of macros that became useless because the reference to the old macro naming was removed.

You'll say, and why you didn't change all macros to the new macro definition? Because it was a lot of work and in that time I wasn't good with macros. I were as you said, looking at others to make my own. And the problem are not only the dependencies from other macro files, but from menus. My context menu is whole made by myself. It is not the same that you are using right now. It has dependencies on macros and also that macros on old macro definitions.

(oh, the buildmenu function... how much headaches gave to me too)

It if was already crazy when I tried to move from 1.1.x to 1.5.x back to 2008 because of all the strict macro parser, double that work to correct every macro.

Anyway, call me lazy if you prefer.

And comming to the core of I want to ask...

JamesD, you said in the local documentation you prepared (macroguidelines.htm)... that there is a naming convention. Really? since when? who decided it? Is it really a convention? If at least macros stop working if they don't have an initial underscore... I could I agree, but I can't.

And it is worst when you say in bold:
The names of all macros and global variables defined in module must have _ as a prefix!

Must? who said that? who decided that? It is not mandatory at all.

Anyway, when all was messed up in newer versions, seeing those underscores where shouldn't that make the code more unintelligible, if possible, I just stopped trying to follow the path and viewing that all you followed it, I just went my way. Yes, you read it correctly. I couldn't adapt at some point.

I just got frustrated. At this point I prefer to do reverse enginering to know where are things comming than trying to follow a nonsense standard/convention that make the life easier for others but not for me when I was used to other way of making things, other macros, other "conventions".

For example, with all respect to chinese, things like the line you appended to my code, are as chinese to me:
$macroModules=$macroModules."injectbar;";

I have to make reverse enginering reading back other macros to find out what it is for and you find that it is... useless!!! Yes, because what is it used for? It is not for example for an important task such as show that macro in the macro extension section of the prefence window... What is $macroModules actually for?

All looking as if it was and actual core of the macros, and it isn't (trying to make difference between global and not global variables and global and not global macros).

This and other things made me give up.

In other words, I make all my macros from scratch, and that is too why I don't share some code here, even if it could be usefull for others, because no one would understand where to place it Because for me is madness all the underscore supposed convention and other things, but, for you, accustomed to it... aren't able to understand my code either. So I only post some snippets here and there to help to refine some code.

END OF RANT But as the topic came I started to.


By the way, readfile(), does it read relative paths? Another thing that is not in the docs.

And maybe that is a good reason for my rant. A lack of some docs.

Sorry for this long rant post


Now you can start to attack my argue that I hope it can be understood as english, without a spellchecker, is... not easy at all

Your english is perfect, no worry

Quote

The names of all macros and global variables defined in module must have _ as a prefix!

No - that is, variables yes, but not all MACROS. Actually I had started writing a post about this last week, because I'm convinced that was a misunderstanding and needs fixing, but then thought oh well who cares and I don't have enough time and energy either to help fix it, so dropped it again. But the misunderstanding is obvious to me because of the very next chapter, which makes a lot more sense, and contradicts the previous chapter concerning macronames.
Personally I find the system really helpful and logical:

- VARIABLES which start with an underscore_ indicate that they are made by optional user macros, are not native. IMO this reduces the risk of future trouble if in some newer KM version a native variable may use the same name! So I happily stick to it, except in rare special cases for some good reason.

- If a global variable is needed across the session, it does also make a lot of sense to start it with a (hopefully) unique prefix made of the macro name. Again to avoid duplicates. You are right that this may get endless long and hard to read, but so I simply use abbreviations: e.g. $_StSc_xxxx for StyleScriptia-variables or $_OnEv_xxx for OnEventCheck-variables. The effect is about the same, and gets much easier to read.

- Macronames-system is similar, except here the first leading underscore_ indicates a helper-submacro, not one that's meant to be used in menus. For me that _ helps keeping overview while coding and making menus or shortcuts. Also helps that all macros start with the macroname as prefix. Okay, in helper-submacros I often use abbreviations too for the prefix to keep them shorter, but again the effect is the same, just abbreviated. For menu-macronames I do keep the long version, again because it helps keeping overview if someone wants to use it in skins or menus.cfg or shortcuts.

Contrary to you I find it instead very confusing if a bunch of macro commands don't have a common prefix, so how do you want to make sure that not some other macro uses the same easy names??
So you may find the 1.5 system messed up, but as expected I find yours much more of a mess ;-)

Your trouble with setmenu I can't quite understand either, find that rather easy really. Quite contrary to the buttonmaker-commands which are a nightmare - are you sure you're not confusing the two?? Of course it also helps greatly to use syntax-highlighting for editing, catches 90% of syntax typos effortlessly....

And I also am glad they improved some default macro names, like &JS_ ... :cool:

Quote

What is $macroModules actually for?

Actually I am needing that too occasionally, to check if another macro that I may have to adjust to is loaded too or not
But instead of working hard with reverse engineering it should suffice to look it up once in the macrolanguage wiki and that was it. If a description needs improvement someone should do it of course (like that $ARG-thing, took me forever and close examining of useragents-macro to figure out THAT one - and then it turned out that thing is quite harmless and kinda easy! All that was needed was an example, as always.)

If readfile() can read relative paths I doubt, but if I'd absolutely need it I'd just do a quick test. What it can do is use getfolder(), rootfolder or macrofolder or some others, so far that was all ever needed in my macros. And sometimes using a variable for other fix paths. So far no prob.

As was clear before, we're not going to find an agreement on this



Edited 2 time(s). Last edit at 09/05/2014 07:42PM by siria.

Just to clear up one point. I did not create the MacroGuidelines. I only re-packaged the content into a htm file for local documents. The original content is in the wiki.
http://kmeleon.sourceforge.net/wiki/MacroGuidelines

I did do the last edit, but that was only to remove some spam.

The wiki page was started by kko in 2006. There were edits by kko and desga2 in 2006, 2007, and 2010. I removed the spam in 2011.

Of course, I'm aware and John sure too, having even been around at the time already. He's merely venting his longstanding frustration at us as supporters and promoters of the 1.5 system Nothing personal.

What Siria said, JamesD.

You just were a collateral damage in the middle, as you made the new local help files, nothing else. A scapegoat.

So sorry