Hi, I have this in an external JS library:
/////////////////////////
function addMyEvent(){
var obj;
if(document.attachEvent) {
obj = document.getElementsByTagName('img');
for (i=0;i<obj.length;i++) {
obj[i].attachEvent('ondrag', noDrag);
}
obj = document.getElementsByTagName('a');
for (i=0;i<obj.length;i++) {
obj[i].attachEvent('ondrag', noDrag);
}
}
}
function noDrag() {
// kill the drag event
return false;
}
////////////////////////
If I call it from the associated web page (no frames/IFrames, etc.
involved) via:
<body onload="addMyEvent();">
It works. If I try the unobtrusive metho and use <bodyon the page
and...
window.onload = addMyEvent();
... in the JS library it fails. Have I got the syntax wrong or can only
the calling page use the 'onload' event.
[FWIW, I have to stop drags of images as their SRCs are query URLs and
dragged images get wrong names 'aspscript.jpg'. I provide a download
link for correct naming]
TIA,
Mark
20  11662 
Mark Anderson said the following on 6/4/2007 5:05 PM:
<snip>
window.onload = addMyEvent();
That executes the addMyEvent function as soon as it encounters it and
assigns the return value (if any) to the window.onload event handler. To
"fix" it, remove the ():
window.onload = addMyEvent;
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
----- Original Message -----
From: "Randy Webb" <Hi************@aol.com>
Newsgroups: comp.lang.javascript
Sent: Monday, June 04, 2007 10:24 PM
Subject: Re: window.onload fails from external JS file
Mark Anderson said the following on 6/4/2007 5:05 PM:
<snip>
>window.onload = addMyEvent();
That executes the addMyEvent function as soon as it encounters it and
assigns the return value (if any) to the window.onload event handler.
To "fix" it, remove the ():
window.onload = addMyEvent;
Actually, I'd tried this syntax (no bracket) too and no joy. There are
no other libraries, but the existing library has this as well:
///////
// trap Safari /Firefox behaviour
killDrag={
init:function(){
if(!document.getElementById || !document.createTextNode){return;}
// we'll only trap <aand <imginside ID 'imageLoc'
killDrag.n=document.getElementById('imageLoc');
if(!killDrag.n){return;}
killDrag.addMyListeners('mousedown',killDrag.suppr essDrag,'img');
killDrag.addMyListeners('mousedown',killDrag.suppr essDrag,'a');
},
addMyListeners:function(eventName,functionName,ele ments){
var temp=killDrag.n.getElementsByTagName(elements);
for(var i=0;i<temp.length;i++){
temp[i].addEventListener(eventName,functionName,false);
}
},
suppressDrag:function(e){
e.stopPropagation();
e.preventDefault();
}
};
window.addEventListener('load',killDrag.init,false );
////////////////
As IE doesn't support these events, I assumed they don't matter but
perhaps they throw an error in IE? However, if so, why does a call from
<bodywork with the same functions in the library? I'm stumped.
Mark
On Jun 4, 11:05 pm, "Mark Anderson" <m...@notmeyeardley.demon.co.uk>
wrote:
Hi, I have this in an external JS library:
for (i=0;i<obj.length;i++) {
Is there a reason you want it to
create a GLOBAL variable called i ?
"dd" <dd****@gmail.comwrote in message
news:11**********************@w5g2000hsg.googlegro ups.com...
On Jun 4, 11:05 pm, "Mark Anderson" <m...@notmeyeardley.demon.co.uk>
wrote:
>Hi, I have this in an external JS library:
for (i=0;i<obj.length;i++) {
Is there a reason you want it to
create a GLOBAL variable called i ?
Global? The var 'i' isn't explicitly declared but it is inside a
function - how then is it global? Surely its scope is that of the
containing function:
function addMyEvent(){
var obj;
if(document.attachEvent) {
obj = document.getElementsByTagName('img');
for (i=0;i<obj.length;i++) {
obj[i].attachEvent('ondrag', noDrag);
}
obj = document.getElementsByTagName('a');
for (i=0;i<obj.length;i++) {
obj[i].attachEvent('ondrag', noDrag);
}
}
}
What would be more helpful at this point would be any pointers on why my
window.onload call in an external JS file fails.
Regards
Mark
Mark Anderson said the following on 6/5/2007 4:04 PM:
"dd" <dd****@gmail.comwrote in message
news:11**********************@w5g2000hsg.googlegro ups.com...
>On Jun 4, 11:05 pm, "Mark Anderson" <m...@notmeyeardley.demon.co.uk>
wrote:
>>Hi, I have this in an external JS library:
for (i=0;i<obj.length;i++) {
Is there a reason you want it to
create a GLOBAL variable called i ?
Global?
Yes, it is Global.
The var 'i' isn't explicitly declared but it is inside a
function - how then is it global?
Because without the var keyword, it is created as a Global variable.
Surely its scope is that of the containing function:
No, it isn't. And easy enough to test:
function testIt(){
for (i=0;i<1000;i++){}
}
testIt()
window.onload=checkI
function checkI(){
alert(i)
}
What will the alert show? If i isn't Global then it will alert
undefined. If it is Global, then it will alert 1000. Test it :)
What would be more helpful at this point would be any pointers on why my
window.onload call in an external JS file fails.
Start removing other parts of the code until it works. Then start adding
them back until it breaks. That is how you find errors/problems and most
people refer to it as "debugging".
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote:
Start removing other parts of the code until it works. Then start adding
them back until it breaks. That is how you find errors/problems and most
people refer to it as "debugging".
Oh, no! Not "de bug ging." Dem come 'round and steal me good tots, me
code suffer large mon.
I hate it when "de bug ging" visit me 'ere. De bugging me!
*runs away screaming from de bugs*
De bugs scare de' caca clean out ah me!
Ya, mon.
--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.
"Mark Anderson" <ma**@notmeyeardley.demon.co.ukwrote in message
news:f4*******************@news.demon.co.uk...
----- Original Message -----
From: "Randy Webb" <Hi************@aol.com>
Newsgroups: comp.lang.javascript
Sent: Monday, June 04, 2007 10:24 PM
Subject: Re: window.onload fails from external JS file
>Mark Anderson said the following on 6/4/2007 5:05 PM:
<snip>
>>window.onload = addMyEvent();
That executes the addMyEvent function as soon as it encounters it and
assigns the return value (if any) to the window.onload event handler.
To "fix" it, remove the ():
window.onload = addMyEvent;
Actually, I'd tried this syntax (no bracket) too and no joy. There
are no other libraries, but the existing library has this as well:
///////
// trap Safari /Firefox behaviour
killDrag={
init:function(){
if(!document.getElementById || !document.createTextNode){return;}
// we'll only trap <aand <imginside ID 'imageLoc'
killDrag.n=document.getElementById('imageLoc');
if(!killDrag.n){return;}
killDrag.addMyListeners('mousedown',killDrag.suppr essDrag,'img');
killDrag.addMyListeners('mousedown',killDrag.suppr essDrag,'a');
},
addMyListeners:function(eventName,functionName,ele ments){
var temp=killDrag.n.getElementsByTagName(elements);
for(var i=0;i<temp.length;i++){
temp[i].addEventListener(eventName,functionName,false);
}
},
suppressDrag:function(e){
e.stopPropagation();
e.preventDefault();
}
};
window.addEventListener('load',killDrag.init,false );
////////////////
As IE doesn't support these events, I assumed they don't matter but
perhaps they throw an error in IE? However, if so, why does a call
from <bodywork with the same functions in the library? I'm stumped.
Mark
Figured it out. IE was choking on this line
window.addEventListener('load',killDrag.init,false );
Changing it to
if (window.addEventListener) {
window.addEventListener('load',killDrag.init,false );
}
.....and using window.onload = addMyEvent; without the () and it works.
Thought I'd post it in case it helps anyne else.
Regards
Mark
Mark Anderson wrote:
Figured it out. IE was choking on this line
window.addEventListener('load',killDrag.init,false );
Changing it to
if (window.addEventListener) {
window.addEventListener('load',killDrag.init,false );
}
....and using window.onload = addMyEvent; without the () and it works.
Thought I'd post it in case it helps anyne else.
You erroneously assume that everyone else does not initiate proper
feature detection routines and/or fails to realize that Internet
Explorer does not adhere to the Gecko DOM, or JavaScript standards.
It is wise to always check for specific features you require. In that
fashion you eliminate having to go through what you did.
--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.
On Jun 7, 2:36 am, -Lost <maventheextrawo...@techie.comwrote:
Thought I'd post it in case it helps anyne else.
You erroneously assume that everyone else does not initiate proper
feature detection routines and/or fails to realize that Internet
Explorer does not adhere to the Gecko DOM, or JavaScript standards.
I think the JavaScript error saying that IE doesn't understand
addeventlistener would have been the biggest hint in this story. Of
course you can turn off those nasty (helpful) error messages.
"dd" <dd****@gmail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...
On Jun 7, 2:36 am, -Lost <maventheextrawo...@techie.comwrote:
Thought I'd post it in case it helps anyne else.
You erroneously assume that everyone else does not initiate proper
feature detection routines and/or fails to realize that Internet
Explorer does not adhere to the Gecko DOM, or JavaScript standards.
I think the JavaScript error saying that IE doesn't understand
addeventlistener would have been the biggest hint in this story. Of
course you can turn off those nasty (helpful) error messages.
dd - IE doesn't, as you imply, tell the user where the error lies - "...
the JavaScript error saying that IE doesn't understand addeventlistener
....". It simply gives a non-specific (for the inexpert user) message and
a line number that could be any of the current page or it's libraries,
etc. In this particular case the line number, perhaps due to the code
flow, didn't immediately indicate the exact cause - just there was an
error. Were it was as obvious as you imply, then I wouldn't have needed
to ask!
Thus the observation doesn't help the less experienced JS user reading
this in the archive as it implies they should expect a message from IE
that they just won't see.
I'm not suggesting you meant to be unhelpful with the above advice -
it's just not helpful as written because it assumes knowledge the reader
clearly won't have (or they'd not have the problem).
Nonetheless thanks to you all n/g members for their help. Certainly,
using the 'myfunction;' syntax instead of the normal 'myfunction();' is
an unintuitive step I'd not have guessed.
Regards
Mark
"Randy Webb" <Hi************@aol.comwrote in message
news:dM********************@giganews.com...
Mark Anderson said the following on 6/4/2007 5:05 PM:
<snip>
>window.onload = addMyEvent();
That executes the addMyEvent function as soon as it encounters it and
assigns the return value (if any) to the window.onload event handler.
To "fix" it, remove the ():
window.onload = addMyEvent;
I see now the latter works, but what changes for the sake of a pair of
empty brackets? I think ...
<body onload="myFunct();"works with the result of myFunct() as it
isn't called until the event fires. Conversely, when using window.onload
= myFunct; in a JS library is telling the browser *ahead* of the
'onload' event, what code to run - in our case a function called
'myFunct' - *when* the event fires. Getting the result of myFunct is
likely meaningless or unusable before the event is triggered.
Ah, I think the O'Reilly JSS Definitive Guide alludes to the use or not
of () on page 393 whilst unhelpfully not explicitly noting the effect
of the inclusion or not (). This isn't intuitive to learn as all basic
JS references tell you the function construct is functName() - i.e. the
brackets are always needed.
But, as a good case in point about references, the same book's 25 page
chapter on Function doesn't cover this (it does tell you want the
brackets do, not what happens without), referring only to a similarly
uninformative mention of the Function operator '()' on Ch 5, page 81.
The above issue isn't pertinent to the Ch 5 reference and the Ch 8
*assumes* the issue is covered already (in Ch 5 - it isn't) and the
error then recurses right through a generally excellent reference (I'm
sure I could find the same error - or worse - in most other JS books).
What JS references/books ought to add when describing functions is that
if a function is placed on the right side of an = without the () then
the left side (attempts to) become the right-side function. This,
simplistically,
var myNum = 2;
function myFirst(data) {
return data;
}
function mySecond(data) {
data = data * 2;
return data;
}
alert(myFirst(myNum)); // 2
myFirst = mySecond;
alert(myFirst(myNum)); // 4
myFirst = mySecond();
alert(myFirst(myNum)); // Code errors as last line isn't valid code
The explanation helps both ways; ff you forget the () when you should
use them, then you are assigning the function (i.e. you get no immediate
result, with them you are assigning the result. I'm sure an expert could
explain this more elegantly, but without placing something like this in
any explanation of how to use functions, it's a stretch to assume a
learner will know how to assign a function to something later in their
JS use. IMO, anyway!
A muddying factor in my original problem is the need for window.onload
to attach events is more due to IE failing - i.e. it can't use the DOM
..addEventListener() function. Still, sadly IE is everywhere so the more
ugly attachment method is needed, even by less experienced JS users.
Perhaps an explanation (better than mine!) of this () issue might be a
<FAQENTRY>? In the meantime, I'm sure I'll be returning to this post as
reference ere long, when I've forgotten and got it wrong again.
Thanks
Mark
On Jun 8, 2:14 pm, "Mark Anderson"
Perhaps an explanation (better than mine!) of this () issue
The simplest explanation is that the <body onload="funcname()"is
HTML and the function is a string. It's specifying the javascript
string to be executed onload. It could be something like <body
onload="myloadedflag=true;">
The other code, is pure Javascript. It's inside a script block. In
that case, you're giving the onload a pointer to a function:
window.onload=myfunction;
You could also use an anonymous function:
window.onload=function(){alert('loaded');}
These are the effectively the same.
By adding the () at the end, you're telling it to call that function
now. The only way that could work is if the function you're calling
returns another function ptr.
Mark Anderson said the following on 6/8/2007 8:14 AM:
"Randy Webb" <Hi************@aol.comwrote in message
news:dM********************@giganews.com...
>Mark Anderson said the following on 6/4/2007 5:05 PM:
<snip>
>>window.onload = addMyEvent();
That executes the addMyEvent function as soon as it encounters it and
assigns the return value (if any) to the window.onload event handler.
To "fix" it, remove the ():
window.onload = addMyEvent;
I see now the latter works, but what changes for the sake of a pair of
empty brackets? I think ...
What changes is *when* the function gets executed. If this gives you a
headache, try figuring out what effect (), and the lack of them, has on
a setTimeout call.
<body onload="myFunct();"works with the result of myFunct() as it
isn't called until the event fires. Conversely, when using window.onload
= myFunct; in a JS library is telling the browser *ahead* of the
'onload' event, what code to run - in our case a function called
'myFunct' - *when* the event fires. Getting the result of myFunct is
likely meaningless or unusable before the event is triggered.
They both know ahead of time what to execute. <body onload tells the
browser as soon as it encounters it what it is going to execute. Neither
of them execute until the page finishes loading. Want another headache?
<body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
Without testing, which alert will you see, and why?
<snip>
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
"Randy Webb" <Hi************@aol.comwrote in message
news:tv********************@telcove.net...
Mark Anderson said the following on 6/8/2007 8:14 AM:
>"Randy Webb" <Hi************@aol.comwrote in message
[snip]
They both know ahead of time what to execute. <body onload tells the
browser as soon as it encounters it what it is going to execute.
Neither of them execute until the page finishes loading. Want another
headache? <body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
Without testing, which alert will you see, and why?
A message "Window onload", as the script loads after the HTML is parsed.
I'd assume that if the script were moved the page's <headsection then
you'd see "Body onload" as the <bodyonload attribute is read/processed
after the inline script. With an external library script, I assume the
same applies unless the library is slow to load and is processed after
the <bodytag is read - or is execution of the latter delayed until all
external libraries called from the <headhave loaded? Indeed where
would the learner look to find the 'rule' on the latter?
Regards
Mark
"dd" <dd****@gmail.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
On Jun 8, 2:14 pm, "Mark Anderson"
>Perhaps an explanation (better than mine!) of this () issue
The simplest explanation is that the <body onload="funcname()"is
HTML and the function is a string. It's specifying the javascript
string to be executed onload. It could be something like <body
onload="myloadedflag=true;">
The other code, is pure Javascript. It's inside a script block. In
that case, you're giving the onload a pointer to a function:
window.onload=myfunction;
You could also use an anonymous function:
window.onload=function(){alert('loaded');}
These are the effectively the same.
By adding the () at the end, you're telling it to call that function
now. The only way that could work is if the function you're calling
returns another function ptr.
Thanks. I see now problem here is that the learner in this scenario will
assume a lack of result is due to an error in the function they're
calling rather than the way the function's called. I think I've learned
this issue now so I won't forget. I am surprised though that the
books/references I was consulting back before I asked here didn't cover
this issue, from a learners perspective. I guess it's the classic trap
of being so obvious to the expert author as to not warrant explicit
explanation.
If nothing else hopefully this thread in the n/g archive will help
others save the time I lost pondering over this last week.
Thanks again for the help!
Mark
Mark Anderson said the following on 6/10/2007 9:29 AM:
"Randy Webb" <Hi************@aol.comwrote in message
news:tv********************@telcove.net...
>Mark Anderson said the following on 6/8/2007 8:14 AM:
>>"Randy Webb" <Hi************@aol.comwrote in message
[snip]
They both know ahead of time what to execute. <body onload tells the
browser as soon as it encounters it what it is going to execute.
Neither of them execute until the page finishes loading. Want another
headache? <body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
Without testing, which alert will you see, and why?
A message "Window onload", as the script loads after the HTML is parsed.
I'd assume that if the script were moved the page's <headsection then
you'd see "Body onload" as the <bodyonload attribute is read/processed
after the inline script. With an external library script, I assume the
same applies unless the library is slow to load and is processed after
the <bodytag is read
No matter where you put the window.onload, it will take precedence -
overwrite - the <body onloadcode. Test it :) Whether it is in the head
section, body section, external file, the window.onload will fire and
stop the body onload from firing.
- or is execution of the latter delayed until all external libraries
called from the <headhave loaded?
Neither window.onload nor body onload will fire until the page has
completely loaded including any, and all, external files. Whether they
are images, css file, js files, any external file (even an iframe file).
Indeed where would the learner look to find the 'rule' on the latter?
It is probably in a spec somewhere, I honestly don't know. I learned it
by testing and testing.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
On Jun 10, 6:04 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Neither window.onload nor body onload will fire until the page has
completely loaded including any, and all, external files. Whether they
are images, css file, js files, any external file (even an iframe file).
FYI Randy, there's been some work done on finding a better
onload than the standard one which as you know waits for all
page assets to load. This new method will "fire" when there's
only images left to load (i.e. the DOM is structurally
complete and scriptable): http://dean.edwards.name/weblog/2006/06/again http://www.thefutureoftheweb.com/blog/adddomloadevent
"Randy Webb" <Hi************@aol.comwrote in message
news:8N********************@telcove.net...
>>[snip]
Want another headache?
<body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
Without testing, which alert will you see, and why?
A message "Window onload", as the script loads after the HTML is
parsed. I'd assume that if the script were moved the page's <head>
section then you'd see "Body onload" as the <bodyonload attribute
is read/processed after the inline script. With an external library
script, I assume the same applies unless the library is slow to load
and is processed after the <bodytag is read
No matter where you put the window.onload, it will take precedence -
overwrite - the <body onloadcode. Test it :) Whether it is in the
head section, body section, external file, the window.onload will fire
and stop the body onload from firing.
So, window.onload is always taking precedence? I can't replicate that.
Following used IE v6 patched to date on XP(SP2) patched to date.
Test #1:
<html>
<head>
</head>
<body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
</body>
</html>
....result message "Window onload".
Test #2:
<html>
<head>
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
</head>
<body onload="alert('Body onload')">
</body>
</html>
....result message "Body onload" [sic]. Here, window.onload isn't taking
precedence.
From your earlier post I have assumed both code version should result in
"Window onload". FWIW, if I substitute an external library for the
inline script the results are still the same.
Regards
Mark
On Jun 11, 7:47 pm, "Mark Anderson" <m...@notmeyeardley.demon.co.uk>
wrote:
"Randy Webb" <HikksNotAtH...@aol.comwrote in message
news:8N********************@telcove.net...
>[snip]
Want another headache?
<body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
>Without testing, which alert will you see, and why?
A message "Window onload", as the script loads after the HTML is
parsed. I'd assume that if the script were moved the page's <head>
section then you'd see "Body onload" as the <bodyonload attribute
is read/processed after the inline script. With an external library
script, I assume the same applies unless the library is slow to load
and is processed after the <bodytag is read
No matter where you put the window.onload, it will take precedence -
overwrite - the <body onloadcode. Test it :) Whether it is in the
head section, body section, external file, the window.onload will fire
and stop the body onload from firing.
So, window.onload is always taking precedence? I can't replicate that.
Following used IE v6 patched to date on XP(SP2) patched to date.
Test #1:
<html>
<head>
</head>
<body onload="alert('Body onload')">
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
</body>
</html>
...result message "Window onload".
Test #2:
<html>
<head>
<script type="text/javascript">
window.onload=function(){alert('Window onload')}
</script>
</head>
<body onload="alert('Body onload')">
</body>
</html>
...result message "Body onload" [sic]. Here, window.onload isn't taking
precedence.
From your earlier post I have assumed both code version should result in
"Window onload". FWIW, if I substitute an external library for the
inline script the results are still the same.
body onload="something();"
is equal to:
window.onload = function(){ something(); }
so as far as my humble mind goes it has to be a race condition here,
like:
/* 1 */ window.onload = foo();
/* 2 */ window.onload = bar();
/* 3 */ window.onload = function(){ something(); };
The winner above is the last anonymous function of course, but if all
three functions are coming at different time from different
locations: maybe some UAs are going nuts of it?
dd said the following on 6/11/2007 7:20 AM:
On Jun 10, 6:04 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
>Neither window.onload nor body onload will fire until the page has
completely loaded including any, and all, external files. Whether they
are images, css file, js files, any external file (even an iframe file).
FYI Randy, there's been some work done on finding a better
onload than the standard one which as you know waits for all
page assets to load.
There isn't a better alternative to what is there now - window.onload.
If your page is so externally heavy that it causes a delay in the onload
event firing then you don't need a new method, you need to trim your
page down.
This new method will "fire" when there's only images left to load
No, it fires sooner than that. It doesn't check to see if everything but
images are left, it fires as soon as you call it. In IE, it will fire as
soon as the script tag is processed, irrelevant of whether there are any
external files left to be downloaded.
(i.e. the DOM is structurally complete and scriptable):
From what I read and saw of the code, it does not ensure that is the
case in IE.
The example it gives somewhere in there about the kitty cats is a prime
example. The problem isn't the DOM not being ready, it is an overkill
with images and rather than making the page lighter - and loading faster
- people are hunting a crutch around it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ This discussion thread is closed Replies have been disabled for this discussion. Similar topics
6 posts
views
Thread by Brian |
last post: by
|
8 posts
views
Thread by Mark |
last post: by
|
10 posts
views
Thread by Pasquale |
last post: by
|
3 posts
views
Thread by Liming |
last post: by
|
3 posts
views
Thread by Frances |
last post: by
|
7 posts
views
Thread by Andrew Poulos |
last post: by
| | | | | | | | | | | | | | | | | | | | | |
