Re: ActiveX and RR

[K]

Does your implementation support *nix platforms?   


-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Tue 08/10, Mark Wieder < [EMAIL PROTECTED] > wrote:
From: Mark Wieder [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 10 Aug 2004 11:44:52 -0700
Subject: Re: ActiveX and RR

K-Tuesday, August 10, 2004, 4:41:47 AM, you wrote:K> I believe the 
focus on ActiveX is a bit short sighted once RRK> can make native OS calls 
(GetProcAddress, LoadLibrary ...) ActiveX,I did the LoadLibrary and 
GetProcAddress external calls some time ago,but without engine support they aren't 
that useful by themselves.-- -Mark Wieder [EMAIL 
PROTECTED]___use-revolution 
mailing list[EMAIL 
PROTECTED]http://lists.runrev.com/mailman/listinfo/use-revolution

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Mark Wieder]

K-

Tuesday, August 10, 2004, 4:41:47 AM, you wrote:

K> I believe the focus on ActiveX is a bit short sighted once RR
K> can make native OS calls (GetProcAddress, LoadLibrary ...) ActiveX,

I did the LoadLibrary and GetProcAddress external calls some time ago,
but without engine support they aren't that useful by themselves.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Mark Wieder]

Troy-

Tuesday, August 10, 2004, 8:19:26 AM, you wrote:

TR> I'm only interested in seeing Rev have the capacity to do even more
TR> than it can currently do. I really don't care what means that is 
TR> through, only that it shouldn't involve a C compiler. It should tap
TR> into some library of tools which is being continuously added to, and is
TR> designed for the average developer to tie into their projects.

Yes - this is exactly the point of a generic extensibility mechanism.

One analogy that comes to mind is music software, where VST plugins
and the like are supported by many different applications without the
users having to write a new connecting library for each new plugin.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[K]

This would allow the development of RR extensions that do not involve a C++ compiler 
or significant knowledge of C++.  I imagine this functioning like the Visual Basic 
Declare statement (only with a significant IDL)which allows Visual Basic to call WIN32 
without C++ knowledge.

Kevin


>Not being a Windows-based programmer, I'd have to ask - would doing
>this provide the every day user (not C programmer) a broad range of
>downloadable plug ins which they could use to extend Rev's
>capabilities?

>I'm only interested in seeing Rev have the capacity to do even more
>than it can currently do. I really don't care what means that is
>through, only that it shouldn't involve a C compiler. It should tap
>into some library of tools which is being continuously added to, and is
>designed for the average developer to tie into their projects.

-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Tue 08/10, Troy Rollins < [EMAIL PROTECTED] > wrote:
From: Troy Rollins [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 10 Aug 2004 11:19:26 -0400
Subject: Re: ActiveX and RR

On Aug 10, 2004, at 7:41 AM, K wrote:> I believe the focus on ActiveX is a 
bit short sighted once RR can make > native OS calls (GetProcAddress, LoadLibrary 
...) ActiveX, OLE, COM, > COM+, CORBA, ImageMagik, PVM are just steps 
away.Not being a Windows-based programmer, I'd have to ask - would doing 
this provide the every day user  (not C programmer) a broad range of 
downloadable plug ins which they could use to extend Rev's 
capabilities?I'm only interested in seeing Rev have the capacity to do 
even more than it can currently do. I really don't care what means that is 
through, only that it shouldn't involve a C compiler. It should tap into some 
library of tools which is being continuously added to, and is designed for the 
average developer to tie into their projects.--TroyRPSystems, 
Ltd.http://www.rpsystems.net___use-revolution
 mailing list[EMAIL PROTECTED]http://lists.runrev.com/mailman/listinfo/use-revolution

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[K]

Not all Java Virtual Machines are created equal!  A company I worked for shipped a 
product that required the SUN virtual machine (not the MSFT look alike).  The most 
significant compliant from Fortune 500 administrators/companies was the deployment of 
the Java Virtual Machine.

K


-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Tue 08/10, Troy Rollins < [EMAIL PROTECTED] > wrote:
From: Troy Rollins [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 10 Aug 2004 10:39:29 -0400
Subject: Re: ActiveX and RR

On Aug 10, 2004, at 7:41 AM, K wrote:>  As far as interfacing with Java I 
see no need to haul a 40+ MB > virtual machine around!Is there such a 
thing as a machine that doesn't have Java installed anymore?I guess I 
don't know, on OSX the latest VM is just part of the OS, and Java apps don't take 
any addition time to launch, and perform quite 
well.--TroyRPSystems, 
Ltd.http://www.rpsystems.net___use-revolution
 mailing list[EMAIL 
PROTECTED]http://lists.runrev.com/mailman/listinfo/use-revolution

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Troy Rollins]

On Aug 10, 2004, at 7:41 AM, K wrote:
I believe the focus on ActiveX is a bit short sighted once RR can make 
native OS calls (GetProcAddress, LoadLibrary ...) ActiveX, OLE, COM, 
COM+, CORBA, ImageMagik, PVM are just steps away.
Not being a Windows-based programmer, I'd have to ask - would doing 
this provide the every day user  (not C programmer) a broad range of 
downloadable plug ins which they could use to extend Rev's 
capabilities?

I'm only interested in seeing Rev have the capacity to do even more 
than it can currently do. I really don't care what means that is 
through, only that it shouldn't involve a C compiler. It should tap 
into some library of tools which is being continuously added to, and is 
designed for the average developer to tie into their projects.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Troy Rollins]

