DonationCoder.com Software > Finished Programs
DONE: Generate sequential serial numbers
anandcoral:
Good going. Must be global warming effect :)
Need to change the thread to something 'Generating sequential point counter-point'.
Though I have similar years, company etc., I still find myself learning. I learnt from the code that AHK auto converts to string if string is added to number. Since I use a lot AHK, AutoIt etc. code, this tip will reduce my code.
Regards,
Anand
IainB:
...I learnt from the code that AHK auto converts to string if string is added to number. Since I use a lot AHK, AutoIt etc. code, this tip will reduce my code...
-anandcoral (June 25, 2012, 07:07 AM)
--- End quote ---
Oh, I missed that. That's useful. Thanks for pointing that out. :up:
I am still slowly developing my understanding of AHK-L and that's why I like to read DC-created scripts and discussions about AHK code, though I am not necessarily able to contribute to or fully understand them... :-[
I also subscribe to the discussions in the forum at http://www.autohotkey.com/community/ in my Google Reader, but it's a bit of a mixed bag, and they are too many and too active for me to be able to keep track of and study them all. I'm sure I miss a lot of useful info.
_____________________________________
"Semper in excremento, solo profundo variat"
MilesAhead:
I think the main risk I've seen using variants and implicit conversion is in comparisons. When I was new to AutoIt3 I got some strange results in comparisons because I didn't realize that reading a value from an .ini file produced a string, no matter the value. Ini files often use 0 for False and 1 for True. It was easy when typing in code to make the error demonstrated by the top half of the code below(esp. since in .ini files strings are not quoted. Easy to see it as boolean instead of string.) That's why I came up with _IniBool() function. It seems trivial but with it you can actually use Boolean values in AutoIt variables and True or False will be written to the .ini using IniWrite. If the user changes it to 1 for true and 0 for false, it still functions as expected.
--- ---$val = "1"
If $val Then
MsgBox(0x1040,"test","$val is True" & " " & $val)
Else
MsgBox(0x1040,"test","$val is False" & " " & $val)
EndIf
$val = "0"
If $val Then
MsgBox(0x1040,"test","$val is True" & " " & $val)
Else
MsgBox(0x1040,"test","$val is False" & " " & $val)
EndIf
$val = "1"
If _IniBool($val) Then
MsgBox(0x1040,"test","$val is True" & " " & $val)
Else
MsgBox(0x1040,"test","$val is False" & " " & $val)
EndIf
$val = "0"
If _IniBool($val) Then
MsgBox(0x1040,"test","$val is True" & " " & $val)
Else
MsgBox(0x1040,"test","$val is False" & " " & $val)
EndIf
Func _IniBool($val)
If $val = "True" Or $val = "1" Then Return True
Return False
EndFunc ;==>_IniBool
For the AHK_L code in question this demonstrates that one can stick the result of SubStr() in another dedicated variable. But since there's no comparison it's just the creation of another variable for no real reason. I found out from Lexicos the author of AHK_L when you create a variable, even a local in a function, the storage is there for the life of the program run. He stressed the main danger of doing things like myObject := 0 to clear an object is if you have other references to the same object. In that case you can get side effects/unexpected behavior. For that reason I modified a small utility I wrote to create an object as a local inside a function, then return the result out to the global. Lexicos says that even though the local variables don't "disappear" when the function returns like compiled program stack variables, the storage is reused on the next function call. So basically, if I make sure I only see one reference to an object, I can safely clear its contents with myObject := 0. In which case the variable myObject is now a numeric. But then you can just assign the object returned from the function and its type is restored to Object.
Fun stuff. Here's a link to the discussion where I asked about just setting an object to 0 to clear the contents. The link is pretty much the climax of the topic.
http://www.autohotkey.com/community/viewtopic.php?f=1&t=87634&start=15#p544146
Here's ahk sticking the result of SubStr() in a different variable
--- ---
mySerial := 1
myFactor := 2
myTemp := 0
^g:: ; Ctrl+G, change to whatever you want.
{
;mySerial := SubStr("000000" . mySerial, -5)
myTemp := SubStr("000000" . mySerial, -5)
SendInput, % myTemp
mySerial += myFactor
}
Return
It works. But in this case since I never compare myTemp or mySerial to anything, there's no purpose served.
I also do C#. It's a strongly typed scripting language as opposed to scripting such as AutoIt3 and AHK where they just use Variants for everything. One benefit of the "one size fits all" Variant is that it makes it easy to interface to system scripting stuff that's all IDispatch based.
In any case, I never held a job with "developer" or "programmer" as the job title. But I've been programming in various languages steadily since I first got hooked in 1986. I guess it just seemed pointless to me and a bit insulting to be offered tips on correct programming practice by someone who doesn't even understand the language in question. It would be like me lecturing someone by saying "I don't know a damn thing about Lisp but if I was doing it in Pascal I sure wouldn't do what you're doing there buddy!" heh heh
Generally I find it better to ask for working code than argue. If someone can demonstrate what they claim, and I can run i and see their point, the argument is over pretty quickly. Otherwise it tends to degenerate into who claims to have the highest IQ. :)
IainB:
@MilesAhead: Thanks for the explanation, especially (my emphasis):
...
...For the AHK_L code in question this demonstrates that one can stick the result of SubStr() in another dedicated variable. But since there's no comparison it's just the creation of another variable for no real reason. I found out from Lexicos the author of AHK_L when you create a variable, even a local in a function, the storage is there for the life of the program run. He stressed the main danger of doing things like myObject := 0 to clear an object is if you have other references to the same object. In that case you can get side effects/unexpected behavior. For that reason I modified a small utility I wrote to create an object as a local inside a function, then return the result out to the global. Lexicos says that even though the local variables don't "disappear" when the function returns like compiled program stack variables, the storage is reused on the next function call. So basically, if I make sure I only see one reference to an object, I can safely clear its contents with myObject := 0. In which case the variable myObject is now a numeric. But then you can just assign the object returned from the function and its type is restored to Object....
...
--- End quote ---
That seems to me to be quite a tidy way of ensuring that you avoid the risk of odd results "if you have other references to the same object" now, or at some stage in the future. Belts and braces.
I have incorporated the modified script you give above (plus some notes) into the "experimental" part of my main AHK script file, for when I might need it. I too find it easier to run a piece of worked demo code to understand/analyse what it is doing and why.
By the way, I found the link you provided to the discussion thread with Lexikos quite informative, so thanks again.
I am left still curious as to what @pagebooks was intending using the incremental numbering for. I mean, he's presumably wanting to generate numbered lines - but why? I would have thought that was likely to be an already-automated feature in most applications. :huh:
cranioscopical:
FWIW, I think there's been a genuine misunderstanding here. My impression is of two people intending to be helpful. I can learn a little something from either side of the discussion, so thank you both.
I don't think it's a matter of IQ. If another is better at something than I, that doesn't necessarily result from a higher IQ than mine (though in my own case it almost certainly does mean that — the "For Dummies" series was clearly written for those like me). It probably means that the other has more or different experience.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version