Leaderboard

I want to present BETA Version of my ADO.au3 UDF. This is modifed version of _sql.au3 UDF. For that I want to thanks : ; Chris Lambert, eltorro, Elias Assad Neto, CarlH This is first public release , and still is as BETA DOWNLOAD LINK (in download section): Have fun, mLipok EDIT: 2016-06-03 Below some interesting topics about databases: EDIT 2016/07/04: For more info about ADO look here: https://www.autoitscript.com/wiki/ADO FOR EXAMPLE DATABASE use AdventureWorksDW2016_EXT.bak from: https://github.com/microsoft/sql-server-samples/releases/download/adventureworks/AdventureWorksDW2016_EXT.bak I will relay on this database in my examples. Here is link to post which shows how "ODBC Data Source Administrator" looks like.

Version 3: Ops, you may ask, where's the version 2? The answer is, you will never see it. I skipped it to jump to version 3 directly. Why? Actually, I didn't learn M$ about that versioning The reason is, I planed to write version 2, using the new window/control handle indexing technique to eliminate all the ugly and slow loop. But when nearly finish, I feel so tired, tired of using a lots of all workaround. And finally, I decided to rewrite entire the UDF, using the direct solution, the way all other languages used, and should use. I late some day, because of some machine code (it's actually not so necessary, but if the control is doing an expensive task, like heavy drawing then passing all the Window Message to AutoIt is not a so good idea because its slow speed may result in some annoying-small-but-easy-to-figure-out problems, (like tearing as example). So I use machine code directly to pass over it. Now you have not a Stupid but a Smart UDF And it's still simple. API change: Remove a parameter from _SSCtrlHover_Register. You nolonger can attach other controls to the registered control. Use another method to do it and when you delete the control be sure to delete all the attached controls yourself. This breaks your old script. Add double click event (last 2 parameters of _SSCtrlHover_Register) Remove the _SSCtrlHover_Delete. You must manually delete yourself. It's easy with GUICtrlDelete and I decide not to duplicate this function to my UDF (be sure to delete your attached control too) This version eliminate all the odd limit of old version, include: No:longer use timer/adlib to test the control is on mouse event. Now it directly use native WinAPI method to provide a truly event-driven way. Every click is detected, every mouse hover/left, is handled perfectly. Fast and very fast. All the loop is eliminated. Machine code. Execute speed is much much improved. (read as: nano seconds instead of milliseconds ) I documented it quite well so if you want you can easily browse it and change it the way you want. Now you can use in both GUIGetMsg() loop mode or event mode. No longer setting constants like before because it works perfectly in both mode. Cheer Remark: I don't include <WinAPI.au3> and <WinAPIShellEx.au3> in my UDF, because those UDF is very large and it will consume much more memory when you run (not matter you run the 'compiled' exe, the au3 file, or the .a3x file). In the CtrlHover UDF, i included a small subset of those UDF with the same name, so if you have already included <WinAPI.au3> or <WinAPIShell.au3>, be sure to edit the UDF and comment out the corresponding region. Edit 2: Reorganize script. Fix some issues when drag too fast. Add ability to handle "click" (work RIGHT as normal button, will not fire if you only release the mouse button upon the control as some UDF use MouseUp event) Add a helper method to check if MouseUp event is click event or not. Add compability function to call as normal UDF (with first letter is underscore). Edit 1: Add some function descriptions as JS's advice. Thank you I also changed script name (shorter) and modify the register function so it may be called with less parameter. From now on, the function name and calling syntax will be fixed. OK, I know there is the famous "GUICtrlOnHover" UDF already in this forum, and many people have used it and enjoyed it! But the UDF didn't work as I expected . So I wrote an UDF myself, as much simple as possible, and it works out of the box It has some advantages compare to the old GUICtrlOnHover.au3 It creates the normal button behavior. When you press primary mouse button in the control and begin to drag, it do not set other controls to "hover" state. Faster. I try to add 2k controls. When mouse change from one control to another, it only take about 25ms to handle. In idle state (mouse cursor is not over any control), the cost is ignorable with < 0.1ms. Compare with GUICtrlOnHover UDF takes about 3ms when mouse cursor is over the control, but in idle state, it takes about 35ms. (I do not know why) (That is, because I tested script with overlapped controls. GUICtrlOnHover rely on WinAPI function WindowFromPoint(), which return the first created control (the control with is overlapped any others), but my script rely on GUIGetCursorInfo() which return the last created control - which is the most nested control in Windows). So my script need to check entire 2k control, but GUICtrlOnHover return the first element. I will wait for information about GUIGetCursorInfo() to decide that my UDF should use WinAPI function instead of the native function. In the normal usecase and controls is not overlapped, my UDF is far faster. Edit: Add a setting constant, make you ability to choose use WindowFromPoint() or GUIGetCursorInfo(). Default to the WinAPI function) Faster time to create/ register control. Native AutoIt. No Callback. The only DllCall I use is to get parent window of a control. Wonder why AutoIt do not have a similar function. Found a new bug #2899. If someone can ad more functinal to WinGetHandle("[LAST]"), it should be great Edit: Use some other WinAPI call to provide workaround for issue with GUIGetCursorInfo. Smaller size, about 280 lines compare with about 400 lines of GUICtrlOnHover. More simple, more easy to use. No more than 120 characters in one line. No annoying jumping when scroll the UDF Support event mode to detect mouse down event. But it doesn't work with overlay control. So you cannot have a control (with event) over another control. (use $_BGUIGETCURSORINFOFIX const setting to get rid of this). It seems that it's a AutoIt bug, the GUIGetCursorInfo return a useless control id when controls overlapped. Its not the same with the control received with WindowFromPoint(), or the control which fire event (anyone can confirm it's a bug? Or it's a special feature? ) ( I open a new Trac Ticket here: #2900) Current limit: Mouse down Almost all mouse event is currently detected by timeout (this is why the script called Simple and Stupid, but every UDF I found in this forum also use this method). You can set a smaller timeout to catch the mouse, but sometimes its annoying. Edit: Default changed to 30ms timeout, it should be fast enough to detect any click! You can also change to use event mode to detect click better! Otherwise, it works like a charm. Try it and happy with it Example: Callback function #include "SSCtrlHover.au3" GUICreate(@AutoItVersion) $idLbl1 = GUICtrlCreateLabel("Label 1", 5, 5) SSCtrlHover_Register($idLbl1, "FnNormal", 0, "FnHover", 0, "FnActive", 0, "FnClick", 0) $idLbl2 =GUICtrlCreateLabel("Label 2", 5, 35) SSCtrlHover_Register($idLbl2, "FnNormal", 0, "FnHover", 0, "FnActive", 0, "FnClick", 5) GUISetState() While GUIGetMsg() <> -3 Sleep(10) WEnd Func FnNormal($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "Normal/Leave " & $idCtrl) EndFunc Func FnHover($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "Hover " & $idCtrl) EndFunc Func FnActive($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "Active " & $idCtrl) EndFunc Func FnClick($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "CLICK! " & $idCtrl & " - " & $hWnd & " - " & $vData) EndFunc You can use it with GUICtrlSetImage to provide a "hover button" effect Version 1: SSCtrlHover.au3 Version 3: SSCtrlHover.zip

