Page 3 of 3 <123
Topic Options
#158119 - 2006-03-06 05:07 PM Re: ChangeVLKey() - Test Function
Arend_ Moderator Offline
MM club member
*****

Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
My whole idea is that it returns 0 when succesfull and an @error code when it isn'succesfull and exits with an @error is it fails somewhere before the function finishes.
Top
#158120 - 2006-03-06 10:09 PM Re: ChangeVLKey() - Test Function
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Quote:

However, when the function is not expected to return data then it makes sense use the error status as the return value.




Well then I would assume in most cases that it would be 0

If that's the case then why do we really need to set it to anything? If it's not expected to return data then as long as one checks for @ERROR and does not find an error then it should have worked, otherwise regardless of what caused the error it would be captured in the EXIT @ERROR code.

Also in your example by using the NOT operator forces one to use KiXtart 4.50 or newer (which is okay )

But as I view it if no data is expected why would you check for data? That's like expecting to really see the Tooth Fairy when you know it's not there.

Code:
Function ChangeVLKey($VOL_PROD_KEY)
Dim $obj, $objects, $result
;Key is without hyphens (ABCDEFGHIJKLMNOPQRSTUVWXY)
$objects = GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("win32_WindowsProductActivation")
If Not @ERROR
For Each $obj in $objects
$result = $obj.SetProductKey($VOL_PROD_KEY)
Next
EndIf
Exit Val('&' + Right(DecToHex(@ERROR), 4))
EndFunction



Here we simply exit with the ERROR if anything caused one during that processing which we didn't expect data.

I assume from your point of view that well we would see the error and know that something went wrong, but I'm thinking the opposite in that for a function that does not return data, I won't go looking, I'll only look for an ERROR

Regardless of outcome here I think it has been a good discussion on the subject.

Top
#158121 - 2006-03-06 10:29 PM Re: ChangeVLKey() - Test Function
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
I think the point is that returning the errorlevel is most "kix-like". For example - WriteValue from the manual is:

Code:

$RC=WriteValue("EZReg\Test", "A MultiString variable", "Line 1|Line 2|Line 3 with a || in it|" "REG_MULTI_SZ")
If @ERROR = 0
? "Value written to the registry"
Endif



WriteValue returns the errorlevel and sets the errorlevel. This keeps two types of coders happy - those that like to check @ERROR (you i think) and those that like to check the return value (me for example).

The only pain-in-the-ass thing is when you forget to capture the return value - but we all deal with that day-in day-out. In fact, when I get rc's dumped to the console its a good reminder (to me anyways) about something that should be checked and handled if issues.

Top
#158122 - 2006-03-06 11:05 PM Re: ChangeVLKey() - Test Function
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Well after a bit more discussion with Glenn on this subject via MSN (Shawn is never on anymore to group chat on this)

I think it boils down a bit more to what is easier to support / use / test and not so much as always mimicking the KiXtart functions which are not 100% consistent either.

As an example in the manual by Ruud

If Exist()

That just doesn't work with 0 for success so he used positive logic for testing.

Returns:
0 File not found
1 File found



So basically in a nutshell (regardless of how KiX internally handles it)

If you can with reasonable certainty know what error you want returned when the function did not do as you wanted then one would force set the value and not use @ERROR
This is on a case by case basis
When the error is fully unexpected then using the @ERROR makes sense.
Setting a positive logic to a RETURN (when data is not excpected) makes more sense than 0 or @ERROR (imho)
ie.. I would set it to 1 to mean it was successful
and set the exit to 0

If I felt the @ERROR might give better feedback than I would use that. Sometimes though setting a specific error gives a better indication of what the problem is.

I apologize for not seemingly being able to clearly define this subject, but I think I have better grasp of how I want to mabye write future UDFs.

Top
#158123 - 2006-03-07 09:06 AM Re: ChangeVLKey() - Test Function
Arend_ Moderator Offline
MM club member
*****

Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
I think this should cover it all
I removed the Error parsing NTDOC suggested earlier because I want to keep the function as simple as can be. It returns an error code, ppl who use this function should be able to recover the error themselves.

Code:

Function ChangeVLKey($VOL_PROD_KEY)
Dim $obj, $objects, $x
;Key is without hyphens (ABCDEFGHIJKLMNOPQRSTUVWXY)
$objects = GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("win32_WindowsProductActivation")
If @Error <> 0
Exit @Error
EndIf
For Each $obj in $objects
$x = $obj.SetProductKey($VOL_PROD_KEY)
$ChangeVLKey = @error
Next
EndFunction


