Leaderboard

Hi everybody since two weeks ago i have been working with this UDF in several proyects and I think its great! In the past i worked with this UDF: https://www.autoitscript.com/forum/topic/151530-ooolibo-calc-udf/ which is fantastic too. I think i have found a bug in the function _LOCalc_DocViewWindowSettings from the library LibreOfficeCalc_Doc.au3. In the line 2161 there is a call to the function __LOCalc_ArrayFill and the fourth and fifth parameters are switched. where it says __LOCalc_ArrayFill($abView, $oCurCont.HasColumnRowHeaders(), $oCurCont.HasVerticalScrollBar(), $oCurCont.HasSheetTabs(), $oCurCont.HasHorizontalScrollBar(), _ it must be __LOCalc_ArrayFill($abView, $oCurCont.HasColumnRowHeaders(), $oCurCont.HasVerticalScrollBar(), $oCurCont.HasHorizontalScrollBar(), $oCurCont.HasSheetTabs(), _ After modified it works fine. Thank you for your job.

This script is evolving quite rapidly, therefore changes will be ongoing. This is inspired by the Great @argumentum and Win11myOwnBorderColor as much of the framework comes from that script. Note: This is for Windows 11 build 22621+ Using that script as a basis, I have since: Added separate variable for title bar color Added the ability to change window corner preference (eg. rounded corners, square corners, etc.) Added the ability to extend the frame into the client area Added ability to apply backdrop material (eg. Mica, Acrylic, Mica Alt (Tabbed), etc.) Fixed child windows not having colors applied (changed to SetWinEventHook) TO DO list at top of script of stuff that I still need to add At the moment, the script is running without Admin, therefore will only apply to user-mode apps. If you want to apply to all apps, remove the comment before #RequireAdmin. Eventually, I am going to add the ability to create a scheduled task (like Win11myOwnBorderColor already does). I already have an AutoIt tray tool, so I will probably integrate this into my other tray tool. I may keep it as a separate executable which would then be run as a scheduled task. Problems: If you run into any problems with any apps, you can press Esc key to close DwmColorBlurMica and any apps that were not happy with it, simply restart them. I have excluded some apps in the script, such as Explorer and Start menu. But I still need to work on an exclusion list (and maybe inclusion list) that is either in the INI file or other file. I would like to be able to eventually load those into an array at some point. Features: Change border color to any color Change title bar color to any color Enable dark mode app settings (particularly dark mode title bar) Apply backdrop material (eg. Mica, Acrylic, Mica Alt (Tabbed), etc.) to the title bar Applies settings to all currently running windows and new windows Extend title bar color and materials to client area * * Please note that the extending of color and materials to client area (DwmExtendFrameIntoClientArea) works best with pure dark themes. For example, Rectify11's Black (Mica) theme. Also, some apps simply don't work well with it. It is a feature that really should be Opt-in per process which is something that I still need to implement. The possibilities (especially when mixing some of these options) are almost endless. The screenshots below only show a small amount of what is possible. Screenshots: Changelog: Current script version: 0.0.3 DwmColorBlurMica.ini DwmColorBlurMica.au3

Thank you for sharing this. I will go over this later tonight and figure out the config, arrays, etc. But for now, I am worn out after smoothing out the File Explorer stuff (version 0.0.2). It's all good now but I need a break for a few hours.

With version 0.0.2 (updated changelog in 1st post), we can now play with Explorer: Screenshots:

