Leaderboard

The AutoIt DllCall() function can only be used to execute functions in dll-files implemented in unmanaged languages such as C, C++ and Pascal. The DllCall() function cannot be used to execute functions in .NET assembly dll-files implemented in managed languages such as C#, F# or VB.NET. With an AutoIt background, the DotNetAll.au3 UDF as implemented in Using C# and VB.NET Code is by far the easiest way to execute C# or VB.NET code directly within an AutoIt script. This is a slightly simplified version of the C# code. COM visibility is handled by the DotNetAll.au3 UDF. Test.cs: using System; public class Operation { public int Add(int x, int y) { int z; if ((x == 10) && (y == 20)) { z = x + y; } else { z = x; } return z; } } And the AutoIt code. Test.au3: #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 #AutoIt3Wrapper_UseX64=Y Opt( "MustDeclareVars", 1 ) #include "DotNetAll.au3" Example() Func Example() ; Create $oOperation object Local $oNetCode = DotNet_LoadCScode( FileRead( "Test.cs" ), "System.dll" ) Local $oOperation = DotNet_CreateObject( $oNetCode, "Operation" ) ; Now the Add() function can be executed Local $z = $oOperation.Add( 10, 3 ) ConsoleWrite( "$oOperation.Add( 10, 3 ) = " & $z & @CRLF ) $z = $oOperation.Add( -5, 20 ) ConsoleWrite( "$oOperation.Add( -5, 20 ) = " & $z & @CRLF ) $z = $oOperation.Add( 10, 20 ) ConsoleWrite( "$oOperation.Add( 10, 20 ) = " & $z & @CRLF ) EndFunc Run the AutoIt code in SciTE with F5. The C# code doesn't need to be registered. Output in SciTE console: $oOperation.Add( 10, 3 ) = 10 $oOperation.Add( -5, 20 ) = -5 $oOperation.Add( 10, 20 ) = 30 The benefits of the DotNetAll.au3 UDF are: The .NET source code can be easily written in SciTE without the need for a specific development tool The .NET code is compiled and executed directly in your AutoIt script, where you apply the code If the AutoIt script is run in SciTE with F5, .NET error messages appear in the console The .NET code can be easily distributed in the form of source files (text files) You avoid the registration/unregistration tyranny of .NET assembly dll-files Another way to execute C# code is briefly described in this post. This method requires an IDE to compile the C# code into a .NET assembly dll-file and it requires the dll-file to be registered/unregistered. All required code is contained in the 7z-file: Operation.7z

I found a good way to alter the grayed (disabled) text color, becoming totally black. It looks much nicer for your script (an edit control appearing like a label) : #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include <WinAPISysWin.au3> Local $iSaveGrayTextColor = _WinAPI_GetSysColor($COLOR_GRAYTEXT) ConsoleWrite("Original gray text color = " & $iSaveGrayTextColor & @crlf) ; 10070188 on my PC _WinAPI_SetSysColors($COLOR_GRAYTEXT, 0) ; force gray text to black during the script Local $hForm = GUICreate('Test' , 400, 250) GUICtrlCreateLabel("", 10, 10, 380, 100, -1, $GUI_WS_EX_PARENTDRAG) ; => $Input1 draggable Local $Input1 = GUICtrlCreateEdit('No caret inside + Not selectable', 10, 10, 380, 100) GUICtrlSetState(-1, $GUI_DISABLE) Local $Input2 = GUICtrlCreateEdit('Caret inside + selectable', 10, 110, 380, 100) Local $Button = GUICtrlCreateButton('Exit', 300, 220, 90, 20) Local $msg GUISetState() While 1 $msg = GUIGetMsg() If $msg = $GUI_EVENT_CLOSE OR $msg = $Button Then ExitLoop WEnd _WinAPI_SetSysColors($COLOR_GRAYTEXT, $iSaveGrayTextColor) ; restore the original color (+++) Exit

GuiBuilderPlus GuiBuilderPlus is a small, easy to use GUI designer for AutoIt. Originally created long ago as AutoBuilder by the user CyberSlug, enhanced as GuiBuilder by TheSaint, and further enhanced and expanded as GuiBuilderNxt by jaberwacky, GuiBuilderPlus is a continuation of their great work, with a focus on increased stability and usability followed by new features. ------ Yes, I have decided to bring back our old friend the GuiBuilder. This utility has a long history, which you can read about in TheSaint's Gui Creators topic, starting all the back back with CyberSlug's AutoBuilder. Even though I've hacked the original code to pieces in order to document and better understand what is going on, the essence of GuiBuilder still lives on! I am using the awesome updates from GuiBuilderNxt by jaberwacky as a starting point since he already did a lot of the hard work of parsing and updating the original code, plus I really like the layout that came about from that update. Unfortunately development seems to have stopped in 2016. Not sure how much interest there is in this, but suggestions and bug reports are welcome. See Full Changelog: Download the latest version: v1.3.0 (2024-03-24) GuiBuilderPlus v1.3.0 - 2024-03-24.zip FIXED: Wrong line endings when copying from code preview window FIXED: Issue changing properties when Obect Explorer window is not open FIXED: Issue when selecting controls under certain other conditions FIXED: SaveAs keyboard shortcut FIXED: Undo/Redo for Global property ADDED: Auto-size property for Labels, Buttons, and Inputs GitHub Repository: https://github.com/KurtisLiggett/GuiBuilderPlus

