1. ActiveX (was Win32Lib: making a "List Table"?)
> KAT wrote:
> I have ActiveX turned off in IE5 and i don't run active desktop. Both
> caused me more headaches then they are worth. Both have crashed the
> puter, destroyed files, rearranged my desktop, etc.. If David can call
> the same functions in win32lib that activeX calls, but in a way that
> won't be a microsoft pain in the a$$ like activeX, that would be useful
> as a simulation of activeX but without the problems. Just my opinion.
What activeX controls were blowing up your computer? Granted that active
desktop was buggy as heck when I first tried it (and I assume still is),
but I've never had those kinds of problems. (BTW, some of your symptoms
sound like they could have also been cured by telling IE to 'browse in a
separate process' using the control panel. This separates it from the OS
in case it does crash. I'd be interested in hearing more specifics on what
was giving you such troubles.
There are a couple of problems with waiting for David (or anybody else) to
wrap activeX. First, nobody has volunteered to do so, and that would be a
BIG project. Second of all, unless someone quits their day job, it won't
happen anytime soon. Third of all, it benefits RDS most of all (from a
monetary standpoint, anyhow), so it would seem that they should be the ones
responsible for doing the work, or contracting it out. Lastly, I love
win32lib, but it's just not extensible. How many 'hacked up' versions have
we either released with our code or send to David to convince him to
incorporate our changes? It makes no sence to perpetuate this cycle to
another technology. (Another argument for OOP!) An activeX wrapper would
be a HUGE pain in the butt if you had to write new routines for every
control, like we do now if we want to use richedit or listview controls in
win32lib. That's still re-inventing the wheel, just with an extra layer of
convoulution. And BTW, xEu (activeX Euphoria) wouldn't pose a risk to your
machine by itself. If you leave it alone, it would leave you alone...
and NICK wrote:
>I think what was actually meant was that ActiveX is trojan prone (often
>mistaken as virus), and that it is - it's dead easy to write an ActiveX
>trojan, then get a user to download it, and theres no way to know what it
>does until it's downloaded. However, trojan horse problems are not an issue
>within an App, as the author would use activex controls that do what they
>need them to do, not downloading an unknown one off the internet.
That was also my fault in not expounding on the issue. UNSIGNED activeX
controls ARE a huge security risk, but no reputable programmer would use an
unsigned activeX control anyhow, so it's really a non-starter. Just like
bound Eu programs, you better trust the author [flashback to NATEGATE]
Brian
3. Re: ActiveX (was Win32Lib: making a "List Table"?)
Brian Jackson wrote:
>There are a couple of problems with waiting for David (or anybody else) to
>wrap activeX. First, nobody has volunteered to do so, and that would be a
>BIG project. Second of all, unless someone quits their day job, it won't
>happen anytime soon. Third of all, it benefits RDS most of all (from a
>monetary standpoint, anyhow), so it would seem that they should be the ones
>responsible for doing the work, or contracting it out. Lastly, I love
>win32lib, but it's just not extensible. How many 'hacked up' versions have
>we either released with our code or send to David to convince him to
>incorporate our changes? It makes no sence to perpetuate this cycle to
>another technology. (Another argument for OOP!) An activeX wrapper would
>be a HUGE pain in the butt if you had to write new routines for every
>control, like we do now if we want to use richedit or listview controls in
>win32lib. That's still re-inventing the wheel, just with an extra layer of
>convoulution. And BTW, xEu (activeX Euphoria) wouldn't pose a risk to your
>machine by itself. If you leave it alone, it would leave you alone...
>
>
>and NICK wrote:
>
>>I think what was actually meant was that ActiveX is trojan prone (often
>>mistaken as virus), and that it is - it's dead easy to write an ActiveX
>>trojan, then get a user to download it, and theres no way to know what it
>>does until it's downloaded. However, trojan horse problems are not an issue
>>within an App, as the author would use activex controls that do what they
>>need them to do, not downloading an unknown one off the internet.
>
>That was also my fault in not expounding on the issue. UNSIGNED activeX
>controls ARE a huge security risk, but no reputable programmer would use an
>unsigned activeX control anyhow, so it's really a non-starter. Just like
>bound Eu programs, you better trust the author [flashback to NATEGATE]
>
>Brian
Brian,
Your points are well taken and not even close to a flame. This is the kind
of discussion we need to have on this list...or at least one of the kinds of
discussion we need to have..for those of you who could care less 
CORBA is a standards based competitor of COM and it's big brother DCOM
that are together one of MS end runs around any standard that they don't
control. JINI is a standards based service locator and mediator that can have
the functions of a universal plug and play for the software interface to
hardware
but can also be used for software services much like those provided by
plug-ins/ActiveX/java beans or even general applications served across
networks, both local and internet. JINI is directory based and is being
integrated with Novell NDS as well as MS Active Directory. JINI is
implemented in JAVA and has all the protections and cross-platform
capabilities that are therein implied.
Euphoria is certainly at a crossroads, and the direction that you would take
it would be towards straight MS Windows based commercial product status.
I don't believe that is a future that many on this list would care for. That
does
not mean that I don't wish for Euphoria to be able to compete in that arena...
just the opposite. I wish to see Euphoria grow as a cross-platform product
along the lines of the Linux version(even though I thought it was premature).
The major necessity to allow Eu to compete in the MS arena is a more
flexible and powerful calling convention that will allow us easy access to
the enormous library of C, C++, and other routines that we cannot now
easily access for one reason or another. Continuing to write wrapping
routines seems to be a huge waste of very good talent( using Eu to write
an automatic wrapping routine seems much more useful). I understand and
see the need for wrappers for the basic Win GUI interface, but I wish this
came from RDS with an option to use x-windows or motif on the back side
...meaning that where wrappers are written, I wish they were cross-platform.
For those who have denigrated JAVA, and who dislike Sun...well, you are
right on both accounts, but if I want to pick a standard to hook to, I would
far rather have JAVA than MS anything. Sun at it's worst is far more open
than MS and it appears that they are eventually going to get to a form of
open source on JAVA and JINI. Enterprise JAVA Beans are not entirely a
creation of Sun and appear to have stabilized some of the picture for JAVA.
Some very large players appear to have committed some large sums of
money and time around EJB development.
That doesn't mean that Eu should wrap JAVA anymore than it should wrap
anything else. Clean, flexible, powerful calling conventions supported by
structures powerful enough to map the external data behind the routines that
we need to call and namespace conventions clean enough to prevent
collisions between same name fields in multiple structures/includes should
allow the Eu programming community access to JAVA, JINI, CORBA,
ActiveX, Windows, x-windows, etc. ad infinitum.
Wrappers can then more easily be written to help doddering old programmer
types like me that are unwilling or unable to handle these new-fangled
interfaces in their native guise.
OOPs, I left out something. I'm not against it, as long as backwards
compatibility is largely maintained for us old procedural types..OOP...that is.
Everett L.(Rett) Williams
rett at gvtc.com
4. Re: ActiveX (was Win32Lib: making a "List Table"?)
> JINI is
> implemented in JAVA and has all the protections and cross-platform
> capabilities that are therein implied.
