In comp.lang.javascript message <67023a25-650b-454f-a915-ebeae30ccf6e@f1
1g2000yql.googlegroups.com>, Tue, 10 Jan 2012 17:04:55, "Michael Haufe
(TNO)" <
t...@thenewobjective.com> posted:
>On Jan 10, 3:40 pm, Dr J R Stockton <
J.R.Stock...@physics.org> wrote:
>
>> Rather easy. Essentially, the HTA has a button and a textarea. The
>> existing JScript for WSH is modified so that the code is just
>> declarations of globals and functions, followed by a call of the main
>> function :-
>>
>> if (typeof window == "undefined") SEAKFYLE()
>>
>> In CScript, that call calls, and all still works as before; in HTA,
>> that call does not call, but the button does it instead.
>>
>> The HTA "include"s SEAKFYLE.JS, and also contains script
>>
>> Fawm = document.forms[0]
>>
>> SEAKFYLE.JS uses the value of Fawm to write to the textarea, and the
>> truth of Fawm for minor code changes, such as reading the command line
>> from an "<input type=text" in the HTA.
>>
>> <
http://www.merlyn.demon.co.uk/programs/32-bit/seakfyle.htm>
>> <
http://www.merlyn.demon.co.uk/programs/32-bit/seakfyle.js>
>> <
http://www.merlyn.demon.co.uk/programs/32-bit/seek.hta>
>
>Note that HTML Applications can take command like arguments as well by
>using windows.dialogArguments
That's well worth knowing. I could use that to pre-load the input line;
and I can add an option, command-line only, to auto-start after pre-
load. ... Except that neither windows nor window.dialogArguments appears
to exist. ... Needs <hta:application ID="oHTA" and then
alert(oHTA.commandLine) shows the command line.
I think that, in HTA mode, no path of execution should now lead to a
WScript. Because of the heritage of the "design" of the code, detected
errors lead to a chain of function calls used as GOTOs, since they ended
up in the original Pascal with a Halt(N) call. In WSH, WScript.Quit(N)
does the same. I'd like to use something similar in HTA mode; but the
only way of stopping that I know is to exit all routines and fall off
the end of the script, which would be tiresome to arrange.
That problem is now circumvented.
I prefer to change such defaults as little as possible. I'd have to
remember to do it on other machines, and other users would also need to
do it. There could be other *.js files needing to run in WScript. But
I've added the possibility to the description.
I'm using WScript.Arguments already.
It is rather too much changed from a version that I no longer have to
import, or to be easy to follow.
Having seen it working, aesthetics demand that the textarea is sized to
fill the rest of the form, and the form is sized to only nearly reach
the bottom of the viewport. But @FrmMain margin-bottom: 5px; does
that.
Resizing then is nice, or will be once I've trapped the error that
occurs when the bottom is dragged up too far. This does it :
TA.style.height = Math.max(0, TA.parentNode.offsetHeight - 10) + "px";
The <H3> wastes height !! I'll stick with <big> or equivalent.
The ROWS control seems not to work; but it has no useful function with
auto-resizing. Removed.
The SEEK button failed, because of its re-naming, fixed.
I was somewhat surprised that Fawm = document.forms[0]; in the HEAD
works when the actual form is in the body.
There is at present one remaining infelicity: the heading (and other)
text, when wrapped because of Zoom or narrowing the window, wraps under
the following element. That's now mitigated by shortening the heading
line.
If IE gets Zoom Text Only, I suppose the vertical sizing will have to be
redone in ex or em units.
The version uploaded at about 23:40 GMT, dated 2012-01-12, includes all
this. More thanks.
--
(c) John Stockton, nr London, UK. ?@
merlyn.demon.co.uk Turnpike 6.05 WinXP.
Web <
http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:
http://www.merlyn.demon.co.uk/pc-links.htm>.