Danyfirex's first suggestion for VBVMR_GetParameterFloat, where he used float* for the second parameter, works fine. The one I use is very similar except it is set up as an API wrapper function (see below). You keep referencing "Strip[1].A1" for the parameter. You're aware that you are referencing the 2nd strip, not the first one, since the strip indexes starts at 0, right? (See the Input Strip Parameters section in the API PDF for details) Could that be the reason you aren't seeing the expected value? The image below shows the test settings on the first strip in my Voicemeeter (not Voicemeeter Banana): When I run my script against it, using my API wrappers, I get the following info written to the console: DllOpen successful VBVMR_Login successful VBVMR_IsParametersDirty = False VBVMR_GetVoicemeeterType = VoiceMeeter VBVMR_GetVoicemeeterVersion = 1.0.8.2 Strip[0].Color_y = +0.90 Strip[0].Color_x = -0.15 Strip[0].Mono = 1 VBVMR_Logout executed DllClose executed The 3 strip parameters, in the console output above, uses the following API wrapper function in my script. As you can see, it passes back valid float values. For example, I used VBVMR_GetParameterFloat("Strip[0].Mono") in my test script to get the first strips Mono setting. Func VBVMR_GetParameterFloat($sParamName) Local $aResult ;Call API $aResult = DllCall($ghVMDll, "long", "VBVMR_GetParameterFloat", _ "str" , $sParamName, _ "float*", 0) If @error Then Return SetError(-99, @error, -99.0) If $aResult[0] <> 0 Then Return SetError($aResult[0], 0, -99.0) Return $aResult[2] EndFunc This a sample of how I called the wrapper function in my test script: ;Display Strip[0].Color_y value $sParam = "Strip[0].Color_y" $fValue = VBVMR_GetParameterFloat($sParam) If @error Then MsgBox($MB_ICONWARNING + $MB_TOPMOST, "ERROR", _ "VBVMR_GetParameterFloat error occurred." & @LF & @LF & _ "@error = " & @error & @LF & _ "@extended = " & @extended) Exit EndIf ConsoleWrite(StringFormat("%-27s = %+0.2f", $sParam, $fValue) & @CRLF) For the record, all of the VBVMR APIs, except 1, pass back a LONG return code. All of the DllCalls in your original post that have "NONE" as the return code, should have "LONG". For instance, the VBVMR_Login declaration in the header file is: /** @name Communication Login / logout * @{ */ /** @brief Open Communication Pipe With Voicemeeter (typically called on software startup). @return : 0: OK (no error). 1: OK but Voicemeeter Application not launched. -1: cannot get client (unexpected) -2: unexpected login (logout was expected before). */ long __stdcall VBVMR_Login(void); So the corresponding AutoIt DllCall would be something like: $aResult = DllCall($ghVMDll, "long", "VBVMR_Login") If you aren't correctly defining and checking the return code after executing the API, then it is very difficult to tell if the API call was successful or not. If it wasn't, it's the return code that will let you know why. Lastly, there are several "return values" that you need to be aware of when using DllCalls. All of them are important and, in my opinion, all should be checked. There's @error and the array returned by the DllCall function itself. There's the return code/value that is returned in array[0] after a successful API call, if it has a return code defined. And there's the parameter values passed back from the API function call, if any exist. So when you refer the return codes and values, you need to be specific as to which ones you are referring to. Looking at some of your previous posts, you seems to be getting the return code from the API function mixed up with the parameter values that are passed back from the API call. Hopefully that helps.

..why not set your alarm in your phone ?

..or with source https://github.com/hmphus/there-edge/tree/main/BrowserProxy if someone can tweak it

AutoIt v3.3.16.0 has been released. Thanks to @jpm and the MVPs who were responsible for the majority of code in this version. Download it here. Complete list of changes: History

What I don’t understand is why you install all those applications? What do you install them on? How many computers do you have? And a lot of those applications don’t look like their work related anyway so I really don’t understand the need for this but anyway use silent install for everything that you want to install as mentioned above If they do not support silent installs then I would use control click to automatically click buttons

Hi there, glad my code was able to help you get started with incorporating Webview2 into AutoIt! I haven't updated that post in a while but I've wrapped more of the functionality since then. Certainly not all of it because I don't have a use for a lot of the methods right now. Awesome you were able to pick this up for the AutoIt community!