argumentum

#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

@SOLVE-SMART, I see the confused emoji. You should know that I have you in the highest regards. All you do is well done and you have an amicable demeanor, yet I answered with an abrupt but clear answer. And that is because asking for what the OP is presenting is a "no-go", "not gonna happen" kind of situation. So, how can we rescue the proposition ?, a compromise. Don't go overboard with the request. Lets see if the independent UDF portion can be updated more often. If that takes off and becomes a reality, then expanding it to some of the UDFs from the WiKi ?, maybe ?. But for now, focusing on distributing the standard UDFs more often is a goal that merits attention. And even that has a strong opposition in my view. So, baby steps. In any case, a package manager for GitHub hosted projects is a simple thing compared to the private ( until full release ) of the standard distribution UDFs. I say that we focus on that if we expect any attention. My 2 cents. Am a forum user just like you in regards to this.

Ok that did solve the long list of unrelated variables but also took away other new interesting features. Any way to separate the type of autocomplete ?, variables vs. functions ? .... but I'd like to keep the variables of the includes that are not UDFs ...so, a way to exclude via an exclude list of variables to not present as part of the list of variables 😅 Goodness, am a pain. I should have asked these questions a year ago when you were actively working on it. Edit: @Jos please put the baseball bat down and don't hit me. It is as it is, and if I participated earlier ... it wouldn't be so frustrating for you dealing with these questions so late in the game.