On Aug 10, 2004, at 7:41 AM, K wrote:
 As far as interfacing with Java I see no need to haul a 40+ MB 
virtual machine around!
Is there such a thing as a machine that doesn't have Java installed 
anymore?

I guess I don't know, on OSX the latest VM is just part of the OS, and 
Java apps don't take any addition time to launch, and perform quite 
well.

--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[K]

Oh, something important I forgot!  The Runtime Revolution "Stacks"/"Windows" must be a 
ActiveX container or provide a interface to be subclassed.  Otherwise ActiveX 
components (with graphics footprint) would not be viable. The RAD would also need to 
consider design time properties (a enormous job for just 1 platform). A IDL and 
APIHOOK declaration system would serve all platforms and allow the community to 
develope this without (platform specific) XCMD development.

Kevin


-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Tue 08/10, jbv < [EMAIL PROTECTED] > wrote:
From: jbv [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 10 Aug 2004 13:57:35 +0200
Subject: Re: ActiveX and RR

BTW I just recalled that among other projects I hada year ago, there was the 
implementation of 2D anti-aliased vector graphics using openGL.I had found 
plenty of opensource code that neededvery little adaptation.I remember 
starting to work on it, but pretty soon theimpossibility to extend the language 
made the wholeproject a source of headaches, and I finally dropped 
it...JB> K a *crit :>> > Kevin> >> > NOTE: I would 
appreciate if someone from RR would explain the design of the RR  low level functions 
so we (the users) can extend the language.>> Yep, agreed. that would be VERY 
nice.> BTW this is one of the 2 major reasons why I dropped> the developpement 
of an openGL library about a year> ago (the other one was lack of time).> But 
I have the feeling that being able to extend the language> would have made lack of 
time less important...>> JB>> 
 ___> use-revolution mailing list> [EMAIL PROTECTED]> 
http://lists.runrev.com/mailman/listinfo/use-revolution___use-revolution
 mailing list[EMAIL 
PROTECTED]http://lists.runrev.com/mailman/listinfo/use-revolution

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[jbv]

BTW I just recalled that among other projects I had
a year ago, there was the implementation of 2D anti-
aliased vector graphics using openGL.
I had found plenty of opensource code that needed
very little adaptation.
I remember starting to work on it, but pretty soon the
impossibility to extend the language made the whole
project a source of headaches, and I finally dropped it...

JB


> K a *crit :
>
> > Kevin
> >
> > NOTE: I would appreciate if someone from RR would explain the design of the RR  
> > low level functions so we (the users) can extend the language.
>
> Yep, agreed. that would be VERY nice.
> BTW this is one of the 2 major reasons why I dropped
> the developpement of an openGL library about a year
> ago (the other one was lack of time).
> But I have the feeling that being able to extend the language
> would have made lack of time less important...
>
> JB
>
> ___
> use-revolution mailing list
> [EMAIL PROTECTED]
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[jbv]

K a *crit :

> Kevin
>
> NOTE: I would appreciate if someone from RR would explain the design of the RR  low 
> level functions so we (the users) can extend the language.

Yep, agreed. that would be VERY nice.
BTW this is one of the 2 major reasons why I dropped
the developpement of an openGL library about a year
ago (the other one was lack of time).
But I have the feeling that being able to extend the language
would have made lack of time less important...

JB

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[K]

I believe the focus on ActiveX is a bit short sighted once RR can make native OS calls 
(GetProcAddress, LoadLibrary ...) ActiveX, OLE, COM, COM+, CORBA, ImageMagik, PVM are 
just steps away.  As far as interfacing with Java I see no need to haul a 40+ MB 
virtual machine around!  The major hurdle is RR would need to invoke each OS call 
"with messages" and provide a ASM stub for OS callbacks.  I provided this 
functionality in several languages I wrote (TIL based).  In my case I had a "run 
mutex" that controled the active "thread" anyone executing a reentrant code (code that 
did not require the intrepreter) would release the "run mutex" make the call and 
reaquire upon returning.  In fact all functions in the system that accessed the OS 
would do this.  Giving the appearence of multi-threading.  My languages actually 
interfaced with OLE, COM and DCOM (supporting ActiveX was not necessary).

