AU4 Library

[JohnOne]

I mean the code and project linked.

[Alzri]

I saw the source without testing... it's really good.

For the moment, I'm only concerned with writing functions that work like AutoIt without inflict the performance.

Look at this one: https://github.com/Z-Rantom/AU4-Library/blob/master/AU4Lib/files.cpp

I've added this condition to au_FileFindNextFile function cuz the first file name should be returned from FindFirstFile in Windows API:

if (retValues.hFileName != L"")

which makes it run another test without the need of it (performance issue) except to make it behave like AutoIt

[Jos]

5 hours ago, Alzri said:

huh ! You shall consider your measure of seriousness !

Please don't... and use the forum standards. Hope that is not too much to ask.

Jos

[luger]

 

It looks like a nice project ..  I can not speak more. My English is not good..

[Guest]

I support this idea.
Keep up the good work

[jvanegmond]

I can't stomach going through three pages of "Can not"'s and "Must not"'s so I will skip that bit.

@OP, AutoIt developers are not mean and evil people who will never release source code. If you can build a working compiler for AutoIt3 with some example methods working (for example MsgBox, ConsoleWrite, Call, Eval, etc.) and good unit tests (run au3 scripts and check output) for all the weird syntax that is 90% of the work required to compile AutoIt3. The real work is not getting the C++ source code of the AutoIt functions, but getting AutoIt3 scripts compiled.

Not to send you home empty handed: Building compilers is hard. If you are going to build a compiler, don't start with AutoIt. First get good writing compilers. Only then pick one of the weirdest dynamic languages in the world to write a compiler for. 

PHP is very much like AutoIt in its dynamic capabilties. Facebook took a subset of PHP and built a compiler for it. It took hundreds of man-years of work and ultimately the project was superceded by a VM (as in, abstraction of a microprocessor).

[JohnOne]

On 08/03/2016 at 11:54 AM, jvanegmond said:

The real work is not getting the C++ source code of the AutoIt functions, but getting AutoIt3 scripts compiled.

I think you might be missing the point of this.

C++ code is everything, this is about converting AutoIt to C++.

[Alzri]

I guess JohnOne clarified things... thanks

I have not anything useful to say, just that there have been many updates since the first post (check first link). Updating pace is slow these days cuz having Physics 2 and Calculus 2 in one's life and finding time to write neat code is really hard.

Edited March 10, 2016 by Alzri

[Guest]

I would call it CU3 Library

C - C++
U - Part of Autoit name and reminder that it is Autoit
3 - Because it is 3 and not 4.

Edited March 10, 2016 by Guest

[JohnOne]

AU32C

[JohnOne]

It is a massive undertaking though, but one which will be immensely popular if it is completed.

GUI stuff will be most challenging thing I'd expect.

[Guest]

On 10.3.2016 at 1:07 PM, JohnOne said:

AU32C

Look like a nice password.

I do not like GNU. too much hard English to read .. I would prefer something simple to read like MIT.

Edited March 21, 2016 by Guest

[water]

No, too short and just uppercase letters and numbers.

[Alzri]

Updates (link in the first post):

-Updated project to VS2015 (with upd 1)
-Added "const" when passing refs
-Changed into vectors containers
-Fixed some bugs
-Added to-do list

I'd be thankful if you inform me about any unexpected behavior from any function.

[Guest]

Update: I use the name "CU3 Library" on github and I managed to implement few Autoit  GUI functions in C++.

I implemented the functions:
GUICreate
GUISetState
GUICtrlCreateButton
GUISetBkColor

https://github.com/GilEli1/CU3-Library/blob/master/gui.h

On 15.2.2016 at 4:01 AM, Alzri said:

OK... this is the very first step: writing AutoIt functions in a C++ library.

Another project is to write a tool (in any lang, even AutoIt) works as follow:

1) The user input an au3 file.

2) The tool (converter) starts to convert the AutoIt script: (AutoIt syntax to C++ syntax) and (AutoIt functions to correspondence C++ functions in this library).

we will end up with a main.cpp (our script in a new form) with some header files and cpp files (the library).

3) C++ compiler does its job to the converted script

4) Voila ! AutoIt script output file is not "scripty" anymore, it runs like a native app.

There is a big problem. In Autoit, variable can be any type.
But in C ++, you must specify the type. The problem is more difficult when it comes to Autoit 2D arrays to C++ objects / C++ 2D arrays.

