Search the Community
Showing results for tags 'modularity'.
-
Plys (/ˈplaɪz/) represents the inconspicuous wrapper which complements the AutoIt language with preprocessor keyword #import "filename" loads only public functions and variables Python-like code blocks by lines indentation (without endfunc, wend etc.) dim and const outside of functions means global and global const respectively, inside of functions means local and local const arguments of function are const by default, but with dim prefix it becomes variable short synonyms for functions as a rule using in large projects: for arrays, files and strings no “$” prefix in variable names single-line anonymous functions and each of this is optional Overview ; file “mylib.aup” dim foo*, bar func baz*() foo = quux() func quux(dim arg="one/two/three") bar = Sort(Split(arg, "/", @NoCount)) return "begin" . @ . bar[0] . @ . "end" ; file “main.aup” #import "mylib.aup" … In this example variable bar and function quux() are private for module mylib.aup (names at declaration ends with an asterisk) and not visible in main.aup. Variable foo and function baz() will be visible with the “mylib:” prefix: ; file “main.aup” #import "mylib.aup" foo = baz() ; error: no foo and baz() in this scope mylib:foo = mylib:baz() ; OK: foo and baz() are public in “mylib” scope mylib:bar = mylib:quux() ; error: bar and quux() are private in “mylib” scope Sort is synonym for _ArraySort, Split is synonym for StringSplit, @NoCount is synonym for $STR_NOCOUNT, “@” is synonym for @CRLF, “.” is synonym for “&” operator. All synonyms Setup Requirements: AutoIt (minimum), AutoIt Script Editor (optionally). Download and unpack archive from latest release. Double click the “setup.aup.au3” file and follow to setup instructions. First steps Right-click in the any folder and select New > AutoIt Plys Script. Right-click on the created file again and select Edit Script. At the bottom of the file type the following: #include <MsgBoxConstants.au3> dim msg = "" for i = 1 to 10 msg .= "Hello World!" . @ msg = TrimRight(msg, 1) MsgBox(MB_OK, "My First Plys Script", msg) Save the script and double-click the file for run (or right-click the file and select Run Script). Extra options You can use extra options by typing in the script one of this: #plys dollarprefix ; refuse to use variables without “$” prefix #plys noconst ; use default variable declarations behavior #plys noindent ; ignore indentation but obligue to use “endif/wend/etc”. #plys noimport ; refuse the import operator #plys nosynonyms ; refuse the function and macro synonyms #plys nolambda ; refuse the anonymous functions Environment After installation Plys already integrated to Windows shell. If you want to run a script by command line use <AutoIt3.exe path> <AutoIt3exe folder>\Plys\plys.aup.au3 [/Rapid] [/ErrorStdOut] [/NoStdio] <script path> [<arguments>] /Rapid means that if source files have not be modified since the previous run, they will not be re-translated. This option speeds up script execution startup. The /ErrorStdOut switch allows the redirection of a fatal error to StdOut which can then be captured by an application. Also you can turn off data exchange through standard input/output streams, then the shell process will not hang in memory, but then you will not be able to observe the output of your program in the output window of your development environment. You can do this by adding the /NoStdio option. If you want to translate a script to pure AutoIt code use <AutoIt3.exe path> <AutoIt3exe folder>\Plys\plys.aup.au3 [/Translate] <script path> Try AutoIt Plys package for Sublime Text which including syntax highlighting, auto-completions, build systems for run and compile, context help, “goto” feature, comments toggling, Tidy and Include Helper command for AutoIt and AutoIt Plys. You can compile the script, specifying to the compiler the translated file *.aup.au3. How it works The plys.aup.au3 file contains the code that will run immediately after the launch of your script. On setup this file will copy to AutoIt install dir (as Plys\plys.aup.au3) and aup-files will associated with it. On the launch aup-files are automatically processed, after which the new AutoIt process interprets the already converted code, and the current process remains cycle to continue data exchange with the new process via standard streams. This handler replaces all #import with #include. The processed files get the extension .aup.au3 and are placed in the folder of the original script with “hidden” attribute. Future #import "filename.aup" noprefix #import "mylib.aup" noprefix bar = foo() ; bar and foo will be taken from the “mylib.aup” without “mylib:” prefix #import "filename.aup" as alias #import "mylib.aup" as ml ml:bar = ml:foo() ; bar and foo will be taken from the “mylib.aup” function scope functions func GlobalFunc() dim var1 = "body" func LocalFunc(var2) return "begin" . @ . var2 . @ . "end" return LocalFunc(LocalFunc(var1)) MsgBox(MB_OK, "begin/body/end", GlobalFunc()) array values in place and array comprehension a = [3, 7, 1] for i in [1, 2, 4] Echo(i . @) Display([t*3 for t in a if t > i]) ; if i = 2 then Display([9, 21]) etc. Download Repository on GitHub Very old version (import only): import
- 6 replies
-
- lambda
- modularity
-
(and 2 more)
Tagged with:
-
As I understand it: there is no distinction, when a variable is declared outside any function, between declaring it Global and declaring it Local. This is unfortunate when: a project has several dialogs: declaration of control variables can conflict. a project has one complex dialog In the latter case, I have one here with a dialog function that is 269 lines! I could declare all the control variables as Global, but globals should be aoided where possible. I think good practice would be to put each dialog in its own file (unless it is a really simple one). Life would be easier if there were a distinction in how variables are declared outside functions: Global would mean the variable is known to all .au3 files in the project Local would mean that the variable is known only within the file in which it is declared. So control variables could then be declared as known to all functions in the file (module) by declaring them as Local outside any function. Other languages have this feature. I am working on a project with one not-very-complex dialog. I would like to be able to split its 269 lines into several functions, e.g. the creation of the dialog, enabling/disabling controls based on a control, and updating the values of the controls due to user actions (in this case, a listview). I already have factored out into functions parts that do not involve control variables: verifications of user entries and actions when the user clicks on OK (or equivalents). Would this be script-breaking change? Probably, but only for those who don't follow the best coding practices: as AutoIt is now, one should not be declaring variables as Local outside functions, because one gets Global anyway. There is nothing Local about a variable declared outside functions. I will be interested to learn what others think. If this is an old topic, I apologize. If I have it wrong, do tell me.