Just for the heck of it, this would be "a" config file This is a configuration file, because that's the way I thought of it =D The only the lines that start with ">" are the field and the value/data of the field is after the first "=" from the left Therefore >MyNameIs=argumentum is a declaration, anything else in this file is just a comment. The more the comments, the better =) and the reader func #include <Debug.au3> _DebugArrayDisplay(ConfigReadingCRLF("MyFile.config.txt"), "Entry count: " & @extended) ; or watever extension we invent Func ConfigReadingCRLF($sFile) Local $aArray = FileReadToArray($sFile) Local $iIndex = 0, $aReturn[UBound($aArray) + 1][2] For $n = 0 To UBound($aArray) - 1 If StringLeft($aArray[$n], 1) <> ">" Then ContinueLoop If Not StringInStr($aArray[$n], "=") Then ContinueLoop $iIndex += 1 $aReturn[$iIndex][0] = StringStripWS(StringTrimLeft(StringLeft($aArray[$n], StringInStr($aArray[$n], "=", 0, 1) - 1), 1), 3) $aReturn[$iIndex][1] = StringStripWS(StringTrimLeft($aArray[$n], StringInStr($aArray[$n], "=", 0, 1)), 3) Next ReDim $aReturn[$iIndex + 1][2] $aReturn[0][0] = $iIndex $aReturn[0][1] = "ConfigFile" Return SetError(0, $iIndex, $aReturn) EndFunc that may look strange but who cares !, is functional. Go figure, in the future coders will use this most awesome brainstorming in their code and it'll become a standard 🤪 Joke aside, use a standard or another. But know that you are not limited by standards. Admittedly, a standard is better because is known. But that is all**. **There is this thing called computer "science" and those in it explore efficiencies and inefficiencies but I never cared much for that, unless I had to.

Thank you for the report, and for tracking down the bug @JALucena, it's greatly appreciated. I'll change that right away. I must have messed it up in modifying the order of the parameters previously. Glad to hear you like the UDF, and that it is working well for you. It's nice to know it is a help to somebody, plus we appreciate the bug testing. Best regards, Donny

I think that INI would be easier for user to modify. I just didn’t know if there were limitations to Value size. For example, I imagine there could be something like 10-30 process names in exclusion list or inclusion list. Nothing significant. I’m not sure yet if INI can hold that in one value or not. But I will test and find out. I was thinking of using iniread func to pull in as a string and use StringSplit func to create the array.

..also, @AppDataDir Path to current user's Roaming Application Data @LocalAppDataDir Path to current user's Local Application Data So I personally use those to keep stuff at in the format of @LocalAppDataDir & "\MyInitials(argg)\Project(awesomeness)\FilesThatAreNotExecutablesAreHere" And I call that portable too, just because I don't use the registry. My code knows where information is centralized at.

Use whatever you feel comfortable with. INI, XML, JSON, ...SQLite, ...anything that you can write to and read from is good. As far as portability, carrying 2 files or 20, is portable if it does not need a declaration. Say you keep a folder structure like, .\settings\thisfile and .\settings\thatFile, is all "portable" by definition. IniRead(), IniWrite(), Ini* whatever is internal to AutoIt3. SQLite would require an external file ( the DLL ) but is all portable, as far as portability goes. And you are not switching to XML given that there is no prior release version while you explore what is best for your project so, use XML if you feel comfortable with it. That's my view.

What's New in Version 0.2505.0.30 The script assumed that only port 80 was HTTP so I fixed that. Also added nicer save to file report. Basically the same with some internal fixes.

Or maybe this : #include <Constants.au3> Global $bInsert = "0xFFFFFF" Global $hFile = FileOpen("mslogo.jpg", BitOR($FO_APPEND, $FO_BINARY)) FileSetpos($hFile, 20, $FILE_BEGIN ) ; Pos = 20 FileWrite($hfile, $bInsert) FileClose($hFile) ==> Info : A better way to work with binary data is to use a struct ! I would advise you to always create a backup of the file before you change it - safety first

If it's OK to compile your file to x64, I would recommend to do it by including #AutoIt3Wrapper_UseX64=Y at the start of your script. According to my experience, a file compiled to x64 is not flagged by MS Defender.

