Randy Webb wrote:
> Randy Webb said the following on 5/30/2007 12:46 PM:
>> -Lost said the following on 5/30/2007 11:23 AM:
>>> Randy Webb wrote:
>>>>> Are you using some debugger to get this or is it just a superior
>>>>> development of your craft?
>>>>
>>>> It is a superior development of the craft with some sorcery thrown
>>>> in for fun. It can be learned from the group FAQ and the archives
>>>> though. Personally, I don't care for the onclick="launch(160);return
>>>> false", I prefer onclick="return launch(160)" and let the launch
>>>> function return true or false. You can search the archives to find
>>>> out why return functionName is a better alternative.
>>>
>>> Could you perhaps provide a search string to that effect?
>>
>> I could probably come up with one if I searched and looked long
>> enough. It is quicker and easier to explain it though.
>>
>>> I tried "return functionName" just in case, and well, it was not
>>> satisfactory to say the least.
>>>
>>> I am quite happy to know that I already subscribed to this method of
>>> coding though. Why it is necessarily better I do not know.
>>
>> Then why do you use a method that you don't know why it is better?
Firstly, sorry for the *extremely* delayed response. I forgot the name
of the thread and had a bit of a family issue so didn't check the groups
for several days.
Little did I know that so many new replies would appear and make me lose
my place.
I eventually searched for "return functionName."
Anyway, in response, because I developed what I thought was a clear
understanding of better coding practices.
>>> I did it because it just made sense to reduce clutter in your markup
>>> and two, because, why not have the function do it for you?
>>
>> In this code:
>>
>> onclick="someFunction();return false"
>>
>> If someFunction has a coding error in it where it causes an error,
>> then the return false never gets executed and the browser will
>> navigate to the href property of the A element. With this code:
Ah, I never thought (or knew) about that.
>> onclick="return someFunction()"
>>
>> If someFunction has an error in it then it essentially returns false
>> (I believe it actually ends up as return null which type converts to
>> return false) and cancels the navigation.
>>
>> Makes debugging a lot easier when the browser isn't navigating away on
>> you.
Ah, OK. So by not firing the default link *and* your function does
nothing you realize it was the function itself that went afoul.
Never thought about that either.
> I like replying to myself so much I had to do it again:
>
> <a href="thisPageRequiresActiveX.html" onclick="return
> doSomething()">Something useless as usual goes here</a>
>
> function doSomething(){
> if (window.activeX){
> //do something insane with activeX
> return false
> }
> return true
> }
Oooo. Internet Explorer-only functions huh? Tsk tsk tsk.
Also, you did mean window.ActiveXObject right? Otherwise, I am lost.
(Get it, I am lost? Ha!)
Speaking of proper coding practices, which is better?:
function f1()
{
if (window.ActiveXObject)
{
// do ActiveX
return false; // don't follow link
}
return true;
}
function f2()
{
if (window.ActiveXObject)
{
// do ActiveX
return false; // don't follow link
}
else
{
return true;
}
}
I certainly like f1() better.
> I should start taking sleeping pills again.
Would Mr. Webb like some of -Lost's Seroquel? I have 300mg tablets.
Unless you are my size, that will put you to sleep for nigh on 16 hours.
--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.