Besides multithreading...

[Aktonius 2]

really consider as worth to mention limit of autoit?

[guinness 1,459]

Read this carefully please >> http://www.autoitscript.com/trac/autoit/wiki/AutoItNotOnToDoList

[Aktonius 2]

guinness i am not asking for it to be added. Just wonder when and why people feel limits.

[wraithdu 70]

Why are you interested in this information if not to build a list of requested features?

[guinness 1,459]

Sorry, but no where does it mention in your original post "I'm not asking this as a request to be added to AutoIt" so of course one can only presume this was a request.

Edit: I was wrong Aktonius wasn't insinuating a request as first thought.

Edited June 16, 2011 by guinness

[James 374]

Sorry, but no where does it mention in your original post "I'm not asking this as a request to be added to AutoIt" so of course one can only presume this was a request.

Because he never requested it.

In fact, it's quite clear that he is asking us what we really consider are the limitations of AutoIt.

For him, it's multi-threading. For me, it's the lack of closures and functionality I'm missing from other languages I use. He's not requesting it.

[Aktonius 2]

Thanks James, even id like to hear specifics.

Why are you interested in this information if not to build a list of requested features?

Just trying to learn my limits for tommorow and see how others feel with them.

[Valik 471]

The user is the limiting factor.

Anyway, thread intent was clear as James says. Read it again.

[guinness 1,459]

Sorry all! I somehow didn't see "what do you" so I broke the cardinal rule about assumption. Apologies Aktonius for my previous behaviour.

[Aktonius 2]

No worries

[LarryDalooza 37]

Probably the limited donations.

Lar.

[Chimaera 140]

The user is the limiting factor.

For the uninitiated isn't the limiting factor the geniuses who make autoit, its their limitations ( if they have any !! ) that determine how far autoit can be pushed, i know you lot are a right clever bunch, but surely the limitation will always stem from the creator (s).

Only an opinion...

Chimaera

[Mat 364]

For the uninitiated isn't the limiting factor the geniuses who make autoit, its their limitations ( if they have any !! ) that determine how far autoit can be pushed, i know you lot are a right clever bunch, but surely the limitation will always stem from the creator (s).

Only an opinion...

Chimaera

Valiks point is that AutoIt allows you to do anything. Maybe not natively (as in: standard AutoIt) but that's why they implemented DllCall. There's exampls of running machine code from AutoIt, so in theory you can do anything.

[Valik 471]

For the uninitiated isn't the limiting factor the geniuses who make autoit, its their limitations ( if they have any !! ) that determine how far autoit can be pushed, i know you lot are a right clever bunch, but surely the limitation will always stem from the creator (s).

Only an opinion...

Chimaera

Your inability to understand how to apply my response perfectly demonstrates why I made my response in the first place. Thanks for that. I guess. Edited June 16, 2011 by Valik
Typo.

[bogQ 89]

my brother say that he's not using autoit only because it dont have double precision that is needed for his math work. i personaly didn't try to find out if that's the case and is there a solution. for me and for work that i need it the most (automating windows based apps for connecting purpos between 2 apps), it dont have any limitations.

[JohnOne 1,589]

my brother say that he's not using autoit only because it dont have double precision that is needed for his math work. i personaly didn't try to find out if that's the case and is there a solution. for me and for work that i need it the most (automating windows based apps for connecting purpos between 2 apps), it dont have any limitations.

$double = 2455579.86455553782

MsgBox(0,0,VarGetType($double))

[Valik 471]

AutoIt supports the C++ double type as it's floating point type. If that is not precise enough then he should be using one of the more math-centric languages which he likely is.

[sleepydvdr 7]

To be honest, I misunderstood the OP's comment, too. But now I get it.

I have also wondered what the limits of AutoIt are (maybe a bit differently than the OP was asking, though). I look at the examples in the Example Scripts section to get ideas of how far AutoIt can go. I see some pretty advanced programs there, but to be honest, I haven't seen anything that can rival highly developed programs like 3D video games, Acronis, VirtualBox, Open Office, VMWare, etc. But AutoIt is still in it's infant stages. Considering it's not very old at all, it has come very far, very fast! I think it will be a household name someday.

[FuryCell 2]

For me the major limiting factor is that it is bound to Windows. I know AutoIt is not suited to other OS's but I fail to find anything that comes close to the perfect blend of simplicity and power on Android and other OSs. Granted there are some solutions on Linux but nothing feels as polished as AutoIt.

[FuryCell 2]

To be honest, I misunderstood the OP's comment, too. But now I get it.

I have also wondered what the limits of AutoIt are (maybe a bit differently than the OP was asking, though). I look at the examples in the Example Scripts section to get ideas of how far AutoIt can go. I see some pretty advanced programs there, but to be honest, I haven't seen anything that can rival highly developed programs like 3D video games, Acronis, VirtualBox, Open Office, VMWare, etc. But AutoIt is still in it's infant stages. Considering it's not very old at all, it has come very far, very fast! I think it will be a household name someday.

AutoIt is much better suited for small utilities. Currently writing large apps such as VMWare would be a nightmare due to AutoIts limitations (threading,speed,etc). With programming you either pick something like C++ or .Net which start off harder but scale well to large projects or something like Au3 which starts easy but can get difficult for larger projects.