#126952 - 2004-09-22 09:20 PM
ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
SCRIPT DELETED. Cheers.
Edited by MythosAZ (2004-09-25 02:26 AM)
|
|
Top
|
|
|
|
#126954 - 2004-09-23 12:12 AM
Re: ALLHKU - Writes Registry Values to All Users
|
NTDOC
Administrator
   
Registered: 2000-07-28
Posts: 11628
Loc: CA
|
The 5th line down in the example... treats the whole thing as UDF
Thanks but yes could be cleaned up a little bit more to make it easier to read and use.
|
|
Top
|
|
|
|
#126956 - 2004-09-23 02:57 AM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
It's not so much the 5th line of the quick example, but there happen to be four lines of quick example before the Function 
|
|
Top
|
|
|
|
#126957 - 2004-09-23 03:10 AM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
I edited the location of the actual function start, and included a commented one at the top for reference.
As far as ease of use, it should function and accept syntax mostly the same as WRITEVALUE, as there's no REAL need to pass the two optional values.
After making this version today, I need to include either an option to REMOVE keys, or a seperate function.
The end goal, probably, will be to make a .REG file parser that knows how to add changes to all KHU keys.
|
|
Top
|
|
|
|
#126958 - 2004-09-23 09:35 AM
Re: ALLHKU - Writes Registry Values to All Users
|
Jochen
KiX Supporter
   
Registered: 2000-03-17
Posts: 6380
Loc: Stuttgart, Germany
|
|
|
Top
|
|
|
|
#126959 - 2004-09-23 07:45 PM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
The non-local use of $ExeDir is intentional and explained. Similarly, I'm aware that this makes log files, and I'm not sure, at this point, that I intend to change it or that I intend to chage the imbedding variables in my strings.
I'll localize $RC on my next update.
|
|
Top
|
|
|
|
#126961 - 2004-09-24 09:55 AM
Re: ALLHKU - Writes Registry Values to All Users
|
Richard H.
Administrator
   
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
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.
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 ...
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.
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.
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!
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.
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.
|
|
Top
|
|
|
|
#126962 - 2004-09-24 11:45 AM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
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.
|
|
Top
|
|
|
|
#126963 - 2004-09-24 12:10 PM
Re: ALLHKU - Writes Registry Values to All Users
|
Richard H.
Administrator
   
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Quote:
It's simply a matter of style.
No, it isn't about style. If you follow the suggestions we have made your function will work in all cases for anyone who tries to use it, regardless of their implementation. If you don't then it won't work for many people.
Please view the comments in the spirit that they have been written. We are not getting at you or dissing your coding skills, we are trying to help you write more robust scripts.
If you think we are being odd or cantankerous about some of these points then please ask. The board moderators are not just admin staff, we've accumulated many years of KiXtarting experience there is (usually) a good reason why we pick up on something.
I'm glad that you are not put off contributing and look forward to more from you.
|
|
Top
|
|
|
|
#126967 - 2004-09-24 08:29 PM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
I'm going to have to disagree with at least one point:
As long as VarsInStrings' default is to allow the behavior, I contend that it *IS* a matter of style. I'm well aware of situations where this can cause a function to fail, and I'm well aware of the pros and cons of not doing it.
Also, I'm not sure how to make any clearer that I understand the suggestions that you're making. I'm well aware that I have an additional variable that needs localized and Redirect that needs fixed. I don't take any issue with adding a piece of $exedir logic to this (and future scripts) -- BUT, this script, because of it's purpose, will probably always write log files, and will probably, for my sanity alone, always include vars in strings. Perhaps I'll just start including bastardized headers and footers.
Quote:
Tough croud huh? Give 'em an inch and they want a mile!
Actually, yeah. This is a pretty useful script. In the example above, it's probably easier to adjust the ProxyByUser/ProxyByMachine policy bit, lacking a policy bit, or the ability to move things into HKCM and have them work, writing to all HKUs is quite valuable.
|
|
Top
|
|
|
|
#126968 - 2004-09-24 09:20 PM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
I've posted a few of the changes, but you're going to have to accept that this script writes logs to $exedir if it exists - at leats for a while.
|
|
Top
|
|
|
|
#126970 - 2004-09-25 02:25 AM
Re: ALLHKU - Writes Registry Values to All Users
|
MythosAZ
Fresh Scripter
Registered: 2003-07-31
Posts: 9
Loc: Phoenix
|
Quote:
There is a reaosn why we have created the UDF Guidelines and why we try to have every single UDF adhere to this. For example, by posting addtional text before the UDF itself, you've just messed up the automatci extraction process used to populatethe UDF mirrors.
Also, we are holding UDFs to a much higher standard than code thatis posted in the scripts forum. The reason being that UDFs should be black boxes mirroring the style of internal Kixtart functions. UDFs have to be graceful with regards to the interactions and be clean, e.g. not keep the log file open as it will interfere with other script functionality. UDFs posted here are not meant to be specialized functions that only work under special circumstances but generalized functions that work in all kinds of environments. Thsi is one of the reasosn we the UDF rules are on the restrictive side. If a UDF does not comply with NoVarsInStrings=ON and Explicit=ON, then the UDF will break a lot of scripts.
Hey, here's an idea. Why don't you all take turns explaining something to me that I ALREADY COMPLETELY UNDERSTAND.
I've removed the script. Problems solved. Cheers.
Edited by MythosAZ (2004-09-25 02:29 AM)
|
|
Top
|
|
|
|
Moderator: Arend_, Allen, Jochen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 1188 anonymous users online.
|
|
|