{"id":21312,"date":"2016-04-16T03:01:20","date_gmt":"2016-04-15T17:01:20","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/ITblog\/?p=21312"},"modified":"2016-04-16T07:14:18","modified_gmt":"2016-04-15T21:14:18","slug":"javascript-dynamic-scheduled-function-primer-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/javascript-dynamic-scheduled-function-primer-tutorial\/","title":{"rendered":"Javascript Dynamic Scheduled Function Primer Tutorial"},"content":{"rendered":"
\"Javascript<\/a>

Javascript Dynamic Scheduled Function Primer Tutorial<\/p><\/div>\n

Today’s very generic HTML and Javascript tutorial has two major “lessons”, if you will. They are …<\/p>\n

    \n
  1. the Javascript setTimeout<\/i><\/a> (and setInterval<\/i><\/a>) parameter 1 function<\/i> parameters do not have to point to static Javascript functions … the parameter 1 can be dynamic in nature, or just known, as with today’s setTimeout(function(){ top.document.getElementById('nothingp').innerHTML+=eval(zero % 10); }, 500);<\/code><\/li>\n
  2. (we’ve done this many times before already, but just reiterating that) the same codeset (in today’s case HTML\/Javascript) can run a (several-)tiered scenario of application, as with today’s two-tiered arrangement of settf.html<\/i><\/a> (parent HTML) calling (child HTML) iframe<\/a> settf.html<\/i>?called=y … where the “child”<\/i> can know the “parent”<\/i>‘s document as top<\/i>.document … and in this way can control every dynamic aspect of the project<\/a>, if you wish<\/li>\n<\/ol>\n

    The first point above is pretty important, and we may revisit this with a more complex example later, because it means you can gain some knowledge as the web application process proceeds, and tailor how you run scheduled tasks as the information comes in, allowing for real time programming thoughts to be called into play.<\/p>\n

    So today we just have a “counter” being controlled by the user via a press of an HTML button<\/a> element, the “display” of which is in the “parent” realm, but the “onclick” logic of which is being processed by the child HTML iframe’s incarnation of your HTML code, that “slaps” the display back up to the parent via the use of top<\/i>.document (blah blah blah).<\/p>\n

    If this was interesting you may be interested in this<\/a> too.<\/p>\n