Leaderboard

@GSPitman welcome to the forum. A couple of questions: Unlock McAffee Solidcore - Try the AutoIt Window Info tool (in the same directory where you installed AutoIt) and hover over the password prompt. What does it return? Install Vigilix - Is this an EXE or MSI? Does it support a silent install? If so, you can use either ShellExecuteWait or RunWait to install this.

Try this, work for me #RequireAdmin MsgBox(0, 0, @UserName) MsgBox(0, 0, _GetUsername()) Func _GetUsername() Local $aResult = DllCall("Wtsapi32.dll", "int", "WTSQuerySessionInformationW", "int", 0, "dword", -1, "int", 5, "dword*", 0, "dword*", 0) If @error Or $aResult[0] = 0 Then Return SetError(1, 0, 0) Local $sUsername = BinaryToString(DllStructGetData(DllStructCreate("byte[" & $aResult[5] & "]", $aResult[4]), 1), 2) DllCall("Wtsapi32.dll", "int", "WTSFreeMemory", "ptr", $aResult[4]) Return $sUsername EndFunc ;==>_GetUsername If someone is expert of DllCall check please if all parameter are correct

AutoIt ou AHK? Pick your choice and stick to it. For AutoIt use AutoIt help.

No surprise here: you get exactly what you ask for. Q - "What do you think a random binary hash looks like, once interpreted as a string?" A - "Unicode garbage"

Read https://www.autoitscript.com/wiki/Recursion

Sure. _ADO_Connection_Create _ADO_Connection_OpenConString _ADO_Execute _ADO_Recordset_ToArray _ADO_RecordsetArray_GetContent now try to open second connection: _ADO_Connection_Create _ADO_Connection_OpenConString and using array which you get from _ADO_RecordsetArray_GetContent you can use a For To Next loop to update each values in second database of cours using: _ADO_Execute

Provided that all logons are local (type 2) this will work, if you have network logons you need to add type 3 as well #requireadmin #include <AutoItConstants.au3> $sCommand = "powershell Get-EventLog -logname 'Security'" $sMessage = '-InstanceID "4624"' $iPID = run($sCommand & " " & $sMessage & "| Format-List", "" , @SW_HIDE , $stdout_child) $sOutput = "" while 1 $sOutput &= StdoutRead($iPID) If @error Then ExitLoop WEnd ProcessClose($iPID) $aOut = stringsplit($sOutput , @LF , 2) $flag = 0 For $i = 0 to ubound($aOut) - 1 If stringinstr(stringstripws($aOut[$i] , 8) , "LogonType:2") Then $flag = 1 If stringinstr($aOut[$i] , "Account Name:") And $flag = 1 Then msgbox(0, 'Last Logged On' , $aOut[$i]) ExitLoop EndIf Next

