Autoit and the serious (comercial) project

[FuryCell]

The way I would put it is the following.

AutoIt is a screwdriver.

C# is a hammer.

Now its up to the developer to figure out whether their project is a screw or a nail.

The bottom line is use the best tool for the job. Both have their strengths and weakness.

Edited June 10, 2010 by FuryCell

[Shafayat]

then FuryCell, all our autoit projects should have been Screwed ?

This is awesome philosophy

[JRowe]

I don't think it's that linear. AutoIt and C# are both applicable to many of the same types of projects.

For two developers, one well-versed in AutoIt and the other in C#, I'd imagine the time to create an application completely from scratch (no foreknowledge of the algorithms or system being designed) would favor AutoIt. Performance would most likely favor C#, size would favor AutoIt. AutoIt would also have the best chance of "just working" on any given (Windows) system.

The point isn't that AutoIt is the greatest language ever, or the most efficient and fastest application platform. It's not. It's that AutoIt has the tools, libraries, and documentation to enable a developer to whip something out quickly that's reasonably comparable to a similar program in another language.

[Richard Robertson]

"Just working"? As long as you stick to the .Net framework's precompiled libraries (1st party) it will work the same on any system unless documented otherwise.

[JRowe]

You still have to install .Net on those systems that don't have it, whereas you can distribute au3 apps standalone. I know that there are ways of bundling .Net and distributing your app as a standalone, but you've got a whole lot of hoops to jump through, compared to pressing Ctrl+F7 and having your app right there, ready to rumble. It's not a big deal, but I consider it one of the little things that makes AutoIt pleasant to use. You don't have to spend hours configuring (or learning to configure) your project deployment settings.

[SmOke_N]

"Just working"? As long as you stick to the .Net framework's precompiled libraries (1st party) it will work the same on any system unless documented otherwise.

I remember a couple of/few years ago you were working on an AutoIt .NET language implementation.

Did you ever finish that?

[FuryCell]

then FuryCell, all our autoit projects should have been Screwed ?

This is awesome philosophy

Replace screwdriver with wrench and screw with bolt if that makes you happy.

[Richard Robertson]

I remember a couple of/few years ago you were working on an AutoIt .NET language implementation.

Did you ever finish that?

I pick it back up when I think about it. I've actually moved to a secondary project which will make compiling the AutoIt directly to a .Net assembly a million times easier, as well as any other language I tackle.

[czardas]

I've hammered in nails with the handle of a screwdriver before now. Though I think one of the neatest ticks is using a tree stump to remove an axe embedded in a log. Just make sure there's nobody standing behind you at the time, and that the log doesn't land on your head.

Edited June 11, 2010 by czardas

[jchd]

I've hammered in nails with the handle of a screwdriver before now.

Do you mean you've already written device drivers in APL or a CRM suite directly in hex machine code?

Though I think one of the neatest ticks is using a tree stump to remove an axe embedded in a log. Just make sure there's nobody standing behind you at the time, and that the log doesn't land on your head.

Hey, don't forget monitoring carefully the axe travelling curve either!

[czardas]

Do you mean you've already written device drivers in APL or a CRM suite directly in hex machine code?

Nope, I just used some nails to replace some pins on my hard drive so I could attach it to the power cable. It didn't work.

Hey, don't forget monitoring carefully the axe travelling curve either!

How could I forget.

Also don't forget to rotate the axe during the swing so that the log splits itself with it's own weight. The best thing would be to avoid getting the axe trapped in the log in the first place. If the axe suddenly seems much lighter during the upswing, then the log just went flying.

Now back to the topic. =>

Edited June 12, 2010 by czardas

[czardas]

I think that producing commercial products made with AutoIt should be encouraged. Personally I would like to contribute more to the forum and Dev team, but my income from music is far from steady ATM. I don't think it is necessary to be an expert in programming to come up with a viable product. There are plenty of willing gurus to help with the code. Perhaps a small percent of the profits from your program could go towards maintenance of the AutoIt website and buy a few beers for the Devs. I'm pretty sure that such an outcome would be welcomed.

