Recently Browsing 0 members
No registered users viewing this page.
In the console under the editor in SciTE:
if I add @@ Debug(line,column) then it goes there.
if I add "script.au3" (line,column) then it goes there if loaded.
if I add "c:\path\script.au3" (line,column) then it loads the file and goes there.
...so far so good.
Since I don't know LUA, nor where that is at, my question is ... where is it at ?
A silly question because once there I would not know what to do, since I don't know LUA.
What I want to achieve is, that since there is something delimiting the script and editor position (li,co), a way to have, let's say:
+I like this color and the text that I care for on the left ["c:\path\script.au3" (line,column)]
and by having this ["" ()] format ( or anything else, it don't have to be this exact format ), the console would know to jump there.
If DClick to jump/goto Line,Column can trigger an external EXE or script, I'd take it from there. If it all can be done from LUA then, I'd do it there.
So I don't mind or know how. I just would like that functionality. In a way that don't require a recompile of SciTE.
while I created an example script to generate and execute a function during runtime, I stumbled across a neat way to share data between running autoit scripts.
This is done using the amazing magic of AutoItObject_Internal . (You'll need at least Version 3.0.0 of AutoItObject_Internal)
Using this UDF, you can create a shared data storage, basically an empty "AutoitObject_Internal-"Object which you can then use to write / read data Inline. no set/get methods, just
#include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") $oShare.some_data = 'foo' and you're done. any other script accessing this data will have to do:
#include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") ConsoleWrite($oShare.some_data & @LF)
Basically it's Larsj's Implementing IRunningObjectTable Interface, but you dont have a Dictionary, but an IDIspatch Object instead.
There are already a bunch of IPC options available - and this is another one.
Example Script 1
Example Script 2
To test: run Example Script 1, Then run example Script 2.. or the other way around.
Example Script 3
To test: run Example_sharedata3.au3.
/Edit: Please note that there's a limitation with the Running object table :
The Script accessing a variable first, will be the "server" for this variable. This means, access to that variable from other scripts should only be possible, as long the "server" script is running! Use appropriate Object Error handlers in case you don't want the surviving "clients" to crash.
Feedback and/or improvements appreciated
Removed need for AutoItObject, as AutoItObject_Internal now comes with ROT support Added UDF Header Fixed typo on "#include AutoItObjectInternal.au3" -> "#include AutoItObject_Internal.au3" Added ObjGet() after registering the object fails (in case 2 programs tried to register the same ID simultaneously) Updated Examples & zip archive. Cheers,
AutoIt3 Lua Wrapper
This is an AutoIt3 wrapper for the Lua scripting language. Consider it beta software, but since I will be using it in commercial product, expect it to evolve.
It has been developped with Lua 5.3.5. Updates will come for new Lua version.
Everything works just fine, except one (big) limitation: Anything that throws a Lua error (using C setjmp/longjmp functionality) will crash your AutoIt program. That means that it is impossible to use throw errors from an AutoIt function called by Lua (luaL_check*, lua_error...).
It is hosted in Github: https://github.com/matwachich/au3lua
#include <lua.au3> #include <lua_dlls.au3> ; Initialize library _lua_Startup(_lua_ExtractDll()) OnAutoItExitRegister(_lua_Shutdown) ; create new execution state $pState = _luaL_newState() _luaopen_base($pState) ; needed for the lua's print function $iRet = _luaL_doString($pState, 'print("Hello, world!")') If $iRet <> $LUA_OK Then ; read the error description on top of the stack ConsoleWrite("!> Error: " & _lua_toString($pState, -1) & @CRLF) Exit EndIf ; close the state to free memory (you MUST call this function, this is not AutoIt's automatic memory management, it's a C library) _lua_close($pState)
so in https://www.autoitscript.com/forum/topic/193254-solved-ipc-between-system-and-user/ I asked around about IPCs and got all the answers I was looking for.
Now the question is: what IPC is most "resilient" on an overwhelmed PC, meaning, the CPU is at 100%, memory is top out and, as is always, need to rely on the IPC.
..and all this happened because I open over 100 GUIs at once 😜
..but it happens sporadically on low CPU or memory demand anyways.
..should I sleep() some time before running another instance ?
I did not know if to make the question in technical, chat, ..or here. So it's here.
Since you will ask what I've tried, I've used the IPC from the Fork UDFish ( WM_COPYDATA that can do Admin/user mix ) and the FMIPC file mapping, that work under the same conditions.
So, how do you handle IPC if it fails ?