Kevin

NOTE: I would appreciate if someone from RR would explain the design of the RR  low 
level functions so we (the users) can extend the language.



-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Mon 08/09, Richard Gaskin < [EMAIL PROTECTED] > wrote:
From: Richard Gaskin [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 09 Aug 2004 20:06:05 -0700
Subject: Re: ActiveX and RR

Mark Wieder wrote:> Richard-> > It's been years since I've used ToolBook, 
and I no longer remember the> syntax for doing these things, so I went and took a 
look at the new> web site:> > 
http://www.sumtotalsystems.com/toolbook/demos/flash/unsupported/unsupported.html> 
> So far I'm not impressed.I'm not suggesting anyone use ToolBook; Rev is 
smaller, faster, and even the Enterprise version costs less than half as much so 
there would be no need.My only point is that if we're going to explore 
ways to add optional type declarations to the language we don't need to reinvent 
that wheel.Extra bonus points:  if we use the long-established conventions 
ToolBook already has for this, it makes it that much easier for those users to 
switch to Rev if they're as impressed by the new owners as you are. ;)-- 
  Richard Gaskin  Fourth World Media Corporation  
__
 _  [EMAIL PROTECTED]   
http://www.FourthWorld.com___use-revolution
 mailing list[EMAIL 
PROTECTED]http://lists.runrev.com/mailman/listinfo/use-revolution

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Richard Gaskin]

Mark Wieder wrote:
Richard-
It's been years since I've used ToolBook, and I no longer remember the
syntax for doing these things, so I went and took a look at the new
web site:
http://www.sumtotalsystems.com/toolbook/demos/flash/unsupported/unsupported.html
So far I'm not impressed.
I'm not suggesting anyone use ToolBook; Rev is smaller, faster, and even 
the Enterprise version costs less than half as much so there would be no 
need.

My only point is that if we're going to explore ways to add optional 
type declarations to the language we don't need to reinvent that wheel.

Extra bonus points:  if we use the long-established conventions ToolBook 
already has for this, it makes it that much easier for those users to 
switch to Rev if they're as impressed by the new owners as you are. ;)

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Mark Wieder]

Richard-

It's been years since I've used ToolBook, and I no longer remember the
syntax for doing these things, so I went and took a look at the new
web site:

http://www.sumtotalsystems.com/toolbook/demos/flash/unsupported/unsupported.html

So far I'm not impressed.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Mark Wieder]

K-

Monday, August 9, 2004, 5:15:18 PM, you wrote:

K> Basically, RR needs is own Dispatch Driver and IConnectionPoint
K> external.  I would recomend however that RR developers implement a
K> GetProcAddress and LoadLibrary fuctionality (cross-platform).  This

Implementing LoadLibrary (even cross=platform) is very very easy. Even
implementing GetProcAddress (given a function name) is easy. The
problems start from there. GetProcAddress gives you a pointer - how to
deal with that in rev? You can store it in a variable, but how do you
turn it around and vector through it? That facility needs to be built
into the engine in order to use it.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Richard Gaskin]