Edited June 12, 2010 by czardas

[janneman]

My main reason for using AutoIt is that it's a good compromise between a compiled program and a script. I work for a software company and I often need to provide little "semi-supported" tools to paper over some of cracks in the product or go the extra mile in unusual situations. I want to give out source so people can support themselves. If I write my tool in a "serious" language like C++, there is little point in releasing source because my average user is not a serious programmer. Vbscript is something that my average user would be more comfortable with, but the convenience of a compiled program is what made me an AutoIt convert.

[E1M1]

I prefer 1 line autoit (Send()) to 50+ lines C++ or 10+ line C#.

If you leave multithreading and compiling your code as DLL out, Is there anything C# can do and Autoit can't? C# has many built in funcs, autoit has also many funcs + udfs. Autoit can do Dll calls which means you can use lots of funcs from windows own dlls. I once saw topic about autoit loops in example scripts where was asm used inside Autoit (correct me if i am wrong) to make loops faster.

[Richard Robertson]

C# works on multiple platforms.

[Mat]

C# has all kinds of things... Not least the class structure which I often find myself missing when using AutoIt. It has a lot more controls, and wpf is pretty awesome, especially at doing menus. A lot of the advantages come from the fact that its oo, which is amazing on its own, and most of the others are because it's got visual studio - Although I love Koda it is clearly beaten by a mile by the vs editor. Resources are so easy to use it's unbelievable that we have to fiddle with reshacker all the time...

AutoIt has it's advantages though... It's interpreted, standalone, supports hotkeys, smaller community so the devs are right here, easier to use winapi (C# isn't bad though) and much much easier to manipulate external windows... Trying it in C# is stupid, you end up calling all the dll functions like you would in AutoIt, only with more lines of code.

Mat

[E1M1]

Cow to do pixcel search and pixcel get color in C#. I've googled it and then found 70 lines long code to find pixcel from picture. Wondering how autoit is doing that. Does it take screenshot and search from there or does it get data directly from screen?

It might be stupid question but what is diference between function and class? Visually both looks same. And why are objects good? I can't understand it. Why I should use Settings.Password = abc if I could use SettingsPassword = abc or just Password = abc.

Could anyone explain that?

[Mat]

Ok, heres a good example. You want to have a collection of reminders. No idea if this works, I'm having trouble registering my visual studio. You should get the idea of how properties and classes are very useful. Doing the same thing in AutoIt is multi-dimensional global arrays, and you need to remember what indexes mean what...

expandcollapse popup

namespace MyProg
{
    class Program
    {
        static void Main(string[] args)
        {
            Reminder[] AllReminders = new Reminder[]
            {
                new Reminder("1", "This is the first reminder", DateTime.Now),
                new Reminder("2", "Another reminder", DateTime.Now)
            }
            
            while (true)
            {
                foreach (Reminder rem In AllReminders)
                {
                    If (rem.Check())
                    {
                        Console.WriteLine("Reminder (" + rem.Date.ToString() + "): " + rem.Name + ", " + rem.Message);
                    }
                }
            }
        }
    }
    
    class Reminder
    {
        // Constructor
        public Reminder(String sName, String sMessage, DateTime dtDate)
        {
            this.Name = sName;
            this.Message = sMessage;
            this.Date = dtDate;
        }
    
        // Properties
        public DateTime Date;
        public string Name;
        public string Message;
        
        // Methods
        public bool Check()
        {
            return (DateTime.Now == Date);
        }
    }
}

[Richard Robertson]

Mat, your code would never work because the chance you'll get the exact tick count on any given loop is too small.

[Mat]

Mat, your code would never work because the chance you'll get the exact tick count on any given loop is too small.

I thought there would be something wrong with it... It's hard to write code without an IDE and compiler. But the theory's all there.