Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11982 > unrolled thread

Mysterious "Unknown runtime error" in a script in a HTA file

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  Mysterious "Unknown runtime error" in a script in a HTA file JJ <jj4public@vfemail.net> - 2018-10-15 20:31 +0700
    Re: Mysterious "Unknown runtime error" in a script in a HTA file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-15 16:13 +0200
      Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-15 10:28 -0400
        Re: Mysterious "Unknown runtime error" in a script in a HTA file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-15 23:22 +0200
          Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-15 19:04 -0400
            Re: Mysterious "Unknown runtime error" in a script in a HTA file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-16 10:01 +0200
              Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-16 10:50 +0200
                Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-16 09:34 -0400
                  Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-16 16:04 +0200
                    Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-16 10:28 -0400
                      Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-16 18:53 +0200
                        Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-16 14:25 -0400
                          Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-16 21:23 +0200
                            Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-16 16:04 -0400
                              Re: Mysterious "Unknown runtime error" in a script in a HTA file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-16 22:38 +0200
                                Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-16 18:19 -0400
                              Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-17 09:30 +0200
                                Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-17 09:42 -0400
                                  Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-17 21:59 +0200
      Re: Mysterious "Unknown runtime error" in a script in a HTA file JJ <jj4public@vfemail.net> - 2018-10-18 02:10 +0700
        Re: Mysterious "Unknown runtime error" in a script in a HTA file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-17 21:36 +0200
    Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-15 10:14 -0400
    Re: Mysterious "Unknown runtime error" in a script in a HTA file "R.Wieser" <address@not.available> - 2018-10-15 17:33 +0200
      Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-15 11:57 -0400
        Re: Mysterious "Unknown runtime error" in a script in a HTA file JJ <jj4public@vfemail.net> - 2018-10-16 18:07 +0700
          Re: Mysterious "Unknown runtime error" in a script in a HTA file "Mayayana" <mayayana@invalid.nospam> - 2018-10-16 09:58 -0400
    Re: Mysterious "Unknown runtime error" in a script in a HTA file "Dave \"Crash\" Dummy" <invalid@invalid.invalid> - 2018-10-16 12:28 -0400

Page 1 of 2  [1] 2  Next page →

#11982 — Mysterious "Unknown runtime error" in a script in a HTA file

I'm seriously puzzled. The problem seems to occur only for TABLE element,
and if the HTML code is opened as an HTML application. i.e. in *.hta file.

<html>
<head></head>
<body>
  <table id="tbl"></table>
  <script language="vbscript">

  result = ""

  'populate result...

  tbl.innerHTML = result 'source of error. but how can it?

  </script>
</body>
</html>

[toc] | [next] | [standalone]

#11983

JJ <jj4public@vfemail.net> wrote on 15 Oct 2018 in 
microsoft.public.scripting.vbscript:

> I'm seriously puzzled. The problem seems to occur only for TABLE element,
> and if the HTML code is opened as an HTML application. i.e. in *.hta file.
> 
> <html>
> <head></head>
> <body>
>   <table id="tbl"></table>
>   <script language="vbscript">
> 
>   result = ""
> 
>   'populate result...
> 
>   tbl.innerHTML = result 'source of error. but how can it?

try:

document.getElementById("tbl").innerHTML = result;


 
>   </script>
> </body>
> </html>
> 



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11985

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote

| try:
|
| document.getElementById("tbl").innerHTML = result;
|

  ?? That's the same thing. And it raises the same error.

 I've never understood why anyone uses getElementById.
It's a superfluous, overcomplicated version of just
referencing the ID itself. There's nothing wrong with
his tbl.innerHTML.

[toc] | [prev] | [next] | [standalone]

#11988

"Mayayana" <mayayana@invalid.nospam> wrote on 15 Oct 2018 in 
microsoft.public.scripting.vbscript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote
> 
>| try:
>|
>| document.getElementById("tbl").innerHTML = result;
>|
> 
>   ?? That's the same thing. And it raises the same error.

Okay.

>  I've never understood why anyone uses getElementById.
> It's a superfluous, overcomplicated version of just
> referencing the ID itself. There's nothing wrong with
> his tbl.innerHTML.

No, it is not,
it is just an remnant in IE, I think, as 
just the id-name could also mean a variable that is defined in js.

In modern browsers there is:

document.getElementById("tbl")
document.querySelector("#tbl")
document.querySelectorAll("#tbl")[0]

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11989

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote

| >  I've never understood why anyone uses getElementById.
| > It's a superfluous, overcomplicated version of just
| > referencing the ID itself. There's nothing wrong with
| > his tbl.innerHTML.
|
| No, it is not,
| it is just an remnant in IE, I think, as
| just the id-name could also mean a variable that is defined in js.
|

  Who would use a variable with the same name
