Leaderboard

AutoIt was never really built for speed — it’s an interpreted language, great for scripting and automation, but not exactly a high-performance engine under the hood. So trying to make it handle things like fast array slicing or inserting elements mid-array feels a bit like teaching a car to fly or haul 30 tons. Sure, maybe you could pull it off with enough creativity (and duct tape), but if you want to fly, you take a plane. If you want to haul heavy stuff, get a truck. Same with programming — sometimes it's better to just pick a faster compiled language for the job. That said, I love seeing people push the boundaries of what AutoIt can do. Using FASM, COM, and clever hacks to get more out of it is impressive, and if it helps you learn or build something cool — go for it! Just don’t forget the core strengths of AutoIt: simplicity, ease of use, and rapid development. Sometimes it’s okay to let the car be a car. 😊

I'm working on a release that has full support for Visual Studio Code (plus VSCodium in my case) and Visual Studio 2022. Both are working beautifully and reliably. So I should be able to do a release soon after some more testing. Screenshots:

So AutoIt does not have a good (fast) solution for things like: taking part of an array as a new array adding element(s) at the start or middle of the array In general array manipulation requires a loop, not a fast solution in AutoIt. I'm thinking using IDispatch to handle variable transfer between normal variables and the raw variant pointers. And fasm to do the array manipulation, importing the OleAut32 functions for variant manipulation. I expect this solution to be fast, and only require AutoIt and a fasm DLL, to work. My biggest issue currently is my lack of experience with ASM. I could try to throw something together, but would prefer help from someone, who actually knows what they are doing Any feedback on this idea is appreciated

I would say fasm is a known DLL. the generated code COULD be a DLL, but I'm thinking sticking with executable memory for now. The appeal would only be when working with big arrays. Thanks Ideally any size array and number of dimensions, but for proof of concept code, 1D arrays would be the target. Not sure about frequent use, but a neat solution when working with big arrays. I agree that small arrays would not benefit from my idea at all. I would argue there are situations where people are working with big arrays, and the issue with acceptable speed limits the projects that AutoIt would be chosen for? Yes and no. Ideal data structures and code for handling those cases, but the syntax suffers in AutoIt, since array access syntax is limited to a few types. If AutoIt supported array access syntax via an interface, i would go with that. The idea is something that can be used in already existing code, without requiring a complete rewrite or converting to and from the underlying safearray.

😄

Hi @argumentum . Thanks for your feedback. Regarding the constants $NIIF_NONE, $NIIF_INFO, $NIIF_WARNING, and $NIIF_ERROR, I chose to comment them out in this example because they correspond to Windows' predefined system icons. This function focuses on custom icons extracted from shell32.dll (system 🙃), selected by the user, hence the exclusive use of $NIIF_USER to handle icon handles. For $NIIF_RESPECT_QUIET_TIME, you’ll need to configure the object beforehand using the method $oNotif.SetBalloonRetry(3000, 0, 0) to set the retry parameters. This is a simple example, designed to be flexible and adaptable, so feel free to modify it to add other icon sources, reactivate the constants for different notification types, or adjust the retry settings as needed.

Ok, what size array/dimensions are you thinking of ?, what frequent use ?. If the array is small, is not that slow ( for AutoIt ) but, ... what circumstances would require lightning fast array manipulation ?