And with that, the thread is locked and you go on Moderation Future posts will need to be approved before they appear on the forum; no patience for this kind of thing.

Characters don't use just the colour table, each character also has attributes. By default these are set to be white text on black background (see here). I wrote a function to set the colour table, and another to set attributes. Try playing around with combinations. With setting the colortable, everything is blue (as you'd expect with all the colours being the same). #include <Array.au3> #include '..\Console.au3' _Console_Alloc() Local $ColorTable[16] = [0xFFFFFF, 0xFF0000, 0xFF0000, 0xFF0000, _ 0xFF0000, 0xFF0000, 0xFF0000, 0xFF0000, _ 0xFF0000, 0xFF0000, 0xFF0000, 0xFF0000, _ 0xFF0000, 0xFF0000, 0xFF0000, 0xFF0000] $aOldColors = _Console_GetScreenBufferColorTable() ;~ _ArrayDisplay($aOldColors, 0xFF0000) ;~ $fSuccess = _Console_SetScreenBufferColorTable(-1, $ColorTable) ;~ If Not $fSuccess Then MsgBox(0, "Error (ColorTable)", @error & @CRLF & @extended) $fSuccess = _Console_SetScreenBufferAttributes(-1, BitOR($FOREGROUND_BLUE, $FOREGROUND_GREEN, $FOREGROUND_INTENSITY, $BACKGROUND_BLUE)) If Not $fSuccess Then MsgBox(0, "Error (Attributes)", @error & @CRLF & @extended) ;~ $aNewColors = _Console_GetScreenBufferColorTable() ;~ _ArrayDisplay($aNewColors, 0xFF0000) _Console_SetTitle("Hey look =P") _Console_Write("Hello, World!" & @LF) _Console_Pause() _Console_SetScreenBufferColorTable(-1, $aOldColors) _Console_Free() Func _Console_SetScreenBufferAttributes($hConsoleOutput, $iAttributes, $hDll = -1) If $hConsoleOutput = -1 Then $hConsoleOutput = _Console_GetStdHandle($STD_OUTPUT_HANDLE, $hDll) If $iAttributes = Default Then $iAttributes = 0 ; Get current buffer info $tConsoleScreenBufferInfoEx = _Console_GetScreenBufferInfoEx($hConsoleOutput, $hDll) If @error Then Return SetError(1, @error, False) ; Modify attributes $tConsoleScreenBufferInfoEx.Attributes = $iAttributes ; Set new buffer info $fSuccess = _Console_SetScreenBufferInfoExEx($hConsoleOutput, DllStructGetPtr($tConsoleScreenBufferInfoEx), $hDll) If Not $fSuccess Then Return SetError(2, @error, False) Return True EndFunc ;==>_Console_SetScreenBufferAttributes Func _Console_SetScreenBufferColorTable($hConsoleOutput, $aiColorTable, $hDll = -1) If $hConsoleOutput = -1 Then $hConsoleOutput = _Console_GetStdHandle($STD_OUTPUT_HANDLE, $hDll) If Not IsArray($aiColorTable) Then Return False If UBound($aiColorTable, 0) <> 1 Then Return False If UBound($aiColorTable, 1) < 16 Then Return False ; Get current buffer info $tConsoleScreenBufferInfoEx = _Console_GetScreenBufferInfoEx($hConsoleOutput, $hDll) If @error Then Return SetError(1, @error, False) $tConsoleScreenBufferInfoEx.Attributes = BitOR($FOREGROUND_RED, $FOREGROUND_BLUE, $FOREGROUND_GREEN, $BACKGROUND_RED, $BACKGROUND_BLUE, $BACKGROUND_GREEN) ; Modify color table For $i = 0 To 15 DllStructSetData($tConsoleScreenBufferInfoEx, "ColorTable", $aiColorTable[$i], $i + 1) Next ; Set new buffer info $fSuccess = _Console_SetScreenBufferInfoExEx($hConsoleOutput, DllStructGetPtr($tConsoleScreenBufferInfoEx), $hDll) If Not $fSuccess Then Return SetError(2, @error, False) Return True EndFunc ;==>_Console_SetScreenBufferColorTable Regards, Mat To clarify since it's not apparent from MSDN, the index in the colour table is with the bits of the attribute in the order IBGR.