as an element ID? If you can't keep them straight
then you might try using naming patterns. In other
words, name a DIV "DivMain" or a TABLE "TabMain".
Don't name a TABLE "i" or "s" and don't name a
variable "TableMain" or "ContentDiv". Problem solved. :)

| In modern browsers there is:
|
| document.getElementById("tbl")
| document.querySelector("#tbl")
| document.querySelectorAll("#tbl")[0]
|

  There's nothing modern about it. getElementById
works back at least to IE6. Probably IE4. But it's
not necessary. The following works perfectly fine
in "modern" Firefox:

<HTML>
<HEAD>
</HEAD>
<BODY>
<DIV ID="div1">
</DIV>
<SCRIPT>
div1.innerText="okey doke";
</SCRIPT>
</BODY></HTML>

  If you don't trust yourself to keep your variables
separate from your IDs and classes then you can
use those methods, but they are superfluous. 

[toc] | [prev] | [next] | [standalone]

#11990

"Mayayana" <mayayana@invalid.nospam> wrote on 16 Oct 2018 in 
microsoft.public.scripting.vbscript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote
> 
>| >  I've never understood why anyone uses getElementById.
>| > It's a superfluous, overcomplicated version of just
>| > referencing the ID itself. There's nothing wrong with
>| > his tbl.innerHTML.
>|
>| No, it is not,
>| it is just an remnant in IE, I think, as
>| just the id-name could also mean a variable that is defined in js.
>|
> 
>   Who would use a variable with the same name
> as an element ID? If you can't keep them straight
> then you might try using naming patterns. In other
> words, name a DIV "DivMain" or a TABLE "TabMain".
> Don't name a TABLE "i" or "s" and don't name a
> variable "TableMain" or "ContentDiv". Problem solved. :)
> 
>| In modern browsers there is:
>|
>| document.getElementById("tbl")
>| document.querySelector("#tbl")
>| document.querySelectorAll("#tbl")[0]
>|
> 
>   There's nothing modern about it. getElementById
> works back at least to IE6. Probably IE4. But it's
> not necessary. The following works perfectly fine
> in "modern" Firefox:
> 
> <HTML>
> <HEAD>
> </HEAD>
> <BODY>
> <DIV ID="div1">
> </DIV>
> <SCRIPT>
> div1.innerText="okey doke";
> </SCRIPT>
> </BODY></HTML>
> 
>   If you don't trust yourself to keep your variables
> separate from your IDs and classes then you can
> use those methods, but they are superfluous. 

If you trust yourself,
there is no need for any scripting-convention.

You could easily do:

const myChangingValue;
let myConstantValue;

However, in interaction with others, there is.

So if you ask about/discuss your code in this NG,
please don't advocate for your selftrusted shortcuts.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11991

Evertjan,

> So if you ask about/discuss your code in this NG,
> please don't advocate for your selftrusted shortcuts.

Although I agree with you that you shouldn't use stupid namings, there is 
nothing wrong with using a method that is largely unknown to others (and it 
seems that that is all it is).

And just as a quick test I tried the same in Firefox, and it had no problem 
with it.  IOW, its not just an MS fad (read: its a good indication its part 
of the JS spec).

Having said that, it definitily would (as always) be a good idea to mention 
when you're using something different than the widely-known-and-used 
methods.  If only to forego any confusion. :-)

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#11993

"R.Wieser" <address@not.available> wrote

| Although I agree with you that you shouldn't use stupid namings, there is
| nothing wrong with using a method that is largely unknown to others (and 
it
| seems that that is all it is).
|

   Shouldn't anyone who does coding use some kind
of system to make their code clear, at least to
themselves? To me that's common sense. A great
example of the problem of not doing that is so-called
"minified" code. Something like:

  BooExists = FileExists(FilePath)
becomes:
  a = b(c)

   That's done partly to obfuscate. It's unreadable code.

   I usually use data type or element indicators for things:
iTotal = iSomething * 3
TDMain.padding = 0

   When I use someone else's code I usually rename
all the variables as part of my process of familiarizing
myself with the code and making it more readable.
It's the same as if I took over someone else's kitchen.
I'd want to put the plastic wrap in a drawer and put the
plates in the cabinet over the sink. Not because that's
the "right" way to do it but because it's my system
and it works for me.

   There's actually a name for prepending variables
with identifiers. I think it's called Hungarian notation.
(I have no idea where that came from.) Many people
in VB use such a notation, prepending s for string,
L for long, Col for collection, etc. Many other people
use prepends like m or g to indicate a variable at
module scope or global scope. Some use both:
gsFilePath.

  Whatever works to make your code clear for you
