-
Posts
132 -
Joined
-
Last visited
Profile Information
-
Location
Germany
-
Interests
Lifting heavy things up and putting them down again, videogames, looking at dank memes, probably AutoIt too.
Recent Profile Visitors
491 profile views
Radiance's Achievements
-
Radiance reacted to a post in a topic: AutoIt/SciTE installers not registering correctly under Windows 10
-
I double-checked this on a clean VM and it's not the case, VS doesn't set anything here. Also tried to reproduce the issue a few times but no luck. I have no idea where this registry value initially came from, I certainly didn't set it myself and there's been no AutoIt-related stuff going on at my freshly set up windows before this. What a mystery, lol. But anyway, it works now. Thank you!
-
Radiance reacted to a post in a topic: AutoIt/SciTE installers not registering correctly under Windows 10
-
!* Registry key: "HKCR\.au3" - "Default" is currently set to au3_auto_file ==> This should be changed to "AutoIt3Script" (or "AutoIt3ScriptBeta") Wow, this one actually really fixed it. Script-files look like they should, there's now Edit/Run/Compile options when you right click one and also I can create new .au3 files via the context menu. I did not and yes I have. A newly set up Windows on an empty hard drive. This is very wild to me. Both installers were freshly downloaded from the official website. AutoIt v3.3.16.1 and SciTE 21.316.1639.0.2 - there are no other installers on my system. I tried to reproduce this by uninstalling, checking that the reg key is gone and then reinstalling (using the same installers where the problem initially occured), it correctly gets set to "AutoIt3Script" now. My theory is that something else did set that registry key beforehand, it might have been Microsoft Visual Studio 2022, which I installed before I installed AutoIt. There's currently no other software on my pc that would have any business with .au3-files. If I manually set the key back to "au3_auto_file" and run the AutoIt-Installer again it simply stays this way, so this: ...doesn't seem to be the case. The invalid reg key: doesn't get removed by uninstalling AutoIt (it does if it's the correct value) doesn't get set to the correct one after installing AutoIt again. Edit: big THANK YOU for the help, Jos
-
I think so too but I have no idea what I did different this time while setting up my pc. Even used the same Win10 DVD as times before. Here's the output from the check: ****************************************************************************************************************************************** !* Found always open with Win7 :Applications\SciTE.exe !* Fixed by removing Registry key : "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.au3\Userchoice" !* Registry key: "HKCR\.au3" - "Default" is currently set to au3_auto_file ==> This should be changed to "AutoIt3Script" (or "AutoIt3ScriptBeta") * HKLM\SOFTWARE\Classes\.au3\ShellNew: C:\WINDOWS\SHELLNEW\Template.au3 (File Exists) * HKCR\.au3 ShellNew : C:\WINDOWS\SHELLNEW\Template.au3 (File Exists) ****************************************************************************************************************************************** * Explorer shell options: * HKCR\au3_auto_file\shell: * => Default Action: ****************************************************************************************************************************************** * User SciTE info: * SCITE_USERHOME:C:\Users\MyUsername\AppData\Local\AutoIt v3\SciTE: * Directory missing: C:\Users\MyUsername\AppData\Local\AutoIt v3\SciTE\SciTE Jump * SciTEUSer.Properties: *----------------------------------------------------------------------------------------- import au3.UserUdfs import au3.keywords.user.abbreviations ******************************************************************************************************************************************
-
Hi all, I recently reformatted my hard drives due to an unrelated malware issue and after setting up Windows I tried to install AutoIt again. Did this the same way I've been doing it for years. Download latest AutoIt Installer, let it run, download latest SciTE installer, let it run. After installing SciTE I noticed I can't create new .au3-files from the windows context menu anymore. Existing .au3-files also had no assiciation with them, meaning trying to open them would bring up the windows prompt for selecting an application. Reboot, uninstalling and installing again didn't fix the issue. A partial solution would be to just tell windows to open the files with SciTE.exe but then they'd all look like compiled scripts. Still wouldn't allow me to create new scripts from the context menu tho. I've been using AutoIt for years, installed it on way too many machines and have never seen this happen. How can I fix this? Windows 10 Enterprise 22H2 with latest updates.
-
I don't know what to log. The example above is only a slight variation of what I actually tried: Global $CheckForFile = "\\myserver\myshare\somefile.txt" While 1 Sleep(2000) If FileExists($CheckForFile) Then FileDelete($CheckForFile) WEnd I swapped the pseudo func for a FileDelete(). This is the whole script which I actually have the exact same problem with. Path names are not the real ones for privacy reasons. The file already exists beforehand and gets deleted once I start up the task manager. FileExists on just the \\myserver\myshare also returns 0 as long as the taskmanager doesn't get started.
-
Hi all, I have an insanely obscure problem at work which I feel is maybe more of a Windows-Problem than an AutoIt one. If this is the wrong forum, apologies, feel free to move my post. I have absolutely no idea what's going on here and can't find any solutions to similar problems online. I have a few Windows 10 x64 clients that need to run an AutoIt Script at startup with local Administrator privileges. What the script basically does can be broken down to the following lines: Global $CheckForFile = "\\myserver\myshare\somefile.txt" While 1 Sleep(2000) If FileExists($CheckForFile) Then _DoSomething() WEnd It waits for an file to appear at a given UNC-Path and does something if this is the case. The script is a compiled .exe and gets started via the Windows Task Scheduler under the context of the default local admin user whenever he logs on. The "Run with highest privileges" is also checked. Now here's the really weird part: Once the user logs on, the script starts and even the tray icon can be seen. But it doesn't do anything, even if the file exists already. The script starts operating the second I manually start the Task Manager. For example like this, by right-clicking on the task-bar: I don't even have to do anything else like switch to the Details-Tab and inspect the process or something. Opening up Task-Manager and closing it is enough for the script to work flawlessly for the rest of the windows-session. The script works correctly without this if I: ..manually start the script by right-clicking it and select "Run As Administrator" ..manually start the task from the windows task schedule ..run the task manager once (as above). So, my current workaround is another AutoIt-script in the Windows startup folder of the admin user which does this: ShellExecute("taskmgr.exe", "", "", "", @SW_MINIMIZE) ProcessClose("taskmgr.exe") Yeah, this works, but I don't like this solution very much because it makes me have two AutoIt scripts in different startup places. The script in question doesn't generate any windows or message boxes at all. None of the scripts contain a #RequireAdmin. I really need some help here... any ideas much appreciated! Best regards, Radiance
-
IBM i Access Client Solutions... with AutoIt
Radiance replied to Radiance's topic in AutoIt General Help and Support
Hi, my bad, here's the code. If the func succeeds, $a will become the var that contains the actual global ECLSession object for further use in other functions. It already fails at the third line of the function. It counts every connected Legacy Client Access session, however leaves out any connected session created via Client Solutions. -
Hi all, this is very specific. I'm an administrator for several IBM i Power mainframe servers that run i5/OS and people use the Client Access Software. For now I've been using the Host Access Class Lib in my AutoIt Scripts on Client Access to automate most of my tasks. The essential code lines are this: After this you can use the methods listed here to remote-control your Client Access session. Much like a macro. This worked fine for the Client Access software. Now IBM released their new IBM i Access Client Solutions and I can't get it to work with it. Does anyone have any experience with this already by chance?
-
zone97 reacted to a post in a topic: convert a Unix/Epoch time to local time (with DST correction)
-
Radiance reacted to a post in a topic: [Solved] For-Loop, counting in Letters
-
[Solved] For-Loop, counting in Letters
Radiance replied to Radiance's topic in AutoIt General Help and Support
Exactly what I was looking for, tyvm!! -
Hi all, I need to progress Microsoft Excel colums using a for-loop: For $i = Asc("A") To Asc("Z") ;Do thing in column Chr($i) Next Once I reach column Z I obviously have to stop. How would I go about this once the colums start to be so many that the order looks like "...X, Y, Z, AA, AB, AC, AD, ...." ?
-
Radiance reacted to a post in a topic: Stringregexp Guide
-
Dllcall does not work... partial
Radiance replied to loady's topic in AutoIt General Help and Support
Does the line Case $CMD_MONITOR_AN in your tablet script really get called? You can check by placing a MsgBox before or after the DLLCall. I'm not very experienced on DLLCalls, can you maybe wake the system up alternatively by moving the mouse a little bit? -
I'm assuming you're in a corporate environment. Deploying software with LANDesk should always be made in the background. If you make random windows appear while the user is working, he will most likely interfere with your setup routines by closing the window or else. For almost every good software there's an option for a "silent install" which runs completely invisible and saves yourself a lot of window-management work.