Using Teng's datetimepicker in IE7 and Nitro PDF

[Paul E. Schoen]

I am trying to use a date/time picker script that is found on
http://www.javascriptkit.com/script/script2/tengcalendar.shtml.

It consists of a simple Demo.HTM file which also uses a cal.GIF and a
datetimepicker.JS. The HTML file will load in IE7 and Firefox, but in IE7
the calendar function shows an error on line 122 saying "access is denied".
Here are the lines from the JS:

(line 121) winCal=window.open("","DateTimePicker", "toolbar=0, status=0,
menubar=0, fullscreen=no, width=195, height=245, resizable=0,
top="+cnTop+", left="+cnLeft);
(line 122) docCal=winCal.document;

I ran the script using the Java Runtime of Arachnophilia and it stopped
with an error of java.class.NoClassDefFoundError: datetimepicker. But the
demo.htm runs OK on Firefox, and IE7 runs the on-line demo (although it
flagged an error once).

When I copied and pasted the JavaScript into the document-level of Nitro
PDF, I got an error on the line:

(line 62) exDateTime=document.getElementById(pCtrl).value;

saying getElementByID is not a function. So I changed it as follows:

(line 62) exDateTime=document.getField(pCtrl).value;

It said IIRC "document is not defined". I noticed that Nitro PDF uses doc
instead of document, but in the JavaScript I used to call the function, I
tried:

var document = doc;
NewCal('Text0','mmddyyyy');

and now it said doc is not defined.

Then I tried to see if I could run the two supposedly equivalent statements
as shown below, but apparently "this" works but not "doc". So I set
document = this:

var v1 = this.getField("Text1");
//var v2 = doc.fieldName("Text1") // doc gives an error not defined
var document = this; // Allows script to execute line 62
NewCal('Text0','mmddyyyy'); // Call function in document level JS

But now I get an error on line 121:

winCal=window.open(...

saying "window" is not defined. I think "window" is not a supported object
in Nitro PDF. So, I suppose I am stuck? Maybe I should try Adobe Pro? Or am
I doing something wrong? Thanks,

Paul

 

[Paul E. Schoen]

^^^^^^^^^^^
It is never a good idea to attempt to make a browser window
non-resizable.

This was in the cut-and-paste script, but I agree.

There are (at least) three good reasons the above not working. The fist
is that the first parameter of the window's - open - method, which is the
URL. Your argument is the empty string,

Yes, this does produce the about:blank window, when it works.

The second problem is the third argument to the - open - method, which is
supposed to be a comma separated list of name/value pairs (or just names
in some cases). Your list is comma-space separated, and while some
browsers may tolerate that some do not.

I added the spaces only to make it easier to read in my post. But I did not
realize that whitespace could be a problem, so that is good to know.

The third problem is the timing of the access to the new window's -
document - property.

That may very well be the reason it works using IE7 on the demo web page,
but not locally.

Do you mean IE 7 flagged one error each time the script loaded, or one
error across multiple loads (the latter would be a symptom of the
consequences of timing issues in the loading of the "about:blank"
document).

Yes, it was intermittent, so I agree that timing was most likely the issue,

The - getElementById - is a DOM method, does Nitro provide a DOM?

It provides a limited DOM. But apparently the help documentation is wrong.
For instance it says:

Example:
this.getField("fieldname");
would be the same as:
doc.fieldName("fieldname");

But actually they use the more usual "document" object, and the following
works:

document.getField("fieldname");

So there were two errors that confused me. Perhaps Nitro PDF is too flaky
to consider, and may not be a bargain at $99 compared to about $300-$500
for Adobe 9 Pro. I'll probably have to visit the forums and discuss my
problems there. I don't think my confusion is with JavaScript itself
(although I have much to learn), but more about the differences of the PDF
environment compared to HTML and WSH.

That would not be surprising, and even if it were what would any - open -
method it may have be expected to do?

Ideally it would create a window, or form, that would support other
properties and methods such as those available in a browser environment.
The datetimepicker.js script apparently writes HTML to the window.document
using writeln() methods and then these are interpreted by the browser to
render the calendar with appropriate rows and columns.

No, if you are using a browser object model script it is a browser
environment that you should be using it in.


You appear to have gone around in some unusual/unexpected circles here.

It is probably unusual to discuss the WSH and JS environments. Probably
most of the discussions here are for browser-based applications. This all
started from trying to implement a date and time picker for a PDF form, and
I was at least able to get a way to insert today's date with an offset. And
I think I have seen PDFs with this feature, but maybe they were written in
Acrobat Pro. It is also supplied by default in Access 2007, which may
really be the appropriate application for this. But the advantage of an
editable PDF is that it can be distributed and used by those who have the
free Reader, rather than the rather pricy Access.

Thanks for all the help, and sorry for the newbie confusion.

Paul

 

[Thomas 'PointedEars' Lahn]

(line 121) winCal=window.open("","DateTimePicker", "toolbar=0,
status=0, menubar=0, fullscreen=no, width=195, height=245,
resizable=0, top="+cnTop+", left="+cnLeft); [...]
(line 122) docCal=winCal.document;

There are (at least) three good reasons the above not working. The fist
is that the first parameter of the window's - open - method, which is
the URL. Your argument is the empty string, which could be interpreted
as the URL of the top of the current page, but is more likely to
interpreted as the "about:blank" URL.

AFAICS, only superficially. While the location bar displays `about:blank'
in some instances, indeed (Opera being an exception, for example),
`document.domain' of the new window remains that of its opener (as expected;
the empty string denotes a same-document URI-reference). Tested in:

- "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212
Iceweasel/3.0.11 (Debian-3.0.11-1)"
(Firefox 3.0.11 for Debian GNU/Linux)

- "Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.14eol) Gecko/20070505
Iceape/1.0.9 (Debian-1.0.13~pre080614i-0etch1)"
(SeaMonkey 1.0.9 for Debian GNU/Linux)

- "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
- "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"
- "Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)"
(Standalone IEs on wine-1.0.1-174-gc4039bd)

- "Opera/9.64 (X11; Linux i686; U; en) Presto/2.1.1"
(Opera 9.64 for Debian 5.0 [Lenny] GNU/Linux, .deb)

Cross-domain scripting issues may then enter into the picture as whatever
protocol your test HTML is using it is unlikely to be the "about:" protocol.

Because of the above, cross-domain scripting issues are unlikely (AFAICs,
only Konqueror 3.5.9 has them, but then again it is seriously borken
in other places as well). Indeed, one can call winCal.document.open(),
winCal.document.write(), winCal.document.close(),
winCal.document.body.appendChild(), and one can access
winCal.document.body.innerHTML, successfully.

I would have been surprised if it was different, as dynamically written
popup documents are not that uncommon. I, for one, have used them since
1999 CE to generate popup documents that show enlarged versions of clicked
images -- with proper no-script alternative, of course. See, e.g., the
"Terra" entry in <http://PointedEars.de/ufpdb/>. (Yes, I know that the
online version of the generator still has bugs; look at it as a proof of
concept.)


PointedEars

 

[Michael J. Ryan]

It is never a good idea to attempt to make a browser window
non-resizable. There are only two possibilities when opening new
windows; you either open the window the correct size for the user, in
which case they won't attempt to re-size it so it doesn't matter that
whether they could or not, or you open it at an inconvenient size for
the user and they then need to re-size it. All you can do with this
setting is prevent some users from being able to mitigate your mistakes.

Funny you mention this, since I've started using my Eee for about 8 months
now, and even more noticable on me G1, I'm really getting sick of in-window
modals that don't test for the viewport size.. Half the time i have to go
into F11 mode to get to the buttons... The other half I have to tab and
guess, heaven help me if it's in flash.

I'm even pretty good with it, I only have one dock/toolbar at around 27px, and
set the navigation in FF to be on the same line as the menu (wish I could
shrink it, ala ie7-8).

</rant>