Mark Wieder wrote:
I don't have a strong preference for the actual syntax of the
declaration statement. I *can* say that I'm not wild about having any
of the existing syntaxes tacked onto runrev, but I *am* used to using
them, as are other developers, so it may be worth putting in something
that feels comfortable to them.
I would stongly advocate using ToolBook's syntax.  To the best of my 
knowledge it remains the only xTalk capable of making direct system 
calls, and has done so for more than a decade.

Although it's been a few years since I worked with it I remember writing 
some routines that directly used the Win API for drawing shapes for a 
custom window and it was a snap.

TookBook changed hands again -- originally published by Asymetrix and 
then Click2Learn, it's now in the hands of Sum Total Systems -- a demo 
is available, which should include the docs:


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 Rev tools and more:  http://www.fourthworld.com/rev
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Troy Rollins]

On Aug 9, 2004, at 9:27 PM, Monte Goulding wrote:
I'm actually more interested in the prospect of a Rev - Java interface 
for a
few reasons:
 - an applet object would be a perfect way to integrate custom 
controls into
Rev
 - an external type interface for Java would allow us to leverage 
lot's of
Java code and also give us a very powerful combination for J2EE clients
 - a reasonable probablility that creations would be as cross-platform 
as
Rev
 - it's far more likely that RunRev would get support from the Sun 
crowd
than the Microsoft crowd
Monte, I think that is a really good idea. I'm no fan of ActiveX 
specifically, being a Mac-based developer, but I am a fan of gaining a 
lot of potential tools and a more opened-up platform with just one 
addition to Rev.

--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: ActiveX and RR

[Monte Goulding]

>As I've mentioned before, I think the mechanism for getting out of the
>RR sandbox (not necessarily ActiveX here) is a necessity for drawing
>in existing developers, at least in the Windows world. As an example,
>if I'm working as part of a larger team and one group has developed a
>middleware library in C that I'm supposed to interact with, I've got a
>limited number of choices right now. I will probably end up spawning
>an external library of functions in C as a shim between the two. I can
>see the questions coming from project management now: why do we need
>an extra layer of complexity? and if we have to write this layer in C
>anyway, why do we need runrev in here?

I'm actually more interested in the prospect of a Rev - Java interface for a
few reasons:
 - an applet object would be a perfect way to integrate custom controls into
Rev
 - an external type interface for Java would allow us to leverage lot's of
Java code and also give us a very powerful combination for J2EE clients
 - a reasonable probablility that creations would be as cross-platform as
Rev
 - it's far more likely that RunRev would get support from the Sun crowd
than the Microsoft crowd

Cheers

--
  Monte Goulding - [EMAIL PROTECTED]
  Sweat Technologies

  InstallGadget - How To Create An Installer In 10 Seconds
  http://www.sweattechnologies.com/InstallGadget

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Mark Wieder]

Chipp-

Monday, August 9, 2004, 2:56:46 PM, you wrote:

CW> 1) 'event trapping' or sending events back and forth across the RR boundary.

CW> 2) 'type marshalling' or converting RR strings to the appropriate 
CW> Windows API type.

These are exactly the two sticky points in creating a generic library
mechanism. It's not just ActiveX and not just (insert your own
favorite OS here)-style calls, either. I think what is necessary here
to deal with variable typing is something similar to the declaration
methods in RB or C or java - something that signals the engine that
when it comes across this external function it will need to pass a
32-bit integer or a string or whatever the function needs. Then we
need generic routines to do the argument casting.

I don't have a strong preference for the actual syntax of the
declaration statement. I *can* say that I'm not wild about having any
of the existing syntaxes tacked onto runrev, but I *am* used to using
them, as are other developers, so it may be worth putting in something
that feels comfortable to them.

CW> Interesting, in talking with Jerry Daniels and Chris about this, the
CW> very first question they had was "What do you want to do which isn't
CW> currently supported?" Ken Ray has offered some good suggestions 
CW> regarding existing ActiveX tables, grids and treeLists. But, to my
CW> knowledge, adding the full functionality of these ActiveX controls are
CW> difficult (if not impossible) both in RB and RR (and I assume Director
CW> as well).

CW> Lastly, for those who have gotten this far:-) and think of ActiveX
CW> support a 'have2have' feature, I am wondering...How much would you
CW> consider paying for it? Or would you expect it to be in the 'Enterprise'
CW> version of RR?

