Sign in to follow this  
Followers 0

AutoItX Future

34 posts in this topic

Posted

AutoItX needs some love. I've neglected it for quite a while and the interfaces/methods aren't up to scratch. I'm probably going to reimplement the interfaces so for those who use it please chip in with any suggestions.

It will likely _not_ be backwardly compatible as some of the existing methods have really lame parameters.

Share this post


Link to post
Share on other sites



Posted

Might be a bit much for a suggestion but it would be nice to have the whole script engine available in autoitx.

Something like execute :P

for AU3_*GetHandle functions, which both dont return a value in c api, i'd sugesst returning a handle

or format the string to be reusable ([HANDLE:...])

Share this post


Link to post
Share on other sites

Posted

Hello Jon,

I saw this beggar on the side of the road today. He was holding a sign saying, "Need a WinList method". It looked like he had been standing out there for awhile; his hands were all gnarled and arthritic from writing all those EnumWindows callbacks. Poor guy. I threw him my two cents.

Also, would it be safe to assume that the interface reimplementation will provide a way to reference controls and windows using the bracket syntax?

Zach...

Share this post


Link to post
Share on other sites

Posted

Hello Jon,

I saw this beggar on the side of the road today. He was holding a sign saying, "Need a WinList method". It looked like he had been standing out there for awhile; his hands were all gnarled and arthritic from writing all those EnumWindows callbacks. Poor guy. I threw him my two cents.

Also, would it be safe to assume that the interface reimplementation will provide a way to reference controls and windows using the bracket syntax?

Zach...

LOL :P

The current version actually works with the same syntax as the full version of AutoIt. It's just not documented really.

Share this post


Link to post
Share on other sites

Posted

post-6470-1195865835_thumb.jpg

Hello Jon,

I saw this beggar on the side of the road today. He was holding a sign saying, "Need a WinList method". It looked like he had been standing out there for awhile; his hands were all gnarled and arthritic from writing all those EnumWindows callbacks. Poor guy. I threw him my two cents.

Also, would it be safe to assume that the interface reimplementation will provide a way to reference controls and windows using the bracket syntax?

Zach...

Was it this fellow?

Share this post


Link to post
Share on other sites

Posted (edited)

@Jon: All jesting aside, I believe a WinList method would be great. Thanks for the heads up on the syntax.

@Confuzzled: That looks like the guy across the street. He was trying to write a batch file wrapper for AutoIt.*

Zach...

* I will stop hijacking this thread now.

Edited by zfisherdrums

Share this post


Link to post
Share on other sites

Posted

AutoItX needs some love. I've neglected it for quite a while and the interfaces/methods aren't up to scratch. I'm probably going to reimplement the interfaces so for those who use it please chip in with any suggestions.

It will likely _not_ be backwardly compatible as some of the existing methods have really lame parameters.

Any chance to include Regular Expression support in AutoItX? Thanks!

Share this post


Link to post
Share on other sites

Posted

Any chance to include Regular Expression support in AutoItX? Thanks!

maybe I am asking this wrong here, because I don't know AutoItX abilities, but, can I register an AuitIT script to windows so if another program will do the following: ObjCreate ("Erez.Interface") can I create this object and register it to windows, and use method within it? so again if another program will call it:

like another AutoIT script:

$part4="hello world"

$oInter=ObjCreate ("Erez.Interface")

$oInter.Initialize(0)

$oInter.SendData($part4)

$oInter.Terminate()

can I write a script that when the other Script creates the object "Erez.Interface", I will Recieve the Initialize command and do stuff with the senddata command?

Share this post


Link to post
Share on other sites

Posted

For the DLL version, the use of strings for windows and controls can be annoying because it's not easy to pass proper HWNDs. eg:

AU3_API long WINAPI AU3_ControlClick(const char *szTitle, const char *szText, const char *szControl, const char *szButton, long nNumClicks, long nX, long nY);

Should I make WinGetHandle and ControlGetHandle the only functions to support strings and make all other functions take pure HWNDs? Or should a have an ...Ex() version of each function that takes alternative parameters?

Share this post


Link to post
Share on other sites

Posted

Should I make WinGetHandle and ControlGetHandle the only functions to support strings and make all other functions take pure HWNDs? Or should a have an ...Ex() version of each function that takes alternative parameters?

I don't think that making all the other functions take HWNDs would be that good of an idea. I'm not sure how it applies to everybody else, but for the automation that I do multiple windows are usually popping up so it is nice to do the automation in one call rather then having to call *GetHandle() for each new window. Having *Ex() versions might work, but I think it would clutter up the dll a lot.

As for suggestions, the ability to automate things like sliders, treeviews, and toolbars would be very nice.

Share this post


Link to post
Share on other sites

Posted

An ...Ex() style seems to make the most sense to me.

Share this post


Link to post
Share on other sites

Posted

any chance that it will be able to fire events, to be fully com compatible?

Share this post


Link to post
Share on other sites

Posted

AutoItX doesn't have any events to fire.

Share this post


Link to post
Share on other sites

Posted

Jon,

if you do decide to reimplement the DLL or even add new features I would be more than happy to create the matching Delphi wrapper to go along with the DLL. A lot of your autoITX users out there I think are Delphi users. I know there are other guys on this forum that have done a Java translation and a few other languages too. It would be cool to have them all in your distributable so developers don't have to come searching for them and know that they match the version of the DLL you are distributing. Just my two cents!

I am always available too.

Share this post


Link to post
Share on other sites

Posted

I would also like to see more of the features included in the dll.

Thanks for your work.

Regards,

John.

Share this post


Link to post
Share on other sites

Posted

In the latest beta version I've changed everything to full unicode. For COM this won't mean any difference to anyone. For the exported DLL version all the string parameters have changed to LPWSTR rather than char. This will cause some issues.

In theory, I could create ANSI versions of every function that converts ansi/unicode on the fly but it's quite a lot of work and I'm not sure it's worth it.

Share this post


Link to post
Share on other sites

Posted

When you release that new version I will update the C# declartions recently posted to use the new format.

Regards,

John.

Share this post


Link to post
Share on other sites

Posted

It's already been released. Just use the unicode function definitions.

Share this post


Link to post
Share on other sites

Posted

How about the Winlist feature?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0