JScript Event Handling questions
Mark Elston
in an application (non Web based) with the generous help of Andrew Nosenko
and Juri Zenkevich. Thanks for the help.
I am still a little perplexed by a few things, however.
I have found that, in order to get JScript to respond to events, I have to
follow the following set of step exactly or it won't work:
1. InitNew()
2. SetScriptState(SCRIPTSTATE_STARTED)
3. ParseScriptText()
4. SetScriptState(SCRIPTSTATE_CONNECTED)
Andrew has assured me that his code works without an explicit transition
to the STARTED state but I just cannot get it to work. This is annoying
because the act of calling ParseScriptText() may cause events to fire
that I would like to catch in my scripts. If this is the case I will have
to
put restrictions on the way scripts are written that may be unacceptable.
Also, I have seen that JScript does not go the the ScriptSite object
and do a GetItemInfo with the return mask set to SCRIPTINFO_ITYPEINFO.
Instead, it uses SCRIPTINFO_IUNKNOWN and appears to do a QI
on the returned object for IProvideClassInfo(2). It was only by supporting
this interface that I was able to get my script to respond to events.
This is different than VBScript which calls GetItemInfo with the return
mask set to SCRIPTINFO_ITYPEINFO. I know this because I have quite
a bit of TRACE output going to the debug window of my application and I
can see exactly what is happening.
I also am having problems when I try to use AddTypeLib. No matter what
I do this function call results in an access violation. This occurs in both
VBScript and JScript. I am not sure that I need it but I was trying to see
if
it would make a difference in the event handling by JScript. I don't know
what could cause VBScript and JScript to die with an access violation
as a result of calling this function.
If anyone can point me in the right direction here it would mean a lot.
Thanks for any help.
Mark
----------------------------------------------------------------------------
-----
Mark Elston
mel...@ard.advantest.com
John Crim
Mark Elston wrote in message <78a86h$o1k$1...@remarQ.com>...
>I have found that, in order to get JScript to respond to events, I have to
>follow the following set of step exactly or it won't work:
>
>1. InitNew()
>2. SetScriptState(SCRIPTSTATE_STARTED)
>3. ParseScriptText()
>4. SetScriptState(SCRIPTSTATE_CONNECTED)
>
>Andrew has assured me that his code works without an explicit transition
>to the STARTED state but I just cannot get it to work.
Try this sequence:
1. InitNew()
2. ParseScriptText()
3. SetScriptState(SCRIPTSTATE_CONNECTED)
If you do this, the script won't be executed until step 3, and no events
will be fired until step 3. But, perhaps I don't understand your problem.
>I also am having problems when I try to use AddTypeLib. No matter what
>I do this function call results in an access violation. This occurs in
both
>VBScript and JScript. I am not sure that I need it but I was trying to see
>if
>it would make a difference in the event handling by JScript. I don't know
>what could cause VBScript and JScript to die with an access violation
>as a result of calling this function.
This is a bug - it bit me also. You have to put an enum in your
typelibrary/IDL. If you don't it will access violate. Supposedly this will
be fixed in the next version of the script engines.
A related issue is: If you're using named constants that you want visible
within your script, use enum do define them, not const.
John Crim
WebGecko Software
jo...@webgecko.com
Mark Elston
>Mark Elston wrote in message <78a86h$o1k$1...@remarQ.com>...
>>I have found that, in order to get JScript to respond to events, I have to
>>follow the following set of step exactly or it won't work:
>>
>>1. InitNew()
>>2. SetScriptState(SCRIPTSTATE_STARTED)
>>3. ParseScriptText()
>>4. SetScriptState(SCRIPTSTATE_CONNECTED)
>>
>>Andrew has assured me that his code works without an explicit transition
>>to the STARTED state but I just cannot get it to work.
>
>Try this sequence:
>1. InitNew()
>2. ParseScriptText()
>3. SetScriptState(SCRIPTSTATE_CONNECTED)
>
>If you do this, the script won't be executed until step 3, and no events
>will be fired until step 3. But, perhaps I don't understand your problem.
That is what Andrew suggested but it doesn't seem to work. I tested it by
putting a call like
Application.DoSomething()
in my script which does execute. However, when DoSomething fires
off an event, it does not get handled by the handler in the script. In
fact, stepping through the code shows that there are no outgoing
connections on the Application object at this point.
However, after this first time through, the scripting engine *is*
connected and does sink events as it should.
I'll play with it some more and see if I can learn a bit more.
>
>>I also am having problems when I try to use AddTypeLib. No matter what
>>I do this function call results in an access violation. This occurs in
>both
>>VBScript and JScript. I am not sure that I need it but I was trying to
see
>>if
>>it would make a difference in the event handling by JScript. I don't know
>>what could cause VBScript and JScript to die with an access violation
>>as a result of calling this function.
>
>
>This is a bug - it bit me also. You have to put an enum in your
>typelibrary/IDL. If you don't it will access violate. Supposedly this
will
>be fixed in the next version of the script engines.
>
>A related issue is: If you're using named constants that you want visible
>within your script, use enum do define them, not const.
>
Thanks for the info. I was unaware of the requirement for an enum in the
IDL file. I'll try it out.
Andrew Nosenko
>>
That is what Andrew suggested but it doesn't seem to work. I tested it by
putting a call like
Application.DoSomething()
in my script which does execute. However, when DoSomething fires
off an event, it does not get handled by the handler in the script. In
fact, stepping through the code shows that there are no outgoing
connections on the Application object at this point.
However, after this first time through, the scripting engine *is*
connected and does sink events as it should.
I'll play with it some more and see if I can learn a bit more.
<<
Here is some thoughts on this.
Actually, you shouldn't expect events to be sunk until you bring the engine into
connected state.
Let's consider how IE works, as far as I may know and guess. JScript native
schema (<object>::<event>) binding doesn't work with IE, because IE doesn't
bring JScript engine into connected state at all. VBScript <object>_<event>
schema starts to work once page is downloaded completely (i.e., all
IActiveScriptParse::ParseScriptText calls are done, and VBs engine is brought
into connected state). But JScript <script for=[object] event=[event]> schema
works, as well as little known <object>.<event> schema ( e.g., function
document.onclick() {...} ). This is thankfully to special IBindEventHandler
(have a look at ActivScp.Idl) supported on IE objects (window, document, etc),
which is JScript engine knows and queries for.
IMHO, this is not a good idea to source events until all scripts get parsed. If
you have an initialization code to be executed once all scripts are loaded, just
put special event for this and source it after SCRIPTSTATE_CONNECTED transition
(much the same to what IE window::onload is). I use:
function Application::init() {
// put init script here
}
I think it's a good idea not to execute any code at all until all scripts get
parsed. I use SCRIPTTEXT_DELAYEXECUTION flag (that corresponds to <script defer>
IE tag). It's almost always possible to structure the code this way and do all
initialization tasks upon Application::init event. But if you really need to
sink some events before SCRIPTSTATE_CONNECTED state, consider IBindEventHandler.
Hope this helps, any comments on the above thinking would be appreciated. Btw,
I'm going to create a page devoted to Active Scripting at my ATL/AUX site, any
ideas/experience/code to share are welcome.
--
Regards,
Andrew Nosenko,
Mead & Company
Free ScriptX Control (Dynamic Event Binding, HTML Printing):
http://www.meadroid.com/scriptx/
ATL/AUX Library:
http://www.geocities.com/~andien/atlaux.htm
Mark Elston
Actually, with a little more investigation I found that I was wrong
about my statement below. It turns out that my tests were taking
place in the midst of some fairly substantial codebase changes and
I thought I was testing the recommended steps and wasn't. Having
taken a little more care about what I was doing I have found that
setting the engine to SCRIPTSTATE_CONNECTED prior to calling
ParseScriptText does, indeed, result in events being sunk as the
script is executing.
More comments inline.
Andrew Nosenko wrote in message ...
>Hi,
...
>Let's consider how IE works, as far as I may know and guess. JScript native
>schema (<object>::<event>) binding doesn't work with IE, because IE doesn't
>bring JScript engine into connected state at all. VBScript <object>_<event>
>schema starts to work once page is downloaded completely (i.e., all
>IActiveScriptParse::ParseScriptText calls are done, and VBs engine is
brought
>into connected state). But JScript <script for=[object] event=[event]>
schema
>works, as well as little known <object>.<event> schema ( e.g., function
>document.onclick() {...} ). This is thankfully to special IBindEventHandler
>(have a look at ActivScp.Idl) supported on IE objects (window, document,
etc),
>which is JScript engine knows and queries for.
>
I will have a look at the IBindEventHandler. I may not be able to use it
right now but it sounds interesting.
>IMHO, this is not a good idea to source events until all scripts get
parsed. If
>you have an initialization code to be executed once all scripts are loaded,
just
>put special event for this and source it after SCRIPTSTATE_CONNECTED
transition
>(much the same to what IE window::onload is). I use:
>
I would agree with this. However, the application I am writing is loading
the entire
script in a single shot. This is an artifact of how it is to be used.
We have a component that is controlling a piece of hardware. All
applications that
deal with this component must all be aware of the state of this hardware
(this is a
simplified explanation). Therefore, this component is accessed through a
systemwide
singleton. Some applications provide a GUI to allow interactive use of the
hardware
while others (such as the one I am working on) are to provide some form of
batch
type access. This application will allow the user to put the hardware in
specific
states by writing scripts to configure the component. Since some actions
must be
preceded by the completion of others the script must be able to respond to
events
in order to "know" when to proceed.
Therefore, we need to have the entire script loaded and parsed, then, when
the script
starts executing, it is to immediately start sinking events.
>function Application::init() {
> // put init script here
>}
>
>I think it's a good idea not to execute any code at all until all scripts
get
>parsed. I use SCRIPTTEXT_DELAYEXECUTION flag (that corresponds to <script
defer>
>IE tag). It's almost always possible to structure the code this way and do
all
>initialization tasks upon Application::init event. But if you really need
to
>sink some events before SCRIPTSTATE_CONNECTED state, consider
IBindEventHandler.
>
This (SCRIPTTEXT_DELAYEXECUTION) is a new flag to me. The documentation I
have
only mentions three flags: SCRIPTTEXT_ISEXPRESSION,
SCRIPTTEXT_ISPERSISTENT,
and SCRIPTTEXT_ISVISIBLE.
>
>Hope this helps, any comments on the above thinking would be appreciated.
Btw,
>I'm going to create a page devoted to Active Scripting at my ATL/AUX site,
any
>ideas/experience/code to share are welcome.
>
Thanks again. You have provided a great deal of insight. The problem is
now
very tractable. I am looking forward to checking out your scripting page.
Mark
Yury Zenkevich
As I recall, I sent you piece of my code which is actually loading typelib.
Check file UtilityObject.h/cpp and method IncludeLib. It does what you
asking
about - it loads TypeLib into script.
The only prob I found so far, it could fail if your TypeLib doesnt have
enums...
And I've heard about that somewhere els on the INet...
PS. Subproject, named FtpControl have registered his own TypeLib
information,
which is loaded from "debug/main.cpp" (JScript file, actually :) and It
works fine for me.
PPS. Im using latest JScrip engine, which supports try/catch, so maybe it
have
some fixes regarding this prob as well ...
YZ.
Yury Zenkevich
Andrew Nosenko wrote in message ...
>Hi,
>
>>>
>putting a call like
>
> Application.DoSomething()
>
>in my script which does execute. However, when DoSomething fires
>off an event, it does not get handled by the handler in the script. In
>fact, stepping through the code shows that there are no outgoing
>connections on the Application object at this point.
Thats right. There is no sync at this stage for the script.
The workaround for this Im using (the same as yours) is just to make
procedure in
script with name like "main()" (heh.. familiar?) and call it AFTER all
script engine initializations done. At this point all your objects could
easily fire events and do what they want ;}
YZ.
Eric Lippert (Microsoft Scripting Dev)
entirely my fault and (b) will be fixed in the next version, and (c) only
happens if the type library you add has no enumerations or constants.
AddTypeLib adds the constants and enumerations in a type library to the name
space -- so guess what all the test cases I threw at the problem had in
common? Yep, they all had constants and enumerations in them. Sorry about
that.
Eric
Mark Elston <mel...@ard.advantest.com> wrote in message
news:78a86h$o1k$1...@remarQ.com...
> I was able to solve the problem I had with getting JScript to handle
events
> in an application (non Web based) with the generous help of Andrew Nosenko
> and Juri Zenkevich. Thanks for the help.
>
> I am still a little perplexed by a few things, however.
>
> I have found that, in order to get JScript to respond to events, I have to
> follow the following set of step exactly or it won't work:
>
> 1. InitNew()
> 2. SetScriptState(SCRIPTSTATE_STARTED)
> 3. ParseScriptText()
> 4. SetScriptState(SCRIPTSTATE_CONNECTED)
>
> Andrew has assured me that his code works without an explicit transition
> to the STARTED state but I just cannot get it to work. This is annoying
> because the act of calling ParseScriptText() may cause events to fire
> that I would like to catch in my scripts. If this is the case I will have
> to
> put restrictions on the way scripts are written that may be unacceptable.
>
> Also, I have seen that JScript does not go the the ScriptSite object
> and do a GetItemInfo with the return mask set to SCRIPTINFO_ITYPEINFO.
> Instead, it uses SCRIPTINFO_IUNKNOWN and appears to do a QI
> on the returned object for IProvideClassInfo(2). It was only by
supporting
> this interface that I was able to get my script to respond to events.
>
> This is different than VBScript which calls GetItemInfo with the return
> mask set to SCRIPTINFO_ITYPEINFO. I know this because I have quite
> a bit of TRACE output going to the debug window of my application and I
> can see exactly what is happening.
>
> I also am having problems when I try to use AddTypeLib. No matter what
> I do this function call results in an access violation. This occurs in
both
> VBScript and JScript. I am not sure that I need it but I was trying to
see
> if
> it would make a difference in the event handling by JScript. I don't know
> what could cause VBScript and JScript to die with an access violation
> as a result of calling this function.
>