Prev: [ann] another way to call api's from script (the PB way)
Next: Multiple IF Conditions
From: vorpal on 3 Jul 2008 16:55
I can handle events fired by an object as follows:

set objTest=WScript.CreateObject("TheObject.TheFunction","objTest_")

Sub objTest_TheEvent
'The event handler code.
End Sub

The above works quite nicely.

I want to do the following:
Class WrapperClass

Sub Class_Initialize
set objTest=WScript.CreateObject("TheObject.TheFunction","objTest_")
End Sub

Sub objTest_TheEvent
'The event handler code.
End Sub

End Class

When I try the second way, the event handler is never called. If I
move it outside the class, it DOES get called, surprisingly enough,
even though the object is declared and initialized inside the class.

Is there any way I can modify this so that the event handler is a
class member?

Thanks,
--Vorpal
From: mr_unreliable on 4 Jul 2008 09:27
vorpal wrote:
> Is there any way I can modify this so that the event handler is a
> class member?
>

hi Vorpal, I don't think you are going to get a constructive
answer to this query.

I tried your modifying your code, and using "GetRef" to connect
your subroutine to an object's events. That didn't work either.

I suspect that the scripting engine is looking for a "global"
subroutine name to connect to, rather than looking for a sub
name in the "class namespace". I would consider this to be a
"bug", but since microsoft has given up on maintaining vbs,
reporting bugs is futile.

As an alternative, you might consider restructuring your class
code as a "windows script component" (a.k.a. a "wsc" file).
WSC's are similar to class code, but structured a bit differently.
More to the point, a wsc file DOES allow for sinking events.
Instead of CreateObject, you use an object tag:

<object id="oATO" progid="wshAPIToolkit.ucATO" events="True"
reference="yes" />

Some scripters have objected to wsc's, because they (mistakenly)
believed that you must register them before using them. This
is not necessarily so. You can also use a wsc by simply loading
it directly from a file. If you are interested in this approach,
then here is some code, showing how to do that:

--- <code> ---
' ================================================
' === INSTANTIATE AN UNREGISTERED WSC COMPONENT ==
' ================================================
' (Note: this technique was suggested by Mike Harris
' (mvp - scripting), see news://microsoft.public.scripting.vbscript,
' entitled: "wsf vs wsc", and timestamped: 2002-03-26 19:10:05 PST).
'
' suggested syntax:
'
' set obj = getobject("script:component path#component id")
'
' where component path can be:
' c:\mypath\mywsc.wsc
' _or_ \\server\share\mypath\mywsc.wsc
' _or_ http://server/mysite/mypath/mywsc.wsc
'
' and, #component id is optional.
' You get the 1st component in the WSC by default.
' You only need #component id if there is more than one in
' the WSC, and you want some other component than the first...
'
' A more exhaustive discussion can be found in the Windows
' Script Component documentation, at the bottom of the page
' entitled: "Using a Script Component in an Application"
' --- end of discussion --------------------------

Sub Instantiate_LocalWSC(oWSC, sComponentFileName, sEventPrefix)

' get the path to the local directory...
Dim sLocalDir : sLocalDir = GetLocalDirectory()
Dim sComponentPath : sComponentPath = sLocalDir & sComponentFileName
' MsgBox(sComponentPath)

' go get the (wsc) object...
' Set oWSC = WScript.GetObject("script:" & sComponentPath,, _
sEventPrefix)
' uh-oh. It appears that this approach only works with the
' VBS getobject and not the wscript.getobject flavor.
Set oWSC = GetObject("script:" & sComponentPath)

' (step two:) connect the events, (after making sure you need it)...
if (sEventPrefix <> "") then WScript.ConnectObject oWSC, sEventPrefix

End Sub ' Instantiate_LocalWSC
--- <code> ---

cheers, jw
____________________________________________________________

You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)

From: vorpal on 4 Jul 2008 11:23
On Jul 4, 6:27 am, mr_unreliable <kindlyReplyToNewsgr...(a)notmail.com>
wrote:
jw,
Thanks for the helpful, informative reply. I had tried wsc's but was
trying with "CreateObject". Now I know better.

My workaround for the other problem was to have a global sub call the
class member I really wanted to usr. This DOES work, but it breaks
encapsulation. Breaks it? Heck, it crushes it, but like I say, it
does work. Ugly, Ugly

I'll try the wsc approach for rev 2.0 This has the added advantage
that once created and working, I can just leave the class in a file
and the scripts that use it get leaner.

Thanks Again,
--Vorpal


> vorpal wrote:
> > Is there any way I can modify this so that the event handler is a
> > class member?
>
> hi Vorpal, I don't think you are going to get a constructive
> answer to this query.
>
> I tried your modifying your code, and using "GetRef" to connect
> your subroutine to an object's events.  That didn't work either.
>
> I suspect that the scripting engine is looking for a "global"
> subroutine name to connect to, rather than looking for a sub
> name in the "class namespace".  I would consider this to be a
> "bug", but since microsoft has given up on maintaining vbs,
> reporting bugs is futile.
>
> As an alternative, you might consider restructuring your class
> code as a "windows script component" (a.k.a. a "wsc" file).
> WSC's are similar to class code, but structured a bit differently.
> More to the point, a wsc file DOES allow for sinking events.
> Instead of CreateObject, you use an object tag:
>
> <object id="oATO" progid="wshAPIToolkit.ucATO" events="True"
> reference="yes" />
>
From: mr_unreliable on 5 Jul 2008 11:06
vorpal wrote:
> My workaround for the other problem was to have a global sub call the
> class member I really wanted to usr. This DOES work, but it breaks
> encapsulation. Breaks it? Heck, it crushes it, but like I say, it
> does work. Ugly, Ugly
>

Yes Vorpal, the life of a scripter is filled with disappointments.
vbs is somewhat limited in what it can do, and so you-don't-always-
get-what-you-want. Scripters must frequently resort to:
work-arounds, compromises, brute-force -- and yes --
just plain UGLY code...

Your only consolation is that your boss doesn't usually care
about ugly, as long as you meet your project completion target
date...

cheers, jw
 | 
Pages: 1
Prev: [ann] another way to call api's from script (the PB way)
Next: Multiple IF Conditions