argumentum

One thing is to install/update AutoIt and it's UDFs, and another outside of my thinking mind, is to use this site and it's product ( AutoIt3 ) to piggyback custom user UDFs, as if this site would vouch for them. And I read that npm had their issues with stuff. My idea is in regards to AutoIt's core components and UDFs. No other UDFs should be included. And don't get me wrong, I'd love to include a whole lot of awesome UDFs that are around but, is not the idea. At least that is something that I would not agree to if I was the owner of this site and project.

ok, did that. The hidden pic above is what am complaining about. How can I declare to only include the variables is the current script ?

Am a bit out of touch with v5. I want to install 3.3.18.0 with the SciTE v5 ( in another PC ), given that all my setups are still with 3.3.16.1. What do I run to install the v5 ? Run the SciTE4AutoIt3_vsc.exe and update with the SciTEx64.zip ?

Nah, other than the file corrupted in transit ( the download ) but not because the hosting site would distribute malware. If the user installed as Admin, then only and Admin should be able to update Admin stuff. Not a problem if you can run as Admin. hmm. A new beta, or alpha ? ( is not "released" other than a work in progress ) that may be interrelated to other UDFs. It'd have to be a full download of the whole new UDFs as a package. So not a "live" in development beta. But once the current beta is deemed as complete, because the help file will have changes too, then that could be packed and ... good luck ?, because a less savvy user ( yourself not long ago ) could have a hard time switching between "release", "beta" and "this" ( whatever this is ) AutoIt looks for the includes subfolder, and in SciTE one can declare a custom includes path ( all this I'll have to read up on because I'm not too sure ) so, ... ... how do you propose it would all work for the end user in exact concrete terms ? ( not pushing your buttons but clarifying your vision ) I like the idea. The AutoIt3 version ( the binaries ) has it's ins and outs, and that is that. But the UDFs could have a more fluid update cycle. There are more corrections that can be easily fixed in a UDF than the those of the stub itself. Then versioning could be with an added letter ?, like 3.3.18.0a ?, or a date, ..or the internal SVN revision I think would be best. 3.3.18.0 (r13212). Again, I like the idea, but again, present the whole picture so that @Jon can buy it ( you're the sales person )

I know you know is not the code. The Devs need a test bed to test their code. Running your code will show them where their code fails.

As you posted, all we all can say is "oh wow". To troubleshoot code, the code should be available as text, not a picture of a chunk. I don't even have PowerPoint installed not ever used, so not much help from me. If you present a simple short script that shows the trouble that can be replicated, then there is going to be a better chance to attend to it.

..since we're talking about it, the reason I don't use SciTE v5 is the autocomplete. If that could be changed in a LUA file ( or somewhere ) to behave like in v4, I'd give it a go.

That !, is exactly what I was looking for. I copy and paste until functional but, not necessarily "correct". Thanks for correcting the code

4k at 225%

#include <WinAPIMisc.au3> #include <ApiErrorsConstants.au3> Exit ConsoleWrite(@CRLF & _GetWindowsNotepadPath() & @CRLF & @CRLF) Func _GetWindowsNotepadPath() Local $asPackageNames = _WinAPI_GetPackagesByPackageFamily("Microsoft.WindowsNotepad_8wekyb3d8bbwe") If @error Then Return SetError(1, 0, @WindowsDir & "\notepad.exe") Local $sPathByFullName = _WinAPI_GetPackagePathByFullName($asPackageNames[1]) If @error Then Return SetError(2, 0, @WindowsDir & "\notepad.exe") Return $sPathByFullName & "\Notepad\notepad.exe" EndFunc ;==>_GetWindowsNotepadPath Func _WinAPI_GetPackagesByPackageFamily($sFamilyName) Local $aCall = DllCall("kernel32.dll", "long", "GetPackagesByPackageFamily", "wstr", $sFamilyName, "uint*", 0, "ptr", 0, "uint*", 0, "ptr", 0) If @error Or ($aCall[0] <> $ERROR_INSUFFICIENT_BUFFER) Then Return SetError(1) ;Bad call or unexpected error Local $iCount = $aCall[2], $iBuffSize = $aCall[4] If (Not $iCount) Or (Not $iBuffSize) Then Return SetError(2) ;No retrievable data Local $tNameLocations = DllStructCreate("ptr Address[" & $iCount & "]") Local $tBuffer = DllStructCreate("wchar[" & $iBuffSize & "]") $aCall = DllCall("kernel32.dll", "long", "GetPackagesByPackageFamily", _ "wstr", $sFamilyName, "uint*", $iCount, "struct*", $tNameLocations, "uint*", $iBuffSize, "struct*", $tBuffer) If @error Or $aCall[0] Then Return SetError(3) ;Bad Call of $aCall[0] <> ERROR_SUCCESS Local $asNames[$iCount + 1] = [$iCount], $tPackageName, $iNameLen, $pNameAddress For $i = 1 To $iCount $pNameAddress = $tNameLocations.Address(($i)) $iNameLen = _WinAPI_StringLenW($pNameAddress) $tPackageName = DllStructCreate("wchar Name[" & $iNameLen & "]", $pNameAddress) $asNames[$i] = $tPackageName.Name Next Return $asNames EndFunc ;==>_WinAPI_GetPackagesByPackageFamily Func _WinAPI_GetPackagePathByFullName($sPackageName) Local $aCall = DllCall("kernel32.dll", "long", "GetPackagePathByFullName", "wstr", $sPackageName, "uint*", 0, "ptr", 0) If @error Or ($aCall[0] <> $ERROR_INSUFFICIENT_BUFFER) Then Return SetError(1) Local $iBuffSize = $aCall[2] If Not $iBuffSize Then Return SetError(2) ;No retrievable data Local $tPath = DllStructCreate("wchar Path[" & $iBuffSize & "]") $aCall = DllCall("kernel32.dll", "long", "GetPackagePathByFullName", "wstr", $sPackageName, "uint*", $iBuffSize, "struct*", $tPath) If @error Or $aCall[0] Then Return SetError(3) Return $tPath.Path EndFunc ;==>_WinAPI_GetPackagePathByFullName Maybe it should be 2 functions, one for GetPackagesByPackageFamily and one for GetPackagePathByFullName ?. In any case, I don't see a reason to separate them. What would be the use 🤔 Thanks to @MattyD we now have proper code With this you can get the path to: "Microsoft.WindowsNotepad_8wekyb3d8bbwe" or "Microsoft.WindowsTerminal_8wekyb3d8bbwe" or anything else from the windows store. If you feel this should be different, say it. Am not a magician ( well, maybe flowers out of a stick but that's unrelated to the topic ).

8k can easily use 500%. Thinking of after 200% "screw you buddy", ain't nice. As long as odd percentages look good ( 125% & 175% ) in your monitor, it should look the same in greater scaling like 225% All tho, if you could get yourself a 4k monitor ( they are quite inexpensive nowadays compared to some years ago ) it would be good.

AI say that it does not need releasing/clean up, because the shell/OS takes care of it.

While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd $oIObjectCollection.GetCount($iCount) ConsoleWrite("returned " & $iCount & @CRLF) $oIObjectCollection.Release() $oIObjectCollection.GetCount($iCount) ConsoleWrite("returned " & $iCount & @CRLF) I don't think that does it.

...all you need is an 8k monitor. If the wife ask about the expense, you say "honey: was for science", and she'll say "ok, that makes sense" and you'll be off the hook

... Local $tagICustomDestinationList = _ "SetAppID hresult(wstr);" & _ "BeginList hresult(uint*;clsid;ptr*);" & _ "AppendCategory hresult(wstr;ptr);" & _ "AppendKnownCategory hresult(int);" & _ "AddUserTasks hresult(ptr);" & _ "CommitList hresult();" & _ "AbortList hresult();" & _ "DeleteList hresult(wstr);" & _ "GetRemovedDestinations hresult(clsid;ptr*);" ... hope this is good. I hope it is correct close to it. 😅