makes sense to me. But it should be clear. You should
be able to read your own code and make sense of it.
If you've got a DIV with a name that sounds to you
like a script variable then you're in trouble. In that case
you're probably a person who looks in every kitchen
cabinet every time he needs a plate.

  A related issue of interest: There's a notable difference
between VB* and C-ish code like C++ and javascript.
The former is non-case-sensitive, which helps to make
more readable variable names, like iTotal or AReadingList().
It also means that we can use editors that auto-adjust
variable case, which helps a lot to notice mis-spelled
variables. In other words, if I have sBookListFile and
type sbooklitfile my editor won't capitalize the B, L, F,
which makes it easier for me to see that I mis-spelled it.

  C-ish programmers often make fun of that, but all it
really means for them is that they have less options.
Javascript variables end up being nearly all lower case
because it's easier not to have any case at all when it's
case sensitive. But itotal and areadinglist are not as
readable.

  Which is right? Whichever works for you. To my
mind C-ish code is a monstrosity that should have
been erased before it spread. But now it's considered
normal and lots of people like it. If it works for them
it's none of my business.

| Having said that, it definitily would (as always) be a good idea to 
mention
| when you're using something different than the widely-known-and-used
| methods.  If only to forego any confusion. :-)
|

  You're heading for a fringe position when you start
thinking of it that way. What you may regard as widely
used is neither here nor there. Both methods are
legitimate methods of browser DOM for all browsers.

  I've never used getElementById. I've written a lot
of HTA utlities and webpages, never finding a need for
that method. The fact that Evertjan wasn't familiar
with the ability to refer to an ID as an object doesn't
make it quirky. It just means he didn't know about it.

   Everyone has their favorites and everyone
has things they don't like. In VB I've never really
got the point of the IIf method, for instance. But
that's my problem. The fact I don't like it doesn't
make it illegitimate or "not widely used". It's an
official, functional part of the VB language. No more
and no less than any other method. The same is
true of IDs as object referrents in browser DOM.
Div1.innerText is in no way less official than
x = getElementById("Div1").innerText. The former
is also a lot more compact and readable.

   While I can accept the idea that some people
want to use getElementById because they're not
comfortable keeping their variables clear, I regard
that as inferior coding practice, excessive complexity,
and wasted functionality. That's just my opinion.
Fortunately, we can all use whatever code we like,
as long as it's valid and it works. Anyone who doesn't
like that can go rant on Twitter:
 #IWantToBeOffendedToo  :) 

[toc] | [prev] | [next] | [standalone]

#11995

Mayayana,

>   Shouldn't anyone who does coding use some
> kind of system to make their code clear, at least
> to themselves?

What makes you think it wasn't clear - crystal clear even - to JJ ?

>   That's done partly to obfuscate. It's unreadable code.

I'm going to ignore that, as it isn't even remotely related to the "don't 
you use a menthod I do not readily recognise" stance EverJan posted.  Nor is 
it anything JJ was seemingly aiming for (conciously or not) or advocating.

>  You're heading for a fringe position when you start
> thinking of it that way.

I do not understand how the above is connected to my "just make it clear 
when you do" advice.  Sorry.

>   While I can accept the idea that some people
> want to use getElementById because they're not
> comfortable keeping their variables clear, I regard
> that as inferior coding practice, excessive complexity,
> and wasted functionality.

True.

But what has that to do with JJs decision to use elements ID as an object ?

I get the feeling we are not even talking about the same thing(s) here ...

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#11996

"R.Wieser" <address@not.available> wrote

| >   Shouldn't anyone who does coding use some
| > kind of system to make their code clear, at least
| > to themselves?
|
| What makes you think it wasn't clear - crystal clear even - to JJ ?
|

  Because that's what he said -- that he uses
getElementById to avoid possible mixups between
HTML element IDs and script variables. If he doesn't
know which is which then his code is not clear to him.

| >   While I can accept the idea that some people
| > want to use getElementById because they're not
| > comfortable keeping their variables clear, I regard
| > that as inferior coding practice, excessive complexity,
| > and wasted functionality.
|
| True.
|
| But what has that to do with JJs decision to use elements ID as an object 
?
|
| I get the feeling we are not even talking about the same thing(s) here ...
|

  Maybe not. :)
  JJ (and I) was using tbl.innerHTML. Everjan thought
that was invalid code and said to use getElementById
instead.

  Both methods use element IDs as objects. Both
are valid DOM scripting. But the first does it directly
while the second unnecessarily adds steps and variables.

tbl.innerHTML = "apple"
document.getElementById("tbl").innerHTML = "apple"

  The second version has to reference the document,
find a method and parse "tbl" to get the same pointer
that's already provided by tbl. It's all unnecessary.
As Matthew Curland, one of the developers of VB,
used to say: Every period you use indicates a
referenced object and is therefore less efficient.

  In this case, tbl is already an object. It doesn't
need a new reference created, which is what
getElementById does. I don't know whether
getElementById is actually slower. It probably
doesn't matter on the level of human perception.
But it is a clunky, unnecessarily complex way of
doing the job.

[toc] | [prev] | [next] | [standalone]

#11998

Mayayana

>  Because that's what he said -- that he uses
> getElementById to avoid possible mixups between
> HTML element IDs and script variables.

He did ?  Where ?   Not in the two post of his in this thread.

>  JJ (and I) was using tbl.innerHTML.

I saw that JJ posted that as part of his sample code.

> Everjan thought that was invalid code and said to use
> getElementById instead.

Nope, thats not what he said at all.  He expressed he didn't like the 
method, because of (his?) possible confusion with variable names.

>  The second version has to reference the document,
> find a method and parse "tbl" to get the same pointer
> that's already provided by tbl. It's all unnecessary.

That was not what I was talking (to EvertJan) about.   It was soly about the 
why of his rejection of the method.

>  In this case, tbl is already an object.  It doesn't
> need a new reference created, which is what
> getElementById does.

As long as you are *absolutily sure* that that ID - and the same-named 
object - exists than I do not see any problem with using it directly.  In 
all other cases using getElementById and testing for a null is simply a bit 
of defensive programming (allowing the script to continue running, instead 
of stopping its execution)

> But it is a clunky, unnecessarily complex way of
> doing the job.

As you might read from the above, I do not agree with you.   I think that 
both methods have their usage - depending on how sure you are of the 
contents of the html page.

In other words, I would not advice the direct object method for webpages 
[1], but could imagine that it is prefectly at its place in HTA files

[1] Just think of FireFox plugins (a)like GreaseMonkey, which can cause 
elements to disappear without a notice.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#11999

"R.Wieser" <address@not.available> wrote


| In other words, I would not advice the direct object method for webpages
| [1], but could imagine that it is prefectly at its place in HTA files
|
| [1] Just think of FireFox plugins (a)like GreaseMonkey, which can cause
| elements to disappear without a notice.
|

 You really are nuts. :)

  You won't use something like Div1.display = "none"
because you're worried someone might be hacking
your webpage and raise an error? So you check every
object before you use it? What about error trapping?
I thought it was silly that Evertjian was worried he
might mix up his variables and his IDs. Now you're
saying you can't directly reference the object because
it will raise an error. You're not making sense.

  Say your page has one of these:

  Div1.display = "none"

  document.getElementById("Div1").display = "none"

   How is the second option more stable than the first
if Div1 doesn't exist? Neither one shows any kind of script
error when I run them in a page that has no Div1.

   If you have no idea what your script is doing, or
if you want to anticipate the endless possibilities of
a GreaseMonkey-using visitor, then haven't you error
trapped? You can even check to see whether Div1
is an object if you like, though I've never heard of
anyone doing it:

<html>
<head></head>
<body>
  <table id="tbl"><TR><TD></TD></TR></table>
  <script language="vbscript">
msgbox IsObject(tbl) 'returns true
  tbl.innerHTML = result
  </script>
</body>
</html>

   My apologies for using VBScript in a VBScript group,
but I didn't know the js corollary of IsObject. :)

[toc] | [prev] | [next] | [standalone]

#12000

Mayayana,

>  You won't use something like Div1.display = "none"
> because you're worried someone might be hacking
> your webpage and raise an error?

Kiddo, currently I am too tired to humor you.   Go look up what "defensive 
programming" means.  You might learn a thing or two.  Goodbye.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#12001

"R.Wieser" <address@not.available> wrote

| Kiddo, currently I am too tired to humor you.   Go look up what "defensive
| programming" means.

  I think I know what that means by listening to you
and Evertjian. You've spent a day coming up with
any and every reason why it's not a good idea to
use something like Div1.display = "none". If you
don't want to use it that's up to you, but you don't
need to come up with reasons why other people
shouldn't use it.

  I've kept answering you because this is a worthwhile
point. There's no reason for anyone to be "scared"
into using getElementById through hokey reasoning about
errors, confusing code, the nutty idea that it's old
fashioned, outdated, or IE-only. None of that
is true.
  It's not a problem to use getElementById. I know
everyone tends to like to stay with what they know.
But getElementById is unnecessary, excessively
complicated, and superfluous. There's no reason for
other people to develop a poor programming habit. 

[toc] | [prev] | [next] | [standalone]

#12002

"Mayayana" <mayayana@invalid.nospam> wrote on 16 Oct 2018 in 
microsoft.public.scripting.vbscript:

> Div1.display = "none"

THAT at least will not work, try:

Div1.style.display = "none"

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#12003

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote

| > Div1.display = "none"
|
| THAT at least will not work, try:
|
| Div1.style.display = "none"
|

    Ah. Good one. I often forget that. 

[toc] | [prev] | [next] | [standalone]

#12004

Mayayana,

> You've spent a day coming up with any and every
> reason why it's not a good idea to use something
> like Div1.display = "none".

Which is specifically *NOT* what I've been saying.

And by the way: From how many third parties can a webpage download 
additional content ?  And yes, that includes JS too.   Don't you think that 
a little bit caution would be a good idea ?   Well, I do.

I have absolutily no idea why you thought you needed to try to ridicule me, 
but it shows, at least to me, you have been flapping your mouth without 
actually enagaging your brains.

You see, in the grandparent I rather specifically mentioned GreaseMonky, but 
for some reason you failed to see that its scripts would exactly be "hacking 
your webpage" (instead of some fantasized third party).

And as I'm writing GreaseMonkey scripts often with routines that get shared 
between several of them it pays to write them with error catching build in. 
And yes, that includes checking if the element(s) you're targetting actually 
(still) exists.   Precisely because than a disappearing element (because of 
layout changes you do not have any control over) wont stop the rest of the 
(GreaseMonky) script to perform its actions.

I don't know who you actually are angy towards, but I certainly do not wish 
to be used as punching bag.  Comprende ?     Behave yourself.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#12005

"R.Wieser" <address@not.available> wrote

| And by the way: From how many third parties can a webpage download
| additional content ?  And yes, that includes JS too.   Don't you think 
that
| a little bit caution would be a good idea ?   Well, I do.
|

  I don't think it should be allowed at all. The Internet
was designed to separate domains. Third party cookies
subvert that. Scripts and fonts coming from Google
subvert that. Iframes were considered bad manners
and insecure, nearly phased out, before the likes of
Google and Facebok started using them to load ads and
thereby set 3rd-party cookies. I think the solution is
to block browsers from loading external content.

  But I don't know what that issue has to do with the
topic of tbl.innerHtml vs getElementById.

   If you have anything relevant point to make about
tbl.innerHTML, or want to clarify some misunderstanding
on my part, then that's fine. But I repeatedly asked you
to show some reason why getElementById is somehow
safer and you didn't. You instead came up with unrelated,
tangential topics. If you're going to confuse things then
I'll try to clarify them.

| And as I'm writing GreaseMonkey scripts often with routines that get 
shared
| between several of them it pays to write them with error catching build 
in.
| And yes, that includes checking if the element(s) you're targetting 
actually
| (still) exists.

  Suit yourself. But didn't you bring up GreaseMonkey
to make a point? The original question: Why is
getElementById superior? In this case you seem to
be saying that you think it's "safer", less error-prone.
I don't get it. How is it better in checking whether an
object exists?

If IsObject(tbl) then.....

x = getElementById("tbl")
If IsObject(x) then....

  Am I missing something?

[toc] | [prev] | [next] | [standalone]

#12009

Mayayana,

> But didn't you bring up GreaseMonkey to make a point?

Not quite, but if you want to think of it that way than be my guest.  Do you 
have a problem with it ?  If so which one and why.

> The original question: Why is getElementById superior?

No, it wasn't.  At least not in this thread.    And definitily not a 
question which I would want to waste my time on.

>  Am I missing something?

You are trying to yank my chain there, are you.   Even if you would have 
added brackets around the "if" condition and ment to use a curly bracket 
instead of that "then" and IsObject would exist under JS, referencing a 
non-existing something (in the first line) will *still* throw an error.

You know, I'm starting to doubt that you are actually Mayayana ...

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#12006

On Mon, 15 Oct 2018 16:13:22 +0200, Evertjan. wrote:
> 
> try:
> 
> document.getElementById("tbl").innerHTML = result;

Sorry for the late reply.

I'm not looking for a solution to my problem. I was asking how the error
occurs (which is already answered by Mayayana).

And I specifically don't use `getElementById()` because I don't have any
variable named `tbl`. FYI, I'm not an early adopter of newer standards, so
I'll use old specification or even dodgy technique as long as it works.
Especially if the code is for private use.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web