"Once upon a time ..." than I've made the following: But now exist a new version of the "quricol.dll" for 32 and 64 bit. All parameters can be used now. In the old thread you can see, that is implemented with the help of @TheXman . Thanks for that. Then I revised the GUI and I came up with new possibilities. This has now resulted in a much more powerful tool, which is why I decided to create a new thread on this topic. There are 3 components:     QRCreator.au3         This is the base UDF that need for all. You can write your own applications by using it.     QRCreatorUI         This is the graphical User Interface to deal with all functions of the UDF.         As a special feature, you have a preview that can be enlarged.     QRCreatorCI         This is the Commandline Interface.          With the exception of HBITMAP generation, which is not required on the command line, you can perform all functions of the UDF to generate QR codes. Here more in detail: QRCreator.au3 - functions   _QR_generatePNG        Generates the QR-Code as PNG file for the passed text.   _QR_generateBMP        Generates the QR-Code as BMP file for the passed text.   _QR_getHBitmap        Creates a HBITMAP handle for the QR-Code for the passed text.         Don't forget to delete it, if no more need (_WinAPI_DeleteObject(HBITMAP)).   _QR_copyToClipboard        Copies the QR-Code picture for the passed text to the clipboard.   _QR_FileDefault       Generates a default filename (QR_YYYYMMDD_hhmmss)   _QR_getLastCall()      Asks for the result of the last call (_QR_getHBitmap/_QR_copyToClipboard/_QR_generateBMP/_QR_generatePNG)      Gets a structure with: .success(1/0) .error(@error) .width .type(B/C/[F/R]) .output(hBMP/''/fullpath) .margin .sizept .corrlevel      Types(.type): B (HBITMAP), C (Clipboard), F (File created), R (resized file created) The following parameters will used:   $_sText     The text to encode. Full unicode is supported.   $_sPathOut (ONLY: _QR_generatePNG und _QR_generateBMP)     The full path of the file to create. If only a filename has passed the @ScriptDir will used.     Without a filename the default filename will used (QR_YYYYMMDD_hhmmss).     If the filename exists, it will get a suffix (1..n) until it's unique.   $_iMargin       The QR-Code margin in px   $_iSizePt       Size of the points in the QR-Code (1-4, depends by the correction level)     If a wrong value is passed, it will corrected by the script.   $_iCorrLvl       The used correction level (0-3). Allows to read a QR-Code if some parts damaged.   $_iOutSize (ONLY: _QR_generatePNG und _QR_generateBMP)     As a new feature you can pass a target size for created file.      The size of the file depends by used correction level and the size of created points.      If you pass a value for width (and so for heigth too), the default by the dll created file will resized for this size.      If the passed size is to small it raises an error.   $_iScale (ONLY: _QR_copyToClipboard)     Also new is the ability to scale up the QR-Code copied to clipboard.      It's a factor for linear scaling, based on the default creation size by the dll call. QRCreatorUI.au3   All information for the actions you've done will shown in the statusbar of the GUI.    But this is my own statusbar, that allows formatting. I've attached them too. QRCreatorCI   available command line parameters   ---------------------------------------------------------------------------------------------------------------    REQUIRED NEW: Passing multi-line text via command line break=Placeholder character for a line break (default is ^) Must only be set if the default value is not to be used. For single-line text that contains the default placeholder, set "break=none"! If break is set, this must always be the first parameter!      text=Text for encoding    OPTIONAL      file=path/filename[.ext]  - If ommited, the default will used: @HomeDrive & @HomePath & "\QR_YYYYMMDD_hhmmss"      type=png,bmp,clip         - If ommited, 'png' will used. With clip runs CopyToClipboard.           or combined png/bmp    If file has .ext and type is passed but is different to .ext than will used type      width=int                 - (and height) initializes a resizing of the default created QR-Code                                  Resizing fails, if passed size is smaller as the default generated file.                                REMARK: Only for file creation      scale=int                 - Factor for up scaling the QR-Code                                REMARK: Only for CopyToClipboard      margin=4                  - The margin around the QR-Code in px (Default = 4)      corrlevel=0               - Up to 7%, 15%, 25% or 30% damage [0, 1, 2, 3]. (Default = 0)      sizept=2                  - The size of the painted pixel itself. The value depends on the correction level.                                  Only the smallest point size can be used for the largest correction level.                                  The value will corrected automatically, if wrong.   ---------------------------------------------------------------------------------------------------------------   return values   ---------------------------------------------------------------------------------------------------------------   comma separated string with:     ERROR=@error     RESULT='FullFilePath' or 'CLIPBOARD'     SIZE=width x heigth     SIZEPT=The really used (may be corrected) size of point     MARGIN=The used margin size     CORRLEVEL=The used correction level   --------------------------------------------------------------------------------------------------------------- You find all the stuff also in the function headers. So that you get an impression, here are a few pictures. Gallery QRCode.zip QRCreatorUI.au3 QRCreatorCI.au3