argumentum

lol, nope. In any case, this is a drain of money and time. You can always jump to AutoHotKey. They took the shared source and made it open source. I still like AutoIt better. It can do all I need. Then again AutoIt is not the only language there is. And it would serve everyone to know other languages too. Windows was coded in C, so learning some C would be good to translate some of the M$ stuff to be used in AutoIt. Look, say that you find a nice way to chop wood and share the tool ( AutoIt is a tool ), then people are like "yes, we can add a shotgun shell" and then some other start with "what about a Gatling gun, that'll be even better", and by the end of the day, you are disregarded, your project took a life of it's own and, WTF ! So yes, make more UDFs. Those are open sourced. AutoIt, the binaries ( and the code to build it ) are not. I hope the "let's free willy AutoIt" be dropped before it even become the same repeated conversation, but in 2026, because this topic is going to go nowhere fast, and that'd be a shame.

Get the one from the beta folder. That does not occur with the newest version. I have no idea, but if you can share what is the program you're running, maybe someone has experience with that one. Or at least have a better idea of what's going on. Also, the OS language and keyboard in your setup ?. The more information you share, the better picture of what is going on we get. If you solved any of these, post the solution.

#include <WinAPIGdi.au3> ; _WinAPI_SwitchColor ( $iColor ) ; Converts a color from BGR to RGB and vice versa

Ok, thinking time. You wanna do it all in AutoIt (2) because you could really use knowing more (1). You would not think of taking php.exe and expect to DLL call a function from index.php called DllMain(). Or the same with python.exe of project.py calling DllMain(). Do read what Mav Leving was doing with his C code, because C and AutoIt's scripts are 2 very different animals. ( hasherezade was using his idea ) Because the difference between "Autoit.exe script.au3" and Script.exe, is not much. Before ( 3.3.6.1 ) the script was appended to the executable, now is a resource in the executable, but always a loaded script for the executable. Maybe read up on C# and you'll find ways to use AutoIt with that. You can compile C# on the fly too ( if memory serves ). Also @Trong posted a nice guide on DLL stuff. Yes it is

GitHub is trying to come up with new ways to monetize. Codeberg has "members" ( if you wanna cast a vote ). All git commands are the same. Going one way or the other is all the same to me. Edit: Can't find a way to recover my argumentum GitHub account ( that should be mine but, can't remember a thing ) so am going with another one 🤷‍♂️

Each entry in SVN has the revision number, action type, author and message. In the message we enter details, that in my case has explanations and a link to the source material to read up on why was there a change or addition. Having the logs, do help the reader know why something changed. Edit: and yes, I see that JPM is working on the logs too

autoitudfs-v3.3.19.0-alpha<SVN revision number>.zip would be better when you find a way to automate the building of the zip file.

James bond (007) had license to kill, but I doubt there was a consortium like in GPL. WTFPL is a type of license, but a license is just a type of agreement and that's about that. Pointing to AutoIt Software License should suffice, unless GH only have an assortment from a pull down menu. Edit: didn't see that there was this 3rd page 🫣

..that's the problem. Jon is mostly unavailable. Jos is presenting an option that does not include him. The whole issue is with Jon's lack of delegation, and if you follow the history of AutoIt's development, that lack of delegation is perfectly understandable. The SVN is not publicly readable, hence my requesting of permission to even think of any changes. Mind you that am a new addition and haven't been here long enough to know exactly how to go about changing the way it is been all this time. But for me to "man up" and ask Jon for something it will have to be clear and concise and, not solely dependent on one forum user, because that user may die ( or something ). So it should be something that does not risk degradation due to so-and-so is not here. Something that can be automated as much as possible and the team that runs the GitHub not be able to screw with this site's repo ( SVN ). All this with the assumption that Jon does not have the time with the hectic pace of GitHub. On the other hand, he does not code UDFs, he's just for AutoIt3 binary, the UDFs is MVP area, so far. I don't know what "picture of reality" will better serve the community, and that is something that Jon would have to thinker with ( along a drink and soft music I guess ) And this is as far as I can contribute as far as ideas, I think. Know nothing of GitHub and don't have the time to take it on my shoulders ( upon myself ) to run it and be the sole maintainer. @Jon, have a read of this thread and whenever you find the time, share your 2 cents.

Ok, @WildByDesign, long time a go, there was a post called WinAPIEx UDF that was later integrated in the standard UDFs. How about we do our community effort of an unofficial UDFs ( like "WinAPIEx UDF" was at one point ) but hosted in GitHub, and take it from there ?.

Ok, power to the people ! , but, who is going to make the bridge between SVN and GitHub ( not you, ok ). But has to be an already MVP to access the SVN. All in all, we are brainstorming a proposal for Jon to say yay or nay. On the other hand, going all GitHub would open up for expanding the standard UDFs, but it would certainly be more hectic, ..and would need approval 🤔 ? I guess I did it again. But is not to bug anyone. Is to bring ideas to the "think tank". Since I can not state what we are going to do, how things are going to work from now on, and am afraid of unintended consequences, ...bringing a bunch of doubt and assumed limitations, clarifies things. Like your "we can GitHub it" was a surprise for me.

Since the GitHub would require a single person to attend to it ( I guess, I don't have much experience with it ), packing the UDFs when they are not "in between" updates, and that is mainly you, JPM, mLipok, water, etc., making a post announcing a, semi-annual update or whenever there are changes, would be better than just clone to GitHub. The idea of using GitHub is good, but not as a clone, rather as "here is a zipped update", would avoid the control issues that arise from people screwing the UDFs. This site is just as good to collaborate without going all GitHub. What do you think @Jos ?

A zip file is not a great compressor but the most flexible packer for use from WinXP to Win11. Bandwidth is worse but flexibility is better. On that: thinking ahead on what that implementation would need ... . Would be nice if the release.inf ( to give it a name ) was compatible with that unrelated project to future proof the possibility of the integration of both, by the community driven updater. And as you can see, I too tend to over engineer / over think stuff. There is no need for the release.inf to be compatible ( but it'd be nice ) If the release.inf file is a good standard, anyone can make a package manager based on the release.inf standard. So getting that release.inf well thought out ( by those with experience with that type of software, I've never used one ) is important, I believe. Not important to this project but again, it'd be nice to think ahead. Look at the code of the 2 scripts already there. Then we follow the same criteria for this updater. ... I just wanted a separator here When texting my kids a question, if they don't respond within a few minutes, I text: "yes,no,maybe" like in, answer !. Since I don't pay much attention to emotional damage 🤷‍♂️, at times I don't filter myself adequately, or even close. Or just no filter. ...because I process stuff different ( maybe ) and things are "right to the point", is my default trend of thought. My mind works on a "if, then, else" in a loop, to the point that there are so many if,then,elses that I get overwhelmed, and go right to the end result of my if,then.elses, hence a stern yes/no/maybe. I mean no harshness. The avatar I use is the best I found to show myself in a picture 😅

on that front, evaluating a JSON or INI or something, to hold the distro's info would be beneficial for a standardized updater that would keep in mind "what if" we integrated it an all-in-one in the future and/or common interaction, as a standard. Ok, I too have to go, catch some ZZZzzz

You know that in "\AutoIt3\Extras\AutoUpdateIt\" there are 2 scripts to update AutoIt and SQLite. Maybe we can ask for a UDFs update script and place the UDF.ZIP file somewhere on this site and that would not require any changes for the current installer nor wait for a next release to get what we wanna see. Just an idea