AutoIt3's future: Embedded ActiveX !

[this-is-me]

Please, don't give up sven. We all need this feature. The most important feature of this is to be able to access mediaplayer and iexplore objects inside of autoit. If yo scrap this altogether, then please at least create a few functions that will allow access to those objects and their methods and properties inside a gui window.

EDIT: when in doubt, ask JON directly instead of completely forgetting about the idea.

Edited May 14, 2005 by this-is-me

[sykes]

EDIT: when in doubt, ask JON directly instead of completely forgetting about the idea.

<{POST_SNAPBACK}>

I agree ... This sounds like too good of an idea to just scrap.

[SvenP]

Guys, guys,

Don't you recognize that I'm just testing you out ?? ;-)

(I know, I know, organizing a 'poll' was a better way to see if there will be enough interest in this new feature)

Today I have submitted the alpha (not even beta) 'ActiveX' code to the developers.

However I'm still busy fixing some (minor) bugs in the COM code. So I can't put all my time in the ActiveX code.

Be patient !

Meanwhile you might think about a name for this new feature. We had AutoIt-GUI for the GUI, AutoIt-COM for the COM extensions.

Let's say AutoIt-triple-X for ActiveX ? :-)

Regards,

-Sven

[this-is-me]

Wshew! That felt like a close one.

For names, how about ActiveAu3 or ActiveGUI?

[jpm]

That's too bad. I for one would like to see AutoIt become more than just a scripting language. Nowadays there just seems to be a thin line between scripting and programming. Oh well 

<{POST_SNAPBACK}>

I Think AUtoIT get an open door to do what is not inside.

This programming part will be reserved to very experience developper.

Some people think we can remove all Autoit functions to use the opendoor as dllcall and dllstruct.

From my experience when I enter the game of creating the Gui functions, I will take a lot of UDF to replace such function.

Definetly the scripting should stay for scripter and the opendoor for dev, 2 different class of users

[quaizywabbit]

I Think AUtoIT get an open door to do what is not inside.

This programming part will be reserved to very experience developper.

Some people think we can remove all Autoit functions to use the opendoor as dllcall and dllstruct.

From my experience when I enter the game of creating the Gui functions, I will take a lot of UDF to replace such function.

Definetly the scripting should stay for scripter and the opendoor for dev, 2 different class of users

<{POST_SNAPBACK}>

Amen!

[Helge]

I agree with jpm.

Of course it's fun to have all those great features, but we must prioritize here people !

AutoIt is automating. Not....eeeh..making.

As I've said before, AutoIt has already stepped over the line and isn't a 100%

automating-language anymore already.. AutoIt features about 90% automating

related functions, and 10% that's not really releated to automating at all.

Don't get me wrong, I'm using all the non-automating releated functions all the

time, because seriously... they are just awsome functions !

But there's a line, and we're reaching it pretty soon.

Btw, I was talking about the line that seperates programming and scripting.

Geez, I'm probably gonna be hanged now or something ... Peace !

-Helge-

I Think AUtoIT get an open door to do what is not inside.

This programming part will be reserved to very experience developper.

Some people think we can remove all Autoit functions to use the opendoor as dllcall and dllstruct.

From my experience when I enter the game of creating the Gui functions, I will take a lot of UDF to replace such function.

Definetly the scripting should stay for scripter and the opendoor for dev, 2 different class of users

<{POST_SNAPBACK}>

Edited May 15, 2005 by Helge

[this-is-me]

Just so everyone understands my point of view on this point, I see it this way:

AutoIt is an automation scripting language.

AutoIt Developers gave autoit a gui to allow easy acces from the user's standpoint to the underlying automation functions.

AutoIt Developers gave autoit a set of com functions to allow automation that is similar to vbscript and other scripting languages.

AutoIt Developers added DllStruct functions to allow more automation that is available in the main language.

AutoIt Developers in this case are adding another "user interface extension" to allow the user to more adequately control the underlying automation functions.

Therefore, In this case, I don't believe at all that this addition would hinder the main focus of autoit. I believe that users will make their own decisions as to whether or not this functionality should be used in their own projects. If this addition were to shift the main focus of every Developer of AutoIt to things other than automation, then I would think again about it.

Edit: spelling

Edited May 15, 2005 by this-is-me

[steveR]

Definetly the scripting should stay for scripter and the opendoor for dev, 2 different class of users

<{POST_SNAPBACK}>

I totally agree, they could have both,the scripting part of AutoIt for the inexperienced, and the more advanced features for the more experienced. We already have DllCall and COM. Adding ActiveX will make it more powerful and it will let the scripter learn as he goes along

[MSLx Fanboy]

I know that I'll be sticking to the current GUI functions, only because I want simplicity...but I do believe adding more features and functions to AutoIt help others automate more aspects of the Windows environment, without having to switch between languages, or have to use a library file.

Edit: Removed name suggestion, I'm slow/stupid...nevermind...

Support for the ActiveX and DLL versions of AutoIt.

Edited May 16, 2005 by MSLx Fanboy

[steveR]

Oh yeah Ill be using AutoIt Gui 99% of the time too, but I think about the 1000's of ActiveX components out there I could use. Has me drooling.

How about: AutoIt AX

Edited May 16, 2005 by steveR

[tuape]

Or AutoIt AXE ---> ActiveX Embedded

[steveR]

Or AutoIt AXE ---> ActiveX Embedded

Even better! AutoIt AX is too close to AutoItX anyway

[MHz]

Clarity is always best. AutoIt is a basic language. So ActiveX, should be ActiveX. Anything else, just distorts the new addition. AutoIt ActiveX

Bring on AutoIt ActiveX !!!

[this-is-me]

I still like ActiveAu3.

[quaizywabbit]

AutoIt Xtreme

[layer]

AutoIt Xtreme

<{POST_SNAPBACK}>

Haha, that sounds pretty cool

[Michel Claveau]

AutoIt-XP (activeX Portable)

[w0uter]

Clarity is always best. AutoIt is a basic language. So ActiveX, should be ActiveX. Anything else, just distorts the new addition. AutoIt ActiveX 

Bring on AutoIt ActiveX !!!

<{POST_SNAPBACK}>

gets my vote

but shouldnt we bug him more with continue'ing the project,

then thinking of a name ?

Edited May 17, 2005 by w0uter

[w0uter]

this fell of the page. i was wondering if this is actually coming?