ActiveX is a mixed bag. My understanding is that OLE was rather
universally reviled by developers as being too arcane and hard to use,
so Microsoft renamed it ActiveX and more or less forced developers to
use it by dropping support for earlier technologies. That said,
ActiveX at least has a fairly good and well-documented discovery
process for the features it exposes.

As I've mentioned before, I think the mechanism for getting out of the
RR sandbox (not necessarily ActiveX here) is a necessity for drawing
in existing developers, at least in the Windows world. As an example,
if I'm working as part of a larger team and one group has developed a
middleware library in C that I'm supposed to interact with, I've got a
limited number of choices right now. I will probably end up spawning
an external library of functions in C as a shim between the two. I can
see the questions coming from project management now: why do we need
an extra layer of complexity? and if we have to write this layer in C
anyway, why do we need runrev in here?

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: ActiveX and RR

[K]

Basically, RR needs is own Dispatch Driver and IConnectionPoint external.  I would 
recomend however that RR developers implement a GetProcAddress and LoadLibrary 
fuctionality (cross-platform).  This will facilitate Win32 calls as well as glibc 
(CoCreateInsyance, CreateThread, CoMarshall, fork and many more) it would also 
increase the capibilities of the tool significantly.


NOTE: All COM and ActiveX interfaces are called via standard Win32 DLL.  Of course on 
*nix systems CORBA, PVM and many other libraries would finally be easily available.

Kevin




-==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=-
Disclaimer:

Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental. 
Any resemblance between the above and my own views is non-deterministic.

 The question of the existence of views in the absence of anyone to hold
them
is left as an exercise for the reader. The question of the existence of
the reader
 is left as an exercise for the second god coefficient. 
(A discussion of non-orthogonal, non-integral polytheism is beyond the
scope of this article.)



 --- On Mon 08/09, Chipp Walters < [EMAIL PROTECTED] > wrote:
From: Chipp Walters [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 09 Aug 2004 16:56:46 -0500
Subject: ActiveX and RR

Spent some talking with Chris today about ActiveX controls inside of 
RunRev.Some on the list here have posited the notion that RR can't be taken 
seriously as a tool until (among other things) it has ActiveX support. While 
this may indeed be true, it is worth examining what really *is* ActiveX support 
and how does a product like RB 'support' it?(Note: I expect this argument may 
also be true for Director, though I'm not positive. Perhaps Troy can shed some 
light).Regarding ActiveX (from Chris):1) He believes it's easy to add 
(in fact, we have a ActiveX instantiator in our XConnector code for Hemingway) 
with the following caveats:a) You would need to know the CLSID of the ActiveX 
control you wanted to add (this could probably be done inside of RR using a 
Registry browser function).b) You could display the ActiveX control/player 
easily on a cardc) You could set properties and call methods (assume 
 you know the correct syntax)All this is well and good...and in fact is 
how RB deals with them. The two major hard parts are:1) 'event trapping' 
or sending events back and forth across the RR boundary.2) 'type marshalling' 
or converting RR strings to the appropriate Windows API type.The first can 
be done thru custom code in an external or an engine modification. Type 
marshalling is a bit more difficult and would make sense to have an engine 
modification in order to do this properly. Things like pointer handles and arrays 
are most difficult. This would mean we would need some way to convert strings to 
variants. Plus, there's the whole issue of unicode which makes things even 
harder...Chris' opinion is that RB provides a subset of ActiveX support and 
doesn't handle the 'events' completely-- and that is why they have their 'own' 
grids, tables, etc and don't use standard ActiveX ones (I assume the
  same is true for Director and 'Xtras'). It is also the reason why altBrowser is 
a custom external and not just an instantiatiated ActiveX wrapper.So, to 
recap, it appears it would be fairly easy to have an 'ActiveX' wrapper external 
which could call ActiveX DLLs. But, the DLL it calls would not actually 'trap' 
events, but rather only have props set and methods called. How functional is this? 
Well, for one it could work as a player for different 'players' like Flash, IE, 
Acrobat,Excel, as long as you don't need callbacks...which is of limited use 
because most programmers want to 'get' the event messaging.In fact, if one 
peruses the RB list, you will find instances of users being able to 'call' to the 
Windows Media Player and start playing a video. But, to able to respond to the 
video via callbacks, etc, is not supported.Interesting, in talking with 
Jerry Daniels and Chris about this, the very first quest
 ion they had was "What do you want to do which isn't currently supported?" Ken 