Top
#158124 - 2006-03-07 09:10 AM Re: ChangeVLKey() - Test Function
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
That's okay, but you're missing an EXIT code when it's finished. All UDF code should have an Exit code and not just Exit either. This has been discussed in the past and shown that on some occassions it can lead to other problems if an Exit with value is not supplied.
Top
#158125 - 2006-03-07 09:57 AM Re: ChangeVLKey() - Test Function
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Quote:

If Exist()

That just doesn't work with 0 for success so he used positive logic for testing.

Returns:
0 File not found
1 File found





That is a very bad example to choose

You've assumed that because the function is returning a 1 or a 0 that this is the same as returning an error state.

But is not is it? The 1 or 0 returned by Exist() is data and has nothing to do with the error condition.

This still fits into the simple rule set:
  1. If a function is designed to return data it should return FALSE, 0 or null on an error where that will not prejudice the purpose of the function.
  2. If a function has no explicit return value then it should return an error status where "0" is success.

Now the example you have chosen (Exist) is designed to explicitly return a value, so it matches rule 1. If an error occurs then 0 will be returned, which fits it's purpose and the way it is used in scripts.

AScan is a good example of a function which fits rule 1 but cannot return 0 on an error which is a bit of a design error IMO.

Top
#158126 - 2006-03-07 10:04 AM Re: ChangeVLKey() - Test Function
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
No I did not assume or think it was ERROR it is data and I chose it on purpose to illustrate my point that I think you're still missing the overall larger picture here.

Coding, using a UDF with a positive logic regardless of how KiXtart internals may handle them.

A return and an Error are different and I don't believe I showed otherwise, but then again I seem to have trouble presenting my point here.

I suppose what I'm trying to say is that a UDF does not and can not have a SOLID one rule fits all, but rather can and will change depending on what the UDF code consists of.

I think I agree with your RULE 1 but I don't fully agree with your RULE 2


Edited by NTDOC (2006-03-07 10:06 AM)

Top
#158127 - 2006-03-07 10:35 AM Re: ChangeVLKey() - Test Function
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
I think I understand what you are saying. If I have it right then:
  1. If a function is designed to return data it should return FALSE, 0 or null on an error where that will not prejudice the purpose of the function.
  2. If a function has no explicit return value then it should also return 0 on error and non-zero on success so that it is consistent with rule 1.


I see the argument but it would be pretty counter-intuitive as it is the reverse of every other scripting or programming language I've ever used. I guess that's why it took me a while to see what you were getting at.

Top
#158128 - 2006-03-07 12:16 PM Re: ChangeVLKey() - Test Function
Arend_ Moderator Offline
MM club member
*****

Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
Quote:

That's okay, but you're missing an EXIT code when it's finished. All UDF code should have an Exit code and not just Exit either. This has been discussed in the past and shown that on some occassions it can lead to other problems if an Exit with value is not supplied.




I don't think that is the case in this scenario, it returns an error code at the end of the function. Thus the function is ended. I do not believe the function can "hang" in any case scenario however I'd like to hear it if you believe otherwise.

Top
#158129 - 2006-03-07 06:49 PM Re: ChangeVLKey() - Test Function
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Well I'm not saying it would/could/or might hang or error out, just saying that setting the Function to the error is not the same as exiting the function.

A bit of this is theoritical and personal preference. You may run this function a thousand times and have no issues, but you might and having a set exit code (imho) would be a bit better.

Top
#158130 - 2006-03-08 10:55 AM Re: ChangeVLKey() - Test Function
Arend_ Moderator Offline
MM club member
*****

Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
Ok sounds fair enough, could you give you last suggestion as to how the function should look like in your opinion then ? without converting error codes.
Top
#158131 - 2006-03-08 08:06 PM Re: ChangeVLKey() - Test Function
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Code:
  For Each $obj in $objects
$x = $obj.SetProductKey($VOL_PROD_KEY)
$ChangeVLKey = @error
Next
Exit 0



As I said though I'm sure the script as you have would probably run good on 99.9% of every run.

Personal opinion is that having the Exit 0 or @ERROR is just a bit better is all.

Top
#158132 - 2006-03-09 08:44 AM Re: ChangeVLKey() - Test Function
Arend_ Moderator Offline
MM club member
*****

Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
I agree with that, I've changed the first post and the UDF post to reflect your suggestion. Thanks
Top
Page 3 of 3 <123


Moderator:  Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
2 registered (morganw, mole) and 414 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.065 seconds in which 0.023 seconds were spent on a total of 12 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org