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

Posted

The problem is that the WinList function returns an array and marshaling arrays between languages is messy.

Share this post


Link to post
Share on other sites

Posted

I am very happy to see some development going on with AutoItX. Personally I try to use WSH functionality whenever possible. My main focus is on enhancing workflow and IPC scripting, less on administration and, naturally, I try to do automation tasks by application-internal COM whenever possible. I am in the process of creating a desktop function library based on WSH (using Python and JScript) and I am happy about any library, that makes my life easier. Just for the background.

I re-visited the AutoItX docs to find some function, that would allow me to read out the current desktop's screen-resolution, since I did not find one in the WSH object reference and it fealt to me, that this may be something AutoIt is capable of. I am still relativley new to AutoIt3. I found some macros in the main documentation:

@DesktopHeight  Height of the desktop screen in pixels.  (vertical resolution)
@DesktopWidth   Width of the desktop screen in pixels.  (horizontal resolution)

So, one thing, that I'd find interesting to see in a future version are the macros/constants of AutoIt3.

I am not yet sure, whether I can do this with AutoIt3, but if there is a possibility to change the screen resolution programmatically with it, that would be nice to have in AutoItX, too (I want to change reso for a certain user, who uses my computer with her own account, upon login and change it back upon logout (or place some script onto the desktop to invoke)).

Of course, I am aware, that a lot of functionality, AutoIt3 offers is being offered by different system and 3rd party COM objects and therefore not needed in AutoItX.

Nice introduction on COM in the main docs, btw.

Share this post


Link to post
Share on other sites

Posted

Hi Amix - I use WSH too - I enjoy using javascript as a scripting language (although it does lack metahooks for metaprogramming - but that is slated to be added in the next major revision and a clean macro system is being considered at some point) - with microsoft actively participating in the next minor revision of JS to be included with IE8 - that is WSH will be receiving a very cool jscript upgrade: 5.8) - i find jscript to be far more expressive than vbscript (i started learning them both at the same time - did a couple projects in both - and then settled with jscript because i found myself fighting with the language a lot less).

My domain is healthcare - and the solutions I come up with usually involve IPC too - i.e processing and merging data stored in excel and access - along with manipulating our patient information systems (some interface over citrix) to automate information extraction from the frontend - when backend access is forbidden.

The COM AutoIt dll has allowed me to accomplish many things - and I have created some JS abstractions that allow me to write code such as this:

var win = AutoItWrapper.getWindow("epic");

win.minimize();

var textbox = win.getControl(PATIENT_NUMBER_TEXTBOX_ID);

textbox.send("1234567");

(If someone is interested in this code or thinks the libraries might be worthwhile for WSH let me know and we can figure out the best way to share it with the community in an open source fashion)

Lately I have wanted the ability to install hooks into applications - this would allow some pretty cool automation - adding mouse hooks, keyboard hooks, message hooks, CBT hooks. AutoItCom does not provide such a capability. There does not seem to be much interest in one either. The autoit scripters can install systemwide (global) hooks - but these are expensive - and takes you away from using jscript/WSH.

I have recently coded a COM component in C++ using the incredible boost interprocess and threading library & microsoft's ATL that allows one to install any form of hook, supply a callback function which then receives all the relevant information in the form of a jsript object. It is one com dll - no separate dlls - and allows thread-specific and global hooks. The nice thing about this solution is that for all instances of the COM component that are instantiated (across processes even) - only one hook per window (or global) is installed - and there is only 1 dll which gets injected into each process. And technically all 15 hooks are available for hooking. So it is as performant and permissible as hooks of this nature can be.

Thus you can now write code as such:

win.addHook("WH_MOUSE", function(evt) { if (evt.x > 40) print("you double clicked - and x coord > 40"); }, "WM_MOUSEDBLCLICK");

// block a window from being created - this is slow since each hook has to wait for a response from our script which is quite expensive for a hook to do.

// but then performance is not king in the world of scripting - possibility of gluing a solution together is king

win.addHook("WH_CBT", function(evt) { if (getTitle(evt.hwnd) == "Patient SSN") return true; ); }, "WH_CREATEWND", { synchronize_response: true } );

Anyways - I would like to see this functionality in AutoIt Com too and would be willing to work with the developers of autoit to incorporate it into the dll if there is interest. I also think we shoudl be allowed to create context menus (windows/other controls) anywhere on the screen in response to certain events we are listening for - this is also not difficult to add to AutoItCom. Once again, if none of the other developers have time, I would be willing to add this functionality in if there is interest and the owner of AutoIt would be amenable to such a proposition.

You do mention that a lot of functionality in autoit is available in 3rd party com objects - do you have a list of these - i would be interested in checking them out too?

regards,

Faisal Vali

Radiation Oncology

Loyola

Share this post


Link to post
Share on other sites

Posted

Hello, I use AutoIt and AutoItX for a long time, and I've registered only because I saw this topic.

It will be very nice if we can have some function like "Execute" (like first reply said). In this way, I can crypt my script in executable, then I decrypt and call DLL to execute it, instead to convert/import all functions into my executable and execute one-by-one. (It will eliminate data types mismatch too, like ANSI and UNICODE).

It will be nice too if you remove the CRC check for the DLL, so then I can pack and crypt the DLL too, now I do a work around (I crack the DLL to not check the CRC).

There are any topic realet to AutoIt suggestions? I have some to the "executable" version too.

Thank you in advance

Share this post


Link to post
Share on other sites

Posted

I really would like to see the GUI Functions because the main reason that I am using AutoItX is to extend the use of

Game Maker (It can be found here). It allows the use of dlls

and it does NOT have built in GUI functions. I would also like to see all of the other AutoIt 3 functions put into the

dll. Thank you for such a great tool to program with Jon.

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




  • Recently Browsing   0 members

    No registered users viewing this page.