Even if the convecter will work, it will give very bad code in a case that the user only click on the convert button.
The user needs to tell to the converter  lots of critical technical details and in case that the script is big, will be many..

And after all this the convecter must not make mistakes

 

Edited April 2, 2016 by Guest

[Alzri]

Good work @gil900 !

I'll check it later when I finish my exams... I had a glance at the code, here are my comments (they might not be accurate):

1) I think it's better to use the type wstring instead of an array char.

2) Since it's a big project, I think it's better to put all of AutoIt constants in separate files (I think using Enumeration here is a good idea).

3) We also shall focus on the main functions... how about this order:

(files, environment, registry, process,  network, string, window, mouse, GUI) ?

4) You may use passing values by reference (with the keyword const) instead of passing by value (to avoid unnecessary copies).

Quote

In Autoit, variable can be any type

Yep, that's gonna be painful to handle

Quote

The problem is more difficult when it comes to Autoit 2D arrays to C++ objects / C++ 2D arrays.

Surely, there are solutions; I guess using vectors is one them.

[Guest]

Quote

1) I think it's better to use the type wstring instead of an array char.

Thanks for the suggestion. I did not know any other simple option  char[]. What are the benefits in using wchar instead of char[] ?

Quote

2) Since it's a big project, I think it's better to put all of AutoIt constants in separate files (I think using Enumeration here is a good idea).

I agree. But if there constants that there usge is only under GUI stuff, I prefer to write then insid gui.h directly.

Quote

3) We also shall focus on the main functions... how about this order:

(files, environment, registry, process,  network, string, window, mouse, GUI) ?

No, my order is different. My order (priority) is determined by personal needs and what is considered to be fun to do for me..

Besides, the GUI is very important. It helps you to debug the software much more efficiently. I think few days to write the _ArrayDisplay function. First I need to  Implement the GUI functions that _ArrayDisplay use and then I will write _ArrayDisplay . It will not happen soon because I'm busy developing something more fun and interesting..

 

Quote

4) You may use passing values by reference (with the keyword const) instead of passing by value (to avoid unnecessary copies).

Not for Ints and small data
http://stackoverflow.com/questions/36165581/making-function-that-can-get-as-parameter-var-or-var

 

Quote

Yep, that's gonna be painful to handle

Painful? welcome to HELL and good luck because you need it.
I suggest you reinvent part of the Autoit syntax and in this syntax people will have to specify the type of the variable / function. people will not have to lern to much..

 

In fact, there is a way to do it without violate and change the autoit syntax.
You can make a rule of how the type need to be wrriten in the variable name. For example, int type must be wrriten as $intVariable , or $int_Variable ..
I think that this is the right direction to go with.  Based on the experience of others and based on logic.  

Edited April 8, 2016 by Guest

[Alzri]

Quote

What are the benefits in using wchar instead of char[] ?

In short, support unicode. But, to understand fully how it works, you should read the whole story; here are names of some good topics (google them):

"The Complete Guide to C++ Strings, Part I", "The Complete Guide to C++ Strings, Part II", "What are TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR (etc.)", and  "WinAPI: Being Unicode Friendly".

You also shall read about modernizing the code since using "new" and "delete" is nasty: "Using STL Strings at Win32 API Boundaries"

Quote

My order (priority) is determined by personal needs

Quote

Not for Ints and small data

Thx for the info.

Quote

I suggest you reinvent part of the Autoit syntax and in this syntax people will have to specify the type of the variable / function.

Let's forget about converting and focus on the library cuz writing a converter is just a matter of trial and error process (with having the right approaches ofc).

But for this particular subject, there is a way by finding the first assigning for the variable... the converter can take these steps:

1) find when a variable is declared.

2) find when the variable is assigned to a value (it might get the value from the return of a function so all prototypes must be loaded first to get their return value types).

3) get the type of that value.

4) If an assignment changes the type, this means we need a new variable with a new type.

[Guest]

Thanks for the info. I'll read it

 

Quote

Let's forget about converting and focus on the library

I agree.

 

Quote

But for this particular subject, there is a way by finding the first assigning for the variable

I thought about this idea. This is problematic.
My advice is this: If you go into hell, start simple.  then if it is working, make it better.
Simple is what I suggested .

Edited April 8, 2016 by Guest

[Alzri]

Updates:
- Implemented more functions.

- Many enhancements to the library.