POV-Ray : Newsgroups : povray.off-topic : All that Windoze stuff : Re: All that Windoze stuff Server Time
11 Oct 2024 15:20:53 EDT (-0400)
  Re: All that Windoze stuff  
From: Patrick Elliott
Date: 1 Nov 2007 01:05:13
Message: <MPG.2191c7f6ff09542f98a05e@news.povray.org>
In article <4727abda$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > (I guess it's kind of moot anyway. I don't have access to any 
> > programming language that supports COM. No, I classify VB as "joke" 
> > rather than "programming language"...)
> 
> Javascript running under Windows Scripting Host (and under IE with very
 
> low security settings) can use COM. PHP has a COM extension too, 
> although I have never tried it.
> 
It should be noted that support for COM in those does **not** include 
event management. That is only supported if you are running it IE, since 
it has all the fancy bits in it that allow you to call Invoke. This is 
apparently intentional, though I never quite got how knowing that you 
fracking clicked on a button is more dangerous than a COM object that 
tries to format your hard drive... I just don't get how disallowing 
events did anything but make it a pain to do anything (though it does 
work in IE, since IE supports an object event handler system, which lets 
you link your own script function to the event. Its why, if you look in 
the help for it, you will find that there are commands to both "link" an 
event (don't remember the name of that) and a "GetRef" command used to 
get the internal entry point to your script function, so that when the 
event happens that function will be called. But without IE's event 
manager, the linking command just generates a, "This command not 
available", type error. :p

Its basically a serious pain in the rear. You can get past it by 
introducing what is known as a ATL Bridge. Basically, ATL give more 
direct support to the functions that are "needed" to tell Event A to 
call your own code/script function. The problem is, the event cycle is a 
bit wacky. Basically, you click the button, for example, it generates a 
system level event, which is sent to your application, which is **then** 
supposed to be sent to the event handler that is keeping track of who to 
call when the event is received. Things like VB, MFC and Windows 
Scripting Host, all pretty much leave you hosed, since they either don't 
provide a way to *create* the needed link, or to even inform the object 
that it should generate the event. But in some like MFC, the "event" is 
not identified as one that belongs to your program, so is tossed back to 
the OS, to die in obscurity, instead of being passed on to any handler 
you "may" have. VB is a bit nicer, since you can trap arbitrary events 
(harder to do in MFC, and impossible in WSH), but since you can't talk 
to the core layer of the object to tell it that you "want" the event in 
the first place, it won't tell you that it happened, let alone allow 
your application to do anything about it.

Bloody mess...

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.