After several months pondering how to make the best possible plugin architecture, I have come up with an answer. The code is still in an infancy stage and will require work before it can be applied in "real" projects (PM me if you do want to use this and I'll tag along). What I've made allows you to load an Au3 script file at runtime and call methods in it. This script doesn't have to implement or change anything. Combine this with other functionality such as what Eval offers and (shameless self promotion ftw) and this has many different possibilities. There often seems to be some differences in what people expect a plugin architecture should support, but here is what I support: Sometimes the services interface is not included because it's not needed (say other people). That is what I call a one-way plugin architecture, only the main script can call plugin functions. The architecture in the picture is what I call a two-way plugin architecture and that's what I will be demonstrating in this thread. Firstly, I have created a one way plugin architecture. With the provided libraries, one can do this: plugins\hello world.au3: Func HelloWorld($str) MsgBox(0x40, @ScriptName, $str) EndFunc plugin loader.au3: #include "lib\reflection.au3" ; Demonstrating simple plugin loading, one-way ; This can be used when the main script knows which functions are in the plugin and how to use them ; and the plugin does not need to use any functions in the main script (more rare than you think) $script = _RDoFile("plugins\hello world.au3") $script.HelloWorld("Something different this time") $script.Quit() The _R prefix stands for "_Reflection", because that's what I hope to do eventually fully support with this library. What happens in this example is that the reflection library: Reads the script from the .au3 file, modifies the script so that it can export its function, stores the au3 file as temp.au3, runs it. For curious minds, the temp.au3 file that is generated looks as following. This is a technique that I call "COM server injection". (And here you can see why I said the project is in its infancy) #NoTrayIcon ;tehee #include "lib\AutoItObject.au3" Global $oError = ObjEvent("AutoIt.Error", "_ErrFunc") Func _ErrFunc() Return EndFunc _AutoItObject_StartUp() Global $oObject = _SomeObject() Global $hObj = _AutoItObject_RegisterObject($oObject, "Manadar.AutoIt.Plugin") While 1 Sleep(100) WEnd _QuitObject(0) Func _SomeObject() Local $oClassObject = _AutoItObject_Class() $oClassObject.AddMethod("HelloWorld", "HelloWorld") $oClassObject.AddMethod("Quit", "_QuitObject") Return $oClassObject.Object EndFunc Func _QuitObject($oSelf) _AutoItObject_UnregisterObject($hObj) $oObject = 0 Exit EndFunc ; ============= ACTUAL SCRIPT ============= Func HelloWorld($o___________________o, $str) MsgBox(0x40, @ScriptName, $str) EndFunc The reflection library _RDoFile function uses a method to extract all the functions from the original script, and generates the correct $oClassObject.AddMethod calls when generating the COM object. The while-loop that is added before the script is optional. It can be disabled with another parameter in _RDoFile and eventually there will be various ways to initialize scripts this way, either partly or completely. This parameter is necessary for two-way plugins, but we'll see that later on. This shows how simply it is to load an Au3 file and do a bit of "reflection" magic on the code. It greatly increases the versatility and capabilities of AutoIt scripts. The function in its current state can not load Au3 files when the plugin loader script is compiled but that is almost trivial to add. Now we take a look at two-way plugins, here is the plugin loader script: ; Demonstrating plugin loading, two-way ; Both the plugin and the main script provide an interface ; This is the most common way to deal with plugins ; You simply load the plugins and the plugin defines the additional behavior, ; by adding items to your menus and handling the functionality for them etc. $o = _RImplementInterface("pluginterface.au3", "Manadar.AutoIt.Main") $called = False $script2 = _RDoFile("plugins\hello forums.au3", True) While Not $called Sleep(100) WEnd Func Print($obj, $s) $called = True MsgBox(0x30, "", $s) EndFunc We see in this example that the plugin loader script wants to expose a function called 'Print', but this could be anything and any number of functions. The plugin is written as follows (most ideal case, and actually works): plugins\hello forums.au3 #include "pluginterface.au3" Print("Hello AutoIt forums!") Via the one-way plugin architecture method we can load the plugin, we read the contents, apply COM injection magic, run the script, done. But the same method does not work the other way around because our main script is already running (and COM injection requires restart). What we can do, is let the main script create a COM server which does not require a restart. We do this via the call to _RImplementInterface, this function gets the functions from the pluginterface.au3 file and creates a COM server which exposes these methods to the outside. The pluginterface.au3 file functions connect to the plugin loader script and forward any calls from the plugin there. The pluginterface.au3 file looks like this and it is possible to entirely automatically generate this file (just when you were thinking: I need to write dumb code for this to work? Lame.): #include "lib\reflection.au3" $main = _RAttach("Manadar.AutoIt.Main") ; just a call to _AutoItObject_ObjCreate() with cbi: Func Print($s) $main.Print($s) EndFunc With this approach, we have built a fully two-way interface. The code "needs work" and I put this in various comments through the attached files, but the needs work comments are not complete. Some ideas for the future: - COM server injection also exposes global variables like: $script.g_sVar - Automatic generation of the services interface - Very complete reflection library, with the library itself also object oriented ($script.GetMethods()[0].Call() capability) - Support of these features (or similar) in native AutoIt: #1931 Attached I have the examples used in this thread, the reflection library and a version of AutoItObject that supports this (v1.2.4.0 I believe). The examples should work "out of the box" with AutoIt v3.3.6.1 (latest stable atm). Edit: Forgot to attach file. (Really, Manadar, Really?) Reflection Au3.zip

provides .gif and .ani animation to AutoIt, now supports all gif formats (GIF87a and GIF89a). v1.6 now even displays dynamic gifs with GDIplus. Cute and nice additions to your scripts. i hope you like it. Please leave comments. This is another final and maybe last version, as far as i can see. The UDF: _Ani.au3 [autoit]#AutoIt3Wrapper_AU3Check_Parameters= -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 #cs ;#=#INDEX#============================================================================================================================# ;# Title .........: _Ani.au3 ;# Description ...: Animated Controls (.ani/.gif) for AutoIt. ;# Date ..........: 31.05.09 ;# Version .......: 1.6 (some minor bugs fixed, added _Ani_SetGifExFrame) ;# History .......: 26.05.09 v 1.5 (added GDIplus based functions - now all GIFs should be working ! , using controlhandles instead of control IDs, bug fixing) ;# 23.05.05 v 1.4 (added _Ani_GetGifInfo(), some errors fixed, accelerated decoding, code cleaning) ;# 22.05.09 v 1.3 (GIF87a support, slow mode for problematic gifs, minor improvements) ;# 21.05.09 v 1.2 (improved timer handling, negative speed, immediate speed reaction, functions added, reduced number of callbacks, minor corrections, code designed) ;# 20.05.09 v 1.1 (added gif support, included timer functions, minor corrections) ;# 19.05.09 v 1.0 ;# Author ........: jennico (jennicoattminusonlinedotde)

#include <Array.au3> #include <Constants.au3> #include <WinAPI.au3> Global $avChildren Run('calc.exe') WinWaitActive('Calculator') $hWnd = WinGetHandle('Calculator') WinListChildren($hWnd, $avChildren) _ArrayDisplay($avChildren) Exit Func WinListChildren($hWnd, ByRef $avArr) If UBound($avArr, 0) <> 2 Then Local $avTmp[10][2] = [[0]] $avArr = $avTmp EndIf Local $hChild = _WinAPI_GetWindow($hWnd, $GW_CHILD) While $hChild If $avArr[0][0]+1 > UBound($avArr, 1)-1 Then ReDim $avArr[$avArr[0][0]+10][2] $avArr[$avArr[0][0]+1][0] = $hChild $avArr[$avArr[0][0]+1][1] = _WinAPI_GetWindowText($hChild) $avArr[0][0] += 1 WinListChildren($hChild, $avArr) $hChild = _WinAPI_GetWindow($hChild, $GW_HWNDNEXT) WEnd ReDim $avArr[$avArr[0][0]+1][2] EndFunc Don't list all child controls of me