Quote:

Quote:

The non-local use of $ExeDir is intentional and explained.



Globals are a very bad idea, and should be avoided unless absolutely necessary, which in this case they are not.

Yes, I'm familiar with why variables should be localized. With all due respect, I wrote this script for myself, and thought others could benefit from having seen a reasonably well commented and simple way to make changes to all HKU hives - loaded or unloaded. $rc isn't localized because, simply, it didn't occur to me, and $exedir exists for reasons I've explained.
Quote:

Why not pass $exeDir as an optional parameter:
Code:
Function ALLHKU ($ALLHKUKeyname, $ALLHKUEntry, $ALLHKUExpression, $ALLHKUDatatype, $ALLHKUDefault, $ALLHKUDeleteLog,Optional $exeDir)
	If Not $exedir
		$ExeDir=@SCRIPTDIR
	EndIf
...


Yes, that's a fairly reaonable way to do it. I'll consider it.
Quote:


If you really must use a global, then you should still declare it:
Code:
If Not IsDeclared($exeDir)
   Global $exeDir
EndIf


This will allow your code to be used by people (like me) who use SetOption("Explicit","ON") in our scripts.

I think the number of people who work with Explicit ON who look at this script, see the obvious warnings about $Exedir and the way that I log can probably make the coding changes necessary as to not have to deal with my code which was WRITTEN WITH THE EXPRESS PURPOSE OF EXISTING IN A KISCRIPTS EDITOR EXE FILE.

Quote:

Quote:

Similarly, I'm aware that this makes log files


I think you miss the point. You start a log file using RedirectOuput(), but you never stop it. This means that anyone calling your function would have to know that they had to stop the redirection.

A valid point. I'll end logging by redirect at the end of the function.
Quote:


This is truly bad karma. Your function should perform a single task without interfering with the rest of the script. What we call a "black box" function. What if the main script is already redirecting output? You've just broken the main script!


Again, forgive me, but I had no intention of writing a function that met anyone's success criteria except my own. My success criteria were to make a script segment that was reusable (by me!) and provided enough output to make testing easier. I attempted to provide it here as (a) a functional script [which it is], and (b) an example of how to do what I did.
Quote:


Your function should not assume anything about logging, and you should certainly avoid issues with commands like RedirectOutput().

If you must log stuff withing the script, use FreeFileHandle(), Open(), WriteLine() anc Close() to ensure that you do not affect the main calling script.

Perhaps, again, you misunderstand the purpose of MY function. Outside of the error of me not closing my redirect, it functions the way *I* intended it to function. Are there issues with implementing this script into code that you or others may write? Certainly. Is it a nice, tight, sealed black-box of a function with one input and a tidy @error output? No, absolutely not. As I was fairly clear in writing, I have no intention of that script above being that.

Quote:

I'm not sure ... that I intend to chage the imbedding variables in my strings.




Not embedding variables is good practice. If you must embed variables then you can ensure that your function continues to work with people (like me) who use SetOption("NoVarsInStrings","ON") add the following to the top of your script to save the setting:
Code:
Dim $sNoVarsInStrings
$sNoVarsInStrings=SetOption("NoVarsInStrings","OFF")


At the end of your script just before you exit, restore the setting with:
Code:
$rc=SetOption("NoVarsInStrings",$sNoVarsInStrings)


Now, no-one is going to come round and knee-cap you (or even sue you) if you don't make these changes.

We ask for them becuase it will make your function portable, generic and give it a professional finish. It will mean that anyone can cut'n'paste your function into their own script and know that it will work first time with no odd side effects.

I disagree with your characterization that my script isn't professional because I choose to imbed strings. It's simply a matter of style. Perhaps, when calling borrowed functions, you should add similar code to check and toggle all of your non-default set options.

I appreicate and understand your point of view, but I'm a little shocked anyone shares code. I don't consider this function exactly earth-shattering; but it is useful and educational -- should you want to know something about the function of the profile .DAT files and the HKU tree -- if you actually look at the output log.

So, with all due respect, I'm going to continue to write functions when it makes sense to do so. I'll continue to write them to meet the specifications to make MY tasks work. I'll continue to share them; and, within the boundries of what fits my style of programming, I'll continue to make them as portable as possible (like fixing my redirect("") and localizing $rc). You and the other moderators can continue to welcome the submission of those scripts, or, you can give me a lesson in good programming.