Added here: https://www.autoitscript.com/wiki/User_Defined_Functions#Internet_protocol_suite

@FMS, Are you sure that the ID in your table is a string? ... where id = '1'; -- queries for id being the string '1' ... where id = 1; -- queries for id being the integer 1

sunshinesmile84, You most certainly can select text colour with my UDF - and lots of other options as well. M23

I'd like to start by saying that this is not a network discovery tool, I keep wishing that it was and maybe through WMI I could accomplish that some day, but this tool is fast enough to execute that no users have ever minded a 10 second interruption in their workday as of yet. (I know some tools exist on the forum for domain environments, but many offices are workgroup and I have had no luck in using those...) Now that I have stated what it is not, what this tool does is gathers the following information: The computer's nameThe operating system, architecture, service pack level, and COAThe local usersIf MS Office is installed, gathers the version(s) and COAThe CPU name and speedInstalled RAM, free RAM, and swap file infoLocal drive letters, labels, total and free space, and percent fullNetwork drive letters, their UNC path, total and free space, and percent fullThe computer's IP addressOptional notes, such as "front desk PC" or "runs slow", whatever is helpful to know laterAll of that is bundled in to a CSV file, with the options of creating a new CSV for each machine named the same as the computer's name, an append mode that you can name after the site, or the cool part - there is an option to create a customized agent. In the customized mode, you pre-define the site name and a network path accessible by all machines, and the script will create a new customized script with those details hardcoded and compile it for you! Then all you have to do is get on to any networked pc and browse to the path, run the agent, and in 2 seconds you're done with that machine. Please pay attention to the files required to compile at the top of the script - I know it is a long list but only 2 are required to be downloaded from the forum, the rest are in the AutoIt install folder in Includes or aut2exe folders. I could have included the paths in the code, but found this was just.....nicer (for me). I have found this to be very helpful, and I even had one client thank me for doing it, as he realized the value of me having all of that information if he had a problem. Hopefully there are some other field techs out there, or folks in charge of their office's IT needs, who can also benefit from this. Another benefit for field techs is that with this list you can easily review it later and then call them up a few days later to tell them what upgrades they need and get a re-visit Enjoy Ian EDIT: Updated code to include a couple bug fixes Audit Tool.au3