AutoHotkey Community

I was considering adding an interface to execute code on a thread directly

I think that is pretty nice, I did something of that sort (if I understand you correctly) for UCR, quite primitive though (link).

Also, I tested to replace the AutoHotkey_64.dll with the corresponding v2 version, it worked as far as I could tell, but I couldn't pause .

Cheers.

I'll look into adding that then.

Helgef wrote:but I couldn't pause .

shrug I've never tried v2. Though I can't imagine the functions would be different. I downloaded it to see the help file, but I didn't see anything in there related to the DLL's, as there is (exclusively) in the v1 help. If you can figure out the issue, I certainly won't mind adding a fix for it, or even adding "Set DLL: [Std/Mini] v2" options to the menu.

Added code execution for a specified thread (context menu). It's synchronous though and will pause the main process. I think I might offload the entire list object (which includes all threaded scripts) to a child thread, which would also fix the status update problem. It may present other problems though.. I'll test it and see how it works.

Update: fixed error that was happening during first run.

Drugwash wrote:.

Honestly, I feel like such an idiot. Oh well, it happens. Fixed now. Thanks for the info, by the way!

big help for me, i have 12 scripts thanks

Masonjar13 wrote:Update: fixed error that was happening during first run. […]
Thanks for the info, by the way!

You're welcome, glad I could be of help.

Hey everyone, I've got some news!

First, I pushed a minor update: you can now right-click scripts in the list and choose "Edit" to have the script open in your default editor (whatever you have set for when you right-click > Edit a script file).

Second, I'm working on a new version. Here's a few of the new features:

• All scripts will be offloaded to a worker thread, making the main GUI *much* more responsive.
• There will be a more appealing graphical interface, with actual graphics rather than.. well, just a giant listview box.
• DLLs will be included by default, though you will still be able to change them.
• Compiled! I'm going to make it work seamlessly both in script form and executable form, so you can take it on the go!

This will take some time to do, since it's a near-complete rewrite. When it's done, I'll post it as the v1 release on Github.

Good stuff, I look forward to see the updates. Execute code works well, great for debugging .

Cheers.

Just saw this now for the first time through GitHub... Neat!

Thanks, glad you think so, joedf

While I'm here, I may as well post an update to the current status of the update. I'm stuck with a bug that I can't get around, which is almost the whole point of creating a v1. It has to do with off-loading the threads to a separate thread. Simply, I can't. I've made a post on it; if anyone can help solve that, I can get back to working on it. Otherwise, good chance I'll leave it where it is. Not really what I want to do, but how can I progress if I can't progress?

¯\_(ツ)_/¯

Update: v1 has been released! Huge thanks to HotkeyIt! Special thanks to GitKraken

Binaries will be released with each significant update and can always be found on the releases page. Functionality hasn't changed very much, which is what I was going for. It does seem to be performing noticeably faster, however, so that's good! Script/DLL paths can now be relative to the data folder, allowing for full portability. It also defaults to the included DLLs with a relative path during first run. The binaries are off-the-server ready, no extra stuff needed (it's all packed inside). Meaning, if there's an update to the worker/DLLs, you'll need to remove those files so it can unpack the new versions. I didn't force overwrite for efficiency purposes. An easy way would be to back-up your config, delete the data folder, and move the config file back. I don't expect to be changing the config file to the point where you'll have to start over, so that should always work.

I didn't test on W10, so those who use DPI scaling, let me know if there's an issue, or request a pull.

As noted on the readme, I noticed that scripts will not properly use SetWorkingDir, so I recommend always using full-paths in any scripts you add!

So I was making a new W7 VM to run tests with and I got a curious error in _MemoryLibrary/_Struct: ERROR: BuildImportTable failed

Here's the last page of ran lines. Occurs in both the compiled and script versions. VM is fully updated on Windows 7 Ultimate, same image I have on my desktop. Guest additions installed (using VirtualBox). Anyone know why this is happening? Because I have no idea. The error, as I've gathered, means that the DLL couldn't be loaded into memory. The reason why, that's what I have no idea about. It's definitely not an issue of lack of RAM.

If the error message is in the least accurate it means the script couldn't find an import table in the respective library, or it couldn't list it. You may have to enhance the code a bit to find out which library exactly fails and then look into it using Dependency Walker or any other similar tool to see if it indeed has an import table and what it consists of; it may be all ordinals, or delayed imports, or something that slipped the original code.

There is also a slight possibility that the respective library might wanna be loaded through LoadLibraryW(), not LoadLibraryA() as I see in the code snippet above.
Make sure the loaded library handle is not getting corrupt somewhere in the process.

All this is off the top of my head, didn't look through the Struct or MemoryLibrary code, so don't rely too much on what I said. Hopefully you find the issue soon. Good luck!

If it were any of the aforementioned issues, it would also fail on my host and other computers I've tried it on. It works fine everywhere else though, just not in the VM. I didn't write or modify _MemoryLibrary or _Struct, those are both written by HotKeyIt. He's actually going to be the guest host of the next AHK webinar, and I see "MemoryLibrary" on the list of topics, so I'll ask him about it then.

Hello.
I really like this script and use it very often.
It is almost perfect, there are just some things that are still annoy me.
Okay, so...
I use 2 Scripts with this. The first is "Wallpaper-Randomizer"
and the second is "Process-Whitelist"

My ScriptUp Ini looks like this:

"Wallpaper-Randomizer" as the name says randomizes some Wallpapers from a Folder for your background automatically. It needs a "top.exe" all the time in it´s folder when a new Wallpaper is shuffled.
"Process-Whitelist" terminates or whitelists your processes automaticly, it does this by looking at 2 Logs, named "Process-Whitelist.ahk.BLACKLIST.log" and "Process-Whitelist.ahk.WHITELIST.log".

The Problem i have is that whenever i use your script, it need to has the files from the 2 scripts in it´s own folder, which doesn´t speak not really for portablility. Is it not possible for your script that all the other scripts have it´s own folder and files? It´s not only for these 2 scripts, i found out it´s globally for all scripts that needs some extra files besides only the ahk file. Besides, look how my "Wallpaper-Randomizer" looks because of "ScriptUp":
That speaks for the other Folders too. Even "ScriptUp" need the "top.exe", "Process-Whitelist.ahk.BLACKLIST.log", "Process-Whitelist.ahk.WHITELIST.log" in it´s folder, which mean no true portability.

Please don´t get all that in the wrong meaning. I´m not raging.
Besides all of that your script is great.

Hey, glad you like it! I have spent quite a lot of time (about 3 years) on this, so if even a few people are using, that's awesome.

I've actually noted this limitation on the Github readme. SetWorkingDir will be overridden. They will take on the working directory of the worker script, which is in the library. Full paths will need to be used in scripts.

The reason for it being this way: it allows paths in the ScriptUp ini file to be relative, therefore allowing actual portability on, say, a USB drive. When you connect a USB drive, it gets assigned a drive letter, which may or may not be the same as when you had set the script path. Making relative paths work here allows it to always be able to find the script.

Easy fix: in your other two scripts, don't use relative paths, but use full paths instead. If you need to, when launching a process with Run, set the working directory for it so it can find the files it needs to. If you want to use relative paths, make it a full path instead with a_scriptDir.

Besides the benefit of using relative paths for the scripts, it also keeps a stable working directory. All scripts ran under ScriptUp share the same working directory, since they're all under one single process. That's simply the nature of hosting scripts as threads instead of processes.