Ray has offered some good suggestions regarding existing ActiveX tables, grids and 
treeLists. But, to my knowledge, adding the full functionality of these ActiveX 
controls are difficult (if not impossible) both in RB and RR (and I assume 
Director as well).Lastly, for those who have gotten this far:-) and think 
of ActiveX support a 'have2have' feature, I am wondering...How much would you 
consider paying for it? Or would you expect it to be in the 'Enterprise' 
version of 
RR?-Chipp___use-revolution 
mailing list[EMAIL 
PROTECTED]http://lists.runrev.com/mailman/listinfo/use-revolution

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___

Re: ActiveX and RR

[Chipp Walters]

Dar Scott wrote:
Many automation COM services do not need a control.  I realize that most 
folks want the control, but where I could have used this over the past 
couple years, I have not needed the control.
I agree, this actually would be the best case scenario for an
ActiveX/COM wrapper external.
The calls should be more straightforward.  The callbacks may be a 
problem and there may be a need to get across a thread boundary.  In 
looking at similar problems, I think the Revolution app may need to poll 
for the callbacks.
You are correct, this is the big hurdle.
I don't think this is as bad as it sounds.  The first step is to come up 
with the right mapping of types.  The pointers are known and are not 
arbitrary so a scheme can be set up for those.  The implementation step 
might be tedious but half can be done in transcript.
Certainly a naming convention could be setup where variable prefixes in
RR could be used to 'type' data on the other side. But, even then,
pointers referring to pointers still remains a problem... And arrays,
too (Arrays of arrays of arrays...I know I know...'Dar's Boxes!' :-)
Such a thing would have been handy for some DCOM work over the past 
couple years, but I don't know how much that might come up again.  I 
have toyed with the idea of a generic dll interface, but that has crash 
risks if the developer gets the interface wrong.
No doubt, making a crash proof version would be a challenge. In fact, a
main reason we haven't taken this on is primarily one of support.
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: ActiveX and RR

[Dar Scott]

On Aug 9, 2004, at 3:56 PM, Chipp Walters wrote:
Regarding ActiveX (from Chris):
1) He believes it's easy to add (in fact, we have a ActiveX 
instantiator in our XConnector code for Hemingway) with the following 
caveats:

a) You would need to know the CLSID of the ActiveX control you wanted 
to add (this could probably be done inside of RR using a Registry 
browser function).

b) You could display the ActiveX control/player easily on a card
Many automation COM services do not need a control.  I realize that 
most folks want the control, but where I could have used this over the 
past couple years, I have not needed the control.

c) You could set properties and call methods (assume you know the 
correct syntax)

All this is well and good...and in fact is how RB deals with them. The 
two major hard parts are:

1) 'event trapping' or sending events back and forth across the RR 
boundary.
The calls should be more straightforward.  The callbacks may be a 
problem and there may be a need to get across a thread boundary.  In 
looking at similar problems, I think the Revolution app may need to 
poll for the callbacks.

2) 'type marshalling' or converting RR strings to the appropriate 
Windows API type.

The first can be done thru custom code in an external or an engine 
modification. Type marshalling is a bit more difficult and would make 
sense to have an engine modification in order to do this properly. 
Things like pointer handles and arrays are most difficult. This would 
mean we would need some way to convert strings to variants.
I don't think this is as bad as it sounds.  The first step is to come 
up with the right mapping of types.  The pointers are known and are not 
arbitrary so a scheme can be set up for those.  The implementation step 
might be tedious but half can be done in transcript.

Plus, there's the whole issue of unicode which makes things even 
harder...
Well, Revolution does handle unicode values and for the first version 
it might be OK to assume ASCII.

Such a thing would have been handy for some DCOM work over the past 
couple years, but I don't know how much that might come up again.  I 
have toyed with the idea of a generic dll interface, but that has crash 
risks if the developer gets the interface wrong.

I have found COM to be tedious.  That might mean more work for whomever 
builds this, but it will mean less work (if done well) for others.

Dar Scott
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution