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


Groups > comp.lang.javascript > #35778 > unrolled thread

Image load problem: OK in my Win 7, not in either Win10

Started byDr J R Stockton <J.R.Stockton@physics.org>
First post2018-10-13 14:29 -0700
Last post2018-10-16 05:00 -0700
Articles 13 — 4 participants

Back to article view | Back to comp.lang.javascript


Contents

  Image load problem: OK in my Win 7, not in either Win10 Dr J R Stockton <J.R.Stockton@physics.org> - 2018-10-13 14:29 -0700
    Re: Image load problem: OK in my Win 7, not in either Win10 "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-10-13 20:40 -0700
      Re: Image load problem: OK in my Win 7, not in either Win10 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-14 11:11 +0200
      Re: Image load problem: OK in my Win 7, not in either Win10 John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-14 11:18 +0100
        Re: Image load problem: OK in my Win 7, not in either Win10 "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-10-14 22:06 -0700
      Re: Image load problem: OK in my Win 7, not in either Win10 Dr J R Stockton <J.R.Stockton@physics.org> - 2018-10-14 06:01 -0700
        Re: Image load problem: OK in my Win 7, not in either Win10 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-14 15:29 +0200
        Re: Image load problem: OK in my Win 7, not in either Win10 "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-10-14 21:42 -0700
          Re: Image load problem: OK in my Win 7, not in either Win10 Dr J R Stockton <J.R.Stockton@physics.org> - 2018-10-15 05:02 -0700
            Re: Image load problem: OK in my Win 7, not in either Win10 "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-15 16:06 +0200
              Re: Image load problem: OK in my Win 7, not in either Win10 Dr J R Stockton <J.R.Stockton@physics.org> - 2018-10-15 15:43 -0700
            Re: Image load problem: OK in my Win 7, not in either Win10 "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-10-16 02:55 -0700
              Re: Image load problem: OK in my Win 7, not in either Win10 Dr J R Stockton <J.R.Stockton@physics.org> - 2018-10-16 05:00 -0700

#35778 — Image load problem: OK in my Win 7, not in either Win10

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2018-10-13 14:29 -0700
SubjectImage load problem: OK in my Win 7, not in either Win10
Message-ID<f38f3d44-7c43-4483-a82c-fb0159fd941b@googlegroups.com>
I have the following script fragment in a local HTML page.
FM is a <form>, IM is an unsized <img>.  IM and a textarea
are position:absolute within a position:relative <div>.
The value of DocName names a local .PNG file of about 5kB,
image 640*800px.

Function NewDoc is called by <body onload="...">, and
not before.

In my Win7 PC, Wide and High get the hoped-for values
640 & 800 and function Draw shows the image - OK.

In my Win10 PCs, Wide and High are each about 35, and
no part of the image appears - NOT GOOD.  Firefox logs
no detected errors.

I intend to replace, but not tonight, the setTimeout
with a setInterval of about 0.1 seconds, which will
repeatedly call code to test the .complete property
of the image element and, when that is true will
end the timer and call function Draw.

Any (useful) comment?


<script type="text/javascript">
var IM, Form0, Wide, High // Globals

function NewDoc() {  // Just read the form and wait a bit
  Form0 = document.getElementById('FM'),
  IM = document.getElementById("IM")
  IM.src = Form0.DocName.value		// Get and show the Form
  setTimeout(Next, 1500)		// Short delay needed here
  }

function Next() { // Just show and remember original image details
  Form0.Iwh.value = Wide = IM.width
  Form0.Iht.value = High = IM.height
  Draw() }

// ...


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [next] | [standalone]


#35779

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2018-10-13 20:40 -0700
Message-ID<8b16a9d8-6d22-47b8-8e2d-13595c1fad71@googlegroups.com>
In reply to#35778
Dr J R Stockton wrote:
> I have the following script fragment in a local HTML page.
> FM is a <form>, IM is an unsized <img>.  IM and a textarea
> are position:absolute within a position:relative <div>.
> The value of DocName names a local .PNG file of about 5kB,
> image 640*800px.
> 
> Function NewDoc is called by <body onload="...">, and
> not before.
> 
> In my Win7 PC, Wide and High get the hoped-for values
> 640 & 800 and function Draw shows the image - OK.
> 
> In my Win10 PCs, Wide and High are each about 35, and
> no part of the image appears - NOT GOOD.  Firefox logs
> no detected errors.
> 
> I intend to replace, but not tonight, the setTimeout
> with a setInterval of about 0.1 seconds, which will
> repeatedly call code to test the .complete property
> of the image element and, when that is true will
> end the timer and call function Draw.
> 
> Any (useful) comment?
> 
> 
> <script type="text/javascript">
> var IM, Form0, Wide, High // Globals
> 
> function NewDoc() {  // Just read the form and wait a bit
>   Form0 = document.getElementById('FM'),
>   IM = document.getElementById("IM")
>   IM.src = Form0.DocName.value		// Get and show the Form
>   setTimeout(Next, 1500)		// Short delay needed here
>   }
> 
> function Next() { // Just show and remember original image details
>   Form0.Iwh.value = Wide = IM.width
>   Form0.Iht.value = High = IM.height
>   Draw() }

My first comment is that images have 'onload' and 'onerror' methods you can override. This will eliminate the need for the setTimeout:

img.onload = next
img.onerror = fail

Second, try using the .elements property of the form:

myForm.elements.inputName
myForm.elements["input-name"]


Third, you can access the original image size by using the .naturalHeight and .naturalWidth properties.

Fourth, you should use the JavaScript coding conventions. PascalCase is reserved for classes and constructor functions. 


[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement/elements#Quick_syntax_example

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


#35780

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2018-10-14 11:11 +0200
Message-ID<XnsA97B71D84B898eejj99@194.109.6.166>
In reply to#35779
"Michael Haufe (TNO)" <tno@thenewobjective.com> wrote on 14 Oct 2018 in
comp.lang.javascript: 

> Dr J R Stockton wrote:
>> I have the following script fragment in a local HTML page.
>> FM is a <form>, IM is an unsized <img>.  IM and a textarea
>> are position:absolute within a position:relative <div>.
>> The value of DocName names a local .PNG file of about 5kB,
>> image 640*800px.
>> 
>> Function NewDoc is called by <body onload="...">, and
>> not before.
>> 
>> In my Win7 PC, Wide and High get the hoped-for values
>> 640 & 800 and function Draw shows the image - OK.
>> 
>> In my Win10 PCs, Wide and High are each about 35, and
>> no part of the image appears - NOT GOOD.  Firefox logs
>> no detected errors.
>> 
>> I intend to replace, but not tonight, the setTimeout
>> with a setInterval of about 0.1 seconds, which will
>> repeatedly call code to test the .complete property
>> of the image element and, when that is true will
>> end the timer and call function Draw.
>> 
>> Any (useful) comment?
>> 
>> 
>> <script type="text/javascript">
>> var IM, Form0, Wide, High // Globals
>> 
>> function NewDoc() {  // Just read the form and wait a bit
>>   Form0 = document.getElementById('FM'),
>>   IM = document.getElementById("IM")
>>   IM.src = Form0.DocName.value          // Get and show the Form
>>   setTimeout(Next, 1500)          // Short delay needed here
>>   }
>> 
>> function Next() { // Just show and remember original image details
>>   Form0.Iwh.value = Wide = IM.width
>>   Form0.Iht.value = High = IM.height
>>   Draw() }
> 
> My first comment is that images have 'onload' and 'onerror' methods you
> can override. This will eliminate the need for the setTimeout: 
> 
> img.onload = next
> img.onerror = fail
> 
> Second, try using the .elements property of the form:
> 
> myForm.elements.inputName
> myForm.elements["input-name"]
> 
> 
> Third, you can access the original image size by using the
> .naturalHeight and .naturalWidth properties. 
> 
> Fourth, you should use the JavaScript coding conventions. PascalCase is
> reserved for classes and constructor functions. 

John, you could play with this:

==============
<body>
<script>
  'use strict';
  document.body.onload = () => {
    const myDiv = document.createElement("DIV");
    document.body.appendChild(myDiv);
  
    const myImg = document.createElement("IMG");
    myImg.setAttribute("src", "abcde.jpg");
    document.body.appendChild(myImg);
  
    myImg.onload = () => myDiv.innerHTML = myImg.naturalHeight;
  };
</script>
==============




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

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


#35781

FromJohn G Harris <niam@jghnorth.org.uk.invalid>
Date2018-10-14 11:18 +0100
Message-ID<j156sdpjuvede6120d2if1d5u839r162m9@4ax.com>
In reply to#35779
On Sat, 13 Oct 2018 20:40:59 -0700 (PDT), "Michael Haufe (TNO)"
<tno@thenewobjective.com> wrote:

>Dr J R Stockton wrote:

  <snip>
>Fourth, you should use the JavaScript coding conventions. PascalCase is reserved for classes and constructor functions. 

Its proper name is the Java naming convention. Java programmers have
to use it because it's built into several important system utilities.

There are no ECMAScript system utilities to appease so development
teams can use any naming convention they want. However, they are urged
to use their chosen convention consistently.

  John

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


#35786

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2018-10-14 22:06 -0700
Message-ID<f0fedecd-9206-406a-8652-fec78a95b1ac@googlegroups.com>
In reply to#35781
John G Harris wrote:
> "Michael Haufe (TNO)":
> 
> >Fourth, you should use the JavaScript coding conventions. PascalCase is reserved for classes and constructor functions. 

> Its proper name is the Java naming convention. Java programmers have
> to use it because it's built into several important system utilities.

Why do you believe that is the case? It is inconsistent with anything I've ever seen:

<https://en.wikipedia.org/wiki/Camel_case>

> There are no ECMAScript system utilities to appease so development
> teams can use any naming convention they want. However, they are urged
> to use their chosen convention consistently.

Indeed, within reason. There are limitations to the JavaScript grammar and semantics which influence what the conventions are though.

Following Allman style[1] for example will cause you pain with semicolon insertion for example, so would allowing whitespace after a return statement. There are also legacy conventions which are still used in an evolved form, such as Crockford's [2]

There are also ecosystem constraints built on the assumptions of these conventions. For example, if you've ever worked on or with a .NET project, you are highly likely to encounter a Newtonsoft.Json configuration set to read and generate JSON based on camelCase property names 

[1] https://en.wikipedia.org/wiki/Indentation_style#Allman_style
[2] http://crockford.com/javascript/code.html

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


#35782

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2018-10-14 06:01 -0700
Message-ID<f06ba9ab-2e6f-4a4b-a496-473b2d72f7aa@googlegroups.com>
In reply to#35779
On Sunday, October 14, 2018 at 4:41:08 AM UTC+1, Michael Haufe (TNO) wrote:
> Dr J R Stockton wrote:
> > I have the following script fragment in a local HTML page.
> > FM is a <form>, IM is an unsized <img>.  IM and a textarea
> > are position:absolute within a position:relative <div>.
> > The value of DocName names a local .PNG file of about 5kB,
> > image 640*800px.
> > 
> > Function NewDoc is called by <body onload="...">, and
> > not before.
> > 
> > In my Win7 PC, Wide and High get the hoped-for values
> > 640 & 800 and function Draw shows the image - OK.
> > 
> > In my Win10 PCs, Wide and High are each about 35, and
> > no part of the image appears - NOT GOOD.  Firefox logs
> > no detected errors.
> > 
> > I intend to replace, but not tonight, the setTimeout
> > with a setInterval of about 0.1 seconds, which will
> > repeatedly call code to test the .complete property
> > of the image element and, when that is true will
> > end the timer and call function Draw.
> > 
> > Any (useful) comment?
> > 
> > 
> > <script type="text/javascript">
> > var IM, Form0, Wide, High // Globals
> > 
> > function NewDoc() {  // Just read the form and wait a bit
> >   Form0 = document.getElementById('FM'),
> >   IM = document.getElementById("IM")
> >   IM.src = Form0.DocName.value		// Get and show the Form
> >   setTimeout(Next, 1500)		// Short delay needed here
> >   }
> > 
> > function Next() { // Just show and remember original image details
> >   Form0.Iwh.value = Wide = IM.width
> >   Form0.Iht.value = High = IM.height
> >   Draw() }


> My first comment is that images have 'onload' and 'onerror' methods
> you can override. This will eliminate the need for the setTimeout:
> 
> img.onload = next
> img.onerror = fail

Much better, and solves the problem.  Thanks yet again.  
But why did a generous Timeout not suffice?
 

> Second, try using the .elements property of the form:
> 
> myForm.elements.inputName
> myForm.elements["input-name"]

In what way is that better, as I have used it, than just
   myForm.input-name  ?
is the latter likely to be deprecated away?


> Third, you can access the original image size by using the .naturalHeight and .naturalWidth properties.

Good. Done.


> Fourth, you should use the JavaScript coding conventions.
> PascalCase is reserved for classes and constructor functions.

A declared identifier is in effect a Noun; as far as I
recall, for those of significance I have always used
an initial capital letter, except maybe for loop counters.
I'm too old to train my Shift finger into a new convention.

Anyway, what I really want, in all browsers, is
<script type="text/pascal"> .


> [1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement/elements#Quick_syntax_example

I see from the reference that .elements allows types of
action which I doubt that I ever knew I wanted!


What I'd like to have is, to supplement  window.innerWidth ,
is  printerpaper.innerWidth .

I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
in CSS for HTML; is there some property by which ECMAscript can tell
whether the output is to screen or printer?

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

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


#35783

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2018-10-14 15:29 +0200
Message-ID<XnsA97B9D981FFEFeejj99@194.109.6.166>
In reply to#35782
Dr J R Stockton <J.R.Stockton@physics.org> wrote on 14 Oct 2018 in 
comp.lang.javascript:

> I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
> in CSS for HTML; is there some property by which ECMAscript can tell
> whether the output is to screen or printer?

You could use:

window.onbeforeprint
and
window.onbeafterprint

... to set style values as you want, 
but not, methinks, to read the actual printing values.

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

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


#35785

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2018-10-14 21:42 -0700
Message-ID<4bde13a8-d268-434c-8c90-399efc40d8a1@googlegroups.com>
In reply to#35782
Dr J R Stockton wrote:
> Michael Haufe wrote:

> Much better, and solves the problem.  Thanks yet again.  
> But why did a generous Timeout not suffice?

Because using a timeout is not directly related to the loading of the image. You don't know how long to wait and have reduced your reasoning to probability where it isn't necessary.

Analogy: When you send a letter in the mail, you can assume a 3 week wait is sufficient for it to arrive -or- you can request a receipt and know for certain.

> > Second, try using the .elements property of the form:
> > 
> > myForm.elements.inputName
> > myForm.elements["input-name"]
> 
> In what way is that better, as I have used it, than just
>    myForm.input-name  ?
> is the latter likely to be deprecated away?

The .elements property was introduced to prevent collisions with other propertes on the element. For example:

<form action="https://example.com">
    <input type="hidden" name="action" value="https://example.org">
</form>

<script>
    var form = document.forms[0]
    form.action
</script>

What does form.action return? What should it return? Is that what you expected?

Better to use the elements property and remove all doubt
 
> > Fourth, you should use the JavaScript coding conventions.
> > PascalCase is reserved for classes and constructor functions.
> 
> A declared identifier is in effect a Noun; as far as I
> recall, for those of significance I have always used
> an initial capital letter, except maybe for loop counters.
> I'm too old to train my Shift finger into a new convention.

If your code remains private and for personal use only, it's of course irrelevant but once you code for others in the JavaScript community, conventions are key for understanding.
 
> Anyway, what I really want, in all browsers, is
> <script type="text/pascal"> .

This exists, but I've never used it:

<http://p2js.gelicon.biz/en>

> What I'd like to have is, to supplement  window.innerWidth ,
> is  printerpaper.innerWidth .
> 
> I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
> in CSS for HTML; is there some property by which ECMAscript can tell
> whether the output is to screen or printer?

You utilize the new API window.matchMedia('print'): 

<script>
    var mediaQueryList = window.matchMedia('print');
    mediaQueryList.addListener(function(mql) {
        if (mql.matches) {
            console.log('onbeforeprint equivalent');
        } else {
            console.log('onafterprint equivalent');
        }
    });
</script>

Details:

<https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries>

but there still remains some cross-browser issues:

<https://www.tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/>

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


#35787

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2018-10-15 05:02 -0700
Message-ID<26c6ed3a-f433-4d15-b979-095d9c1b7907@googlegroups.com>
In reply to#35785
On Monday, October 15, 2018 at 5:43:07 AM UTC+1, Michael Haufe (TNO) wrote:
> Dr J R Stockton wrote:
> > Michael Haufe wrote:
> 
> > Much better, and solves the problem.  Thanks yet again.  
> > But why did a generous Timeout not suffice?
> 
> Because using a timeout is not directly related to the loading of the image. You don't know how long to wait and have reduced your reasoning to probability where it isn't necessary.

We have a misunderstanding.  The test image is small and on the
local hard drive, so should load without perceptible delay.  When,
in Win7, I first considered the need for a delay-until-loaded, I
put in a simple   alert()   .  Not a good final solution, but
tolerable (I did not need to wait before dismissing the alert)
and proving that a moderately generous delay should work
adequately in Win7.  I then constructed a Timeout of maybe 3
seconds, which worked in Win7.  But, to my surprise, it did
not work in Win10, even after a significant increase - _it is
that _difference_ between Win7 & Win10 that I was wondering about_.

 
> Analogy: When you send a letter in the mail, you can assume a 3 week wait is sufficient for it to arrive -or- you can request a receipt and know for certain.

But if no receipt arrives, one cannot know for certain whether the
letter arrived...


> > > Second, try using the .elements property of the form:
> > > 
> > > myForm.elements.inputName
> > > myForm.elements["input-name"]
> > 
> > In what way is that better, as I have used it, than just
> >    myForm.input-name  ?
> > is the latter likely to be deprecated away?
> 
> The .elements property was introduced to prevent collisions with other propertes on the element. For example:
> 
> <form action="https://example.com">
>     <input type="hidden" name="action" value="https://example.org">
> </form>
> 
> <script>
>     var form = document.forms[0]
>     form.action
> </script>
> 
> What does form.action return? What should it return? Is that what you
> expected?

I would have expected to be confused by that, sooner or later, and
therefore would have chosen   name="akshun"   (Thomas might have
used Wirkung).  I have a strong tendency to avoid spelling my
identifiers in the same way as anything else in the script, the
page, or the file set...

> Better to use the elements property and remove all doubt

But I see your point.


 
> > > Fourth, you should use the JavaScript coding conventions.
> > > PascalCase is reserved for classes and constructor functions.
> > 
> > A declared identifier is in effect a Noun; as far as I
> > recall, for those of significance I have always used
> > an initial capital letter, except maybe for loop counters.
> > I'm too old to train my Shift finger into a new convention.
> 
> If your code remains private and for personal use only, it's of course irrelevant but once you code for others in the JavaScript community, conventions are key for understanding.
>  
> > Anyway, what I really want, in all browsers, is
> > <script type="text/pascal"> .
> 
> This exists, but I've never used it:
> 
> <http://p2js.gelicon.biz/en>

Ingenious; the page is worth looking at, if only for amusement.
Debugging one's Pascal source code might be rather difficult,
using a browser's view of the JavaScript - but I suppose the
source would normally have been well-debugged in a Pascal system.

A quick check suggests that the cited page is a Google
Translate of the original Russian, and that Russian-English
Translate has not been greatly changed since.



> > What I'd like to have is, to supplement  window.innerWidth ,
> > is  printerpaper.innerWidth .
> > 
> > I use @media print { .NPR { display: none; } } /* SB CIWAS 20140116 */
> > in CSS for HTML; is there some property by which ECMAscript can tell
> > whether the output is to screen or printer?
> 
> You utilize the new API window.matchMedia('print'): 
> 
> <script>
>     var mediaQueryList = window.matchMedia('print');
>     mediaQueryList.addListener(function(mql) {
>         if (mql.matches) {
>             console.log('onbeforeprint equivalent');
>         } else {
>             console.log('onafterprint equivalent');
>         }
>     });
> </script>
> 
> Details:
> 
> <https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries>
> 
> but there still remains some cross-browser issues:
> 
> <https://www.tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/>

Seems rather fraught.  I can already scale the stuff on-screen first,
and printing can be done with Print Preview - those will suffice.

OT:

Led there by one of your cites - have you any connection with, or
influence over,
https://html.spec.whatwg.org/multipage/forms.html#input-author-notes ?
There, section 4.10.1.8 Date, time, and number formats, paragraph 5,
last sentence, is objectionable.  That format is, AIUI, in common
normal use in Japan (except when using pure Japanese) - and it is
probably preferred by many individuals, as well as by me.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

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


#35788

From"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date2018-10-15 16:06 +0200
Message-ID<XnsA97CA3E07FF90eejj99@194.109.6.166>
In reply to#35787
Dr J R Stockton <J.R.Stockton@physics.org> wrote on 15 Oct 2018 in
comp.lang.javascript: 

>> Because using a timeout is not directly related to the loading of the
>> image. You don't know how long to wait and have reduced your reasoning
>> to probability where it isn't necessary. 
> 
> We have a misunderstanding.  The test image is small and on the
> local hard drive, so should load without perceptible delay.  When,
> in Win7, I first considered the need for a delay-until-loaded, I
> put in a simple   alert()   .  Not a good final solution, but
> tolerable (I did not need to wait before dismissing the alert)
> and proving that a moderately generous delay should work
> adequately in Win7.  I then constructed a Timeout of maybe 3
> seconds, which worked in Win7.

But what is wrong with 'image.onload'?
It should take care of any timing problem?

Or, you could build the onload yourself, as, [if my stipulation that the 
measured width is either 0 or the true value is correct,] you could build a 
a module testing for this zero and repeating that after a small timeout till 
the value is nolonger zero.


> But, to my surprise, it did
> not work in Win10, even after a significant increase - _it is
> that _difference_ between Win7 & Win10 that I was wondering about_.

WeLl, you would have to specify the engine you are talking about,
so the browesr type and version. And perhaps the O.S. core functions could 
be different.

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

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


#35791

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2018-10-15 15:43 -0700
Message-ID<5c79e26b-0f4c-4ce6-908f-73d4c2455e85@googlegroups.com>
In reply to#35788
On Monday, October 15, 2018 at 3:07:09 PM UTC+1, Evertjan. wrote:
> Dr J R Stockton wrote on 15 Oct 2018 in
> comp.lang.javascript: 
> 
> >> Because using a timeout is not directly related to the loading of the
> >> image. You don't know how long to wait and have reduced your reasoning
> >> to probability where it isn't necessary. 
> > 
> > We have a misunderstanding.  The test image is small and on the
> > local hard drive, so should load without perceptible delay.  When,
> > in Win7, I first considered the need for a delay-until-loaded, I
> > put in a simple   alert()   .  Not a good final solution, but
> > tolerable (I did not need to wait before dismissing the alert)
> > and proving that a moderately generous delay should work
> > adequately in Win7.  I then constructed a Timeout of maybe 3
> > seconds, which worked in Win7.
> 
> But what is wrong with 'image.onload'?
> It should take care of any timing problem?

Indeed, but I was not aware of that method at the time.
ANYTHING that got the image loaded was a good TEMPORARY
solution, enabling me to make progress with handling the
later parts of the job.


> Or, you could build the onload yourself, as, [if my stipulation that the 
> measured width is either 0 or the true value is correct,] you could build a 
> a module testing for this zero and repeating that after a small timeout till 
> the value is nolonger zero.

That stipulation is an assumption, and false; but a
test for image size>50 might have worked.


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

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


#35792

From"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date2018-10-16 02:55 -0700
Message-ID<29c102dd-d67c-4641-8946-8bf6405c3f8d@googlegroups.com>
In reply to#35787
Dr J R Stockton wrote:
> Michael Haufe (TNO) wrote:
> > Analogy: When you send a letter in the mail, you can assume a 3 week wait is sufficient for it to arrive -or- you can request a receipt and know for certain.
> 
> But if no receipt arrives, one cannot know for certain whether the
> letter arrived...


See also: <https://en.wikipedia.org/wiki/Two_Generals%27_Problem>
 
  
> > This exists, but I've never used it:
> > 
> > <http://p2js.gelicon.biz/en>
> 
> Ingenious; the page is worth looking at, if only for amusement.
> Debugging one's Pascal source code might be rather difficult,
> using a browser's view of the JavaScript - but I suppose the
> source would normally have been well-debugged in a Pascal system.

This resolved by another modern feature: Source Maps:

<https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map>

So you would in fact be able to debug the original source language if the compiler author generated one.


> OT:
> 
> Led there by one of your cites - have you any connection with, or
> influence over,
> https://html.spec.whatwg.org/multipage/forms.html#input-author-notes ?
> There, section 4.10.1.8 Date, time, and number formats, paragraph 5,
> last sentence, is objectionable.  That format is, AIUI, in common
> normal use in Japan (except when using pure Japanese) - and it is
> probably preferred by many individuals, as well as by me.

As much as you do. If you have the patience you might be able to submit an issue through here:

<https://whatwg.org/>

They have at least one IRC channel. You could also try submitting a GitHub issue

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


#35793

FromDr J R Stockton <J.R.Stockton@physics.org>
Date2018-10-16 05:00 -0700
Message-ID<77b4c66b-b566-4abb-8c5c-7873995a78ea@googlegroups.com>
In reply to#35792
On Tuesday, October 16, 2018 at 10:55:31 AM UTC+1, Michael Haufe (TNO) wrote:

> As much as you do. If you have the patience you might be able to submit an issue through here:
> 
> <https://whatwg.org/>
> 
> They have at least one IRC channel. You could also try submitting a
> GitHub issue

I don't use those.  But there is an E-mail address at the foot of that page, and I have as yet received no bounce message.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.javascript


csiph-web