Leaderboard

Incremental search is usually implemented by drawing the background of the substrings that matches the search string with a specific color eg. yellow. Incremental in this context means that the search is performed dynamically after each character while the search string is typed. In a listview this can be implemented by owner drawing through the LVS_OWNERDRAWFIXED flag and WM_DRAWITEM messages. (A custom drawn listview supports coloring of fields. However, the coloring works best for whole fields. This doesn't make it applicable to incremental search.) Inspiration for the example is found in these two questions: Search box for names and Search In ListView (Redraw with matching string). Examples The zip file below contains three examples. Listview items are strings of random characters with different lengths. In all examples a global $iItems = 1000 in top of script specifies the number of rows. There are no performance issues up till 10,000 rows. Note that the search is performed in an array and not directly in the listview. A regular expression can be entered in the search box. Search strings like "m........." with a varying number of dots will result in a varying number of matches. To keep it simple only one occurrence of the search string in each item is tested. As soon as one occurrence is found the search loop moves on to next item. 1) Incremental text search.au3 The first example is a simple demonstration of basic functionality: F3 and Shift+F3 can be used instead of Next and Prev buttons. 2) Show matching rows only.au3 An owner drawn listview can easily be combined with a virtual listview to extend the functionality of the incremental search. A virtual listview is especially interesting if you want to dynamically update the listview to only display the rows that matches the search string. Such an update is very fast in a virtual listview. This example is useful if the listview contains a set of file names and you are searching for a specific file eg. to open the file. In this situation you are probably not interested in the files that doesn't match. Because the listview only contains matching rows "Next match" and "Prev match" buttons are disabled. Clear the search field to display all items. 3) Standard search dialog.au3 The last example is a demonstration of a standard search dialog as the search box in Notepad. FindText function in comdlg32.dll creates the standard search box. The function is implemented as _WinAPI_FindTextDlg in WinAPIDlg.au3. In the Microsoft documentation you can read: Note that the FINDREPLACE structure and the buffer for the search string should be a global or static variable so it does not go out of scope before the dialog box closes. Because the FINDREPLACE structure is created as a local variable in _WinAPI_FindTextDlg it goes out of scope as soon as the function returns. This implementation of FindText is used in the example: ;Func _WinAPI_FindTextDlg($hOwner, $sFindWhat = '', $iFlags = 0, $pFindProc = 0, $lParam = 0) Func _WinAPI_FindTextDlgEx(ByRef $tFR, $hOwner, $sFindWhat = '', $iFlags = 0, $pFindProc = 0, $lParam = 0) $__g_pFRBuffer = __HeapReAlloc($__g_pFRBuffer, 2 * $__g_iFRBufferSize) If @error Then Return SetError(@error + 20, @extended, 0) DllStructSetData(DllStructCreate('wchar[' & $__g_iFRBufferSize & ']', $__g_pFRBuffer), 1, StringLeft($sFindWhat, $__g_iFRBufferSize - 1)) ;Local $tFR = DllStructCreate($tagFINDREPLACE) $tFR = DllStructCreate($tagFINDREPLACE) DllStructSetData($tFR, 'Size', DllStructGetSize($tFR)) DllStructSetData($tFR, 'hOwner', $hOwner) DllStructSetData($tFR, 'hInstance', 0) DllStructSetData($tFR, 'Flags', $iFlags) DllStructSetData($tFR, 'FindWhat', $__g_pFRBuffer) DllStructSetData($tFR, 'ReplaceWith', 0) DllStructSetData($tFR, 'FindWhatLen', $__g_iFRBufferSize * 2) DllStructSetData($tFR, 'ReplaceWithLen', 0) DllStructSetData($tFR, 'lParam', $lParam) DllStructSetData($tFR, 'Hook', $pFindProc) DllStructSetData($tFR, 'TemplateName', 0) Local $Ret = DllCall('comdlg32.dll', 'hwnd', 'FindTextW', 'struct*', $tFR) If @error Or Not $Ret[0] Then Local $Error = @error + 30 __HeapFree($__g_pFRBuffer) If IsArray($Ret) Then Return SetError(10, _WinAPI_CommDlgExtendedErrorEx(), 0) Else Return SetError($Error, @extended, 0) EndIf EndIf Return $Ret[0] EndFunc Then it's ensured that the local variable that is used for $tFR in the script, does not go out of scope, while the search box is open. ListviewIncrSearch.7z 1) Incremental text search.au3 2) Show matching rows only.au3 3) Standard Find text dialog.au3 DrawItem.au3 GuiListViewEx.au3 WinAPIDlgEx.au3 You need AutoIt 3.3.14 or later. Tested on Windows 7 32/64 bit and Windows XP 32 bit. Comments are welcome. Let me know if there are any issues. (Set tab width = 2 in SciTE to line up comments by column.) ListviewIncrSearch.7z

Now replaced by a new version of the UDF in this link. <hr> [NEW VERSION] - 7 Mar 16 Added: A new option for $iAdded (+ 512) allows you to select just one cell of the ListView rather than the whole row. A new function _GUIListViewEx_SetDefColours allows the user to set the default colours when using either or both the "colour" and "single cell selection" options. Another new function _GUIListViewEx_BlockReDraw which prevents ListView redrawing during looped Insert/Delete/Change calls - this greatly speeds up execution by avoiding lengthy redrawing when using either or both the "colour" and "single cell selection" options, use of which forces the redraw to use a WM_NOTIFY handler within the script. Changed: A number of minor internal changes to speed up the loading of the ListView when using either or both of the "colour" and "single cell selection" options. A slightly modified Example_6 script shows the new functions in use. The LH native ListView can have rows and columns added/removed using both the old and new functions and has a context menu to allow for colour selection. The contents of this ListView can be mirrored to the RH UDF-created ListView which has "single cell selection" enabled and allows the colours of any item (including the selected cell) to be changed programmatically. New UDF in the zip below. Previous changes: ChangeLog.txt Hi, It seemed that I wanted to add, delete, edit or move items in a ListView quite often in my scripts and I got fed up with having to rewrite the code to do it each time. I also wanted to be able to drag items within and between ListViews with the mouse, plus edit the items. So I decided to write a UDF to make life easier and here is the result - GUIListViewEx. If you are interested in how it works, then read this bit - if not, then skip over it: The UDF is pretty easy to use: - You start by creating a ListView (either native or UDF) and passing the returned ControlID/handle and the array you used to fill it to the _Init function of the UDF. You also indicate whether the array has a count in the [0] (or [0][0]) element and if you create an empty ListView, the UDF will still cope and will shadow any items that you insert later. If you have a ListView filled with data but no matching array, there is a function to read that data into an array for you. You can select a colour for the insert mark when dragging items if you are going to use this feature - the default is black - and decide whether to have a shadow of the dragged item follow the mouse. Finally you can set the ListView to be sortable, editable - with various options to determine how the editing process works, determine external drag/drop behaviour and whether user colours are used. - You need to register a few Windows messages, but this is a single call to the _MsgRegister function. If you already have handlers for the relevant messages, there are functions to call within these handlers instead. If you do not want to drag, then you only need the WM_NOTIFY handler loaded. - Then you just need to call the main _Insert($vData), _Delete, _Up, and _Down functions when the appropriate button is pressed, select and drag items, or use one of the edit functions and your ListView responds automatically. - The UDF shadows the contents of the ListView (as explained in the spoiler section above) so you can get its current state at any time with the _ReturnArray function . Many of the functions actually return this data after each call just to help you keep track and there are dedicated Save/Load functions. - If enabled, the user can colour individual items within the ListView - and can set certain elements to be coloured on loading if required. - There are a couple of functions that you need to run in your idle loop if you need the functionality - they detect when items are dragged and edited. - When you have finished with the ListView, you should use the _Close function to clear the memory used by the UDF to shadow its contents. It is not vital, but if you use a lot of ListViews and do not do this, you could end up running out of memory. - You can have as many ListViews as you wish on display at any one time and the same "Insert", "Delete", "Up" and "Down" buttons can be used for them all - you just have to click on the one you want to be active. The UDF also allows you to set the active ListView programatically (_SetActive) - and to determine which is currently active (_GetActive). There are also additional Insert/DeleteSpec functions which allow you to action non-active ListViews. There are 6 example scripts to show the UDF working on native and UDF created ListViews, with single or multiple columns and either filled or empty, along with the UDF itself in this zip file: Credit to martin (for the basic drag code which I found on the forum), the Array UDF authors (for the basis of the array functions) and LarsJ (for the basic colour handler code). Happy for any feedback - hopefully positive! M23

Studying this modified example will shed light: #include <Date.au3> $a=_DateDiff('s', "1970/01/01 00:00:00", _NowCalc()) ConsoleWrite(VarGetType($a) & " = " & $a & @CR) ConsoleWrite(Hex($a, 8) & @CR ) ConsoleWrite(Hex(Int($a), 8) & @CR )

argumentum, Ooops - incorrect check for the existence of the row/col combination meant it crashed on an empty ListView. Now fixed - please download again. M23

luger, Hex requires an int or binary type, like this... ConsoleWrite(Hex(int($a), 8) & @CR ) kylomas

Your code looks too complex to me. You should really add few comments so that others (me - for example) can understand what are you trying to do with each step. Things that look obvious to you may not be that obvious to others. Aside from that, why don't you use WinHttp.au3 in more advanced way? The UDF is probably smarter than you think it is. For example, I just used this code to pick a pic from my comp and upload it to a group: #include "WinHttp.au3" Global Const $sFB_Email = "yaEmail.@domain.com" ;<- your email here Global Const $sFB_sPassword = "p@$$w0rd" ;<- your password here $sGroupID = "5555555555555555" ; group ID you want to post to $sPic = FileOpenDialog("Choose Pic to post", "", "Image (*.jpg;*.png;*.gif;*.bmp)"); choose a file you want to post If $sPic Then ConsoleWrite(FB_PostPicToGroup($sGroupID, $sPic) & @CRLF) Func FB_PostPicToGroup($sGroupID, $sPic) Local $iSuccess = 0 ; preset output (failure) ; Open session Local $hOpen = _WinHttpOpen() ; Connect Local $hConnect = _WinHttpConnect($hOpen, "https://m.facebook.com/") ; Login first (by filling login form) Local $sRead = _WinHttpSimpleFormFill($hConnect, _ ; connection handle "login.php", _ ; target page "login_form", _ ; form identifier "name:email", $sFB_Email, _ ; first field identifier paired with field data "name:pass", $sFB_sPassword) ; second field identifier paired with data ; Check for errors If Not @error And @extended = $HTTP_STATUS_OK Then ; Navigate to the Group and ask for pic upload Local $aRead = _WinHttpSimpleFormFill($hConnect, _ ; connection handle "/groups/" & $sGroupID, _ ; target page "index:1", _ ; form identifier (by index here, because id or name doesn't exist) "name:view_photo", True, _ ; identify submit control and click it "[RETURN_ARRAY]") ; return array because current URL is needed ; Check for errors If Not @error And @extended = $HTTP_STATUS_OK Then ; Read current URL (go with the flow) Local $aURL = _WinHttpCrackUrl($aRead[2]) If Not @error Then ; check for error ; Upload file $aRead = _WinHttpSimpleFormFill($hConnect, _ ; connection handle $aURL[6] & $aURL[7], _ ; target page Default, _ ; form identifier (default is used for simplicity because it's the only form on that page) "name:file1", $sPic, _ ; form field used for file "[RETURN_ARRAY]") ; return array because current URL is needed ; Check for errors If Not @error And @extended = $HTTP_STATUS_OK Then ; Read current URL now $aURL = _WinHttpCrackUrl($aRead[2]) ; check for error If Not @error Then ; Finally submit the post _WinHttpSimpleFormFill($hConnect, _ ; connection handle $aURL[6] & $aURL[7], _ ; target page Default, _ "name:view_post", True) If Not @error And @extended = $HTTP_STATUS_OK Then $iSuccess = 1 EndIf EndIf EndIf EndIf EndIf ; Close handles _WinHttpCloseHandle($hConnect) _WinHttpCloseHandle($hOpen) ; Bye... Return $iSuccess EndFunc Does it do what you want it to do?

I think jchd just added the long answer to JohnOne's short answer.

Yes it does. Else all scripts using this and that standard include and adhering to recommended coding practices would report warnings. That would cause dozens of complaints a day. Would also make stripping unusable (breaking correct scripts).

locknlol, Admitting to using a decompiler is a capital offence here. Consider yourself lucky that it is your first post - other wise you would be permanently banned. As it is this thread will now be locked and I suggest you read the Forum rules (there is also a link at bottom right of each page) before you post again. M23

twelo, My guess was correct - you need to poll the events in both windows. If you are doing this, it is best to use the "advanced" parameter of GUIGetMsg so you can differentiate between the windows - if you do not, you cannot tell the difference between a $GUI_EVENT_CLOSE from the parent or the child. Here is a short example based on your script to show you want I mean. I have changed the Selects to Switches - I think it is clearer : #include <GUIConstants.au3> #include <Misc.au3> #include <String.au3> #include <EditConstants.au3> #include <WindowsConstants.au3> #include <File.au3> #include <GuiEdit.au3> #include <GuiConstantsEx.au3> #include <StaticConstants.au3> #include <WinAPI.au3> #include <ButtonConstants.au3> #include <GuiMenu.au3> $PARENT = GUICreate("PARENT", 300, 300, -1, -1, BitOR($WS_MAXIMIZEBOX, $WS_MINIMIZEBOX, $WS_SIZEBOX, $WS_THICKFRAME, $WS_SYSMENU, $WS_CAPTION, $WS_OVERLAPPEDWINDOW, $WS_TILEDWINDOW, $WS_GROUP, $WS_TABSTOP, $WS_BORDER, $WS_CLIPSIBLINGS), BitOR($WS_EX_ACCEPTFILES, $WS_EX_WINDOWEDGE)) $File = GUICtrlCreateMenu("File") $2ndGUI = GUICtrlCreateMenuItem("Child Win", $File) $About = GUICtrlCreateMenuItem("About", $File) $Button1 = GUICtrlCreateButton("BUTTON 1", 100, 125, 100, 50, $WS_GROUP) GUISetState(@SW_SHOW) While 1 ; Here we have only 1 GUI to worry about, so we can use the "normal" GUIGetMsg Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit Case $About MsgBox(8192, "about", "Parent Child Windows") Case $Button1 MsgBox(8192, "1st Msg", "hello this is parent window") Case $2ndGUI _Create_Child() ; I have only separated this out into a function for clarity EndSwitch WEnd Func _Create_Child() $CHILD = GUICreate("CHILD", 200, 200, -1, -1, BitOR($WS_MAXIMIZEBOX, $WS_MINIMIZEBOX, $WS_SIZEBOX, $WS_THICKFRAME, $WS_SYSMENU, $WS_CAPTION, $WS_OVERLAPPEDWINDOW, $WS_TILEDWINDOW, $WS_POPUP, $WS_POPUPWINDOW, $WS_GROUP, $WS_TABSTOP, $WS_BORDER, $WS_CLIPSIBLINGS), BitOR($WS_EX_WINDOWEDGE, $WS_EX_MDICHILD), $PARENT) $Button2 = GUICtrlCreateButton("BUTTON 2", 50, 100, 100, 50, $WS_GROUP) GUISetState(@SW_SHOW) ; We have 2 GUIs, so use the "advanced" parameter for GUIGetMsg While 1 $aMsg = GUIGetMsg(1) ; We get an array returned with the "advanced" parameter - [1] = GUI, [0] = ControlID/EventID Switch $aMsg[1] ; All these events took place in the Parent GUI Case $PARENT Switch $aMsg[0] Case $GUI_EVENT_CLOSE ; We know this is the parent so we can exit Exit Case $About MsgBox(8192, "about", "Parent Child Windows") Case $Button1 MsgBox(8192, "1st Msg", "hello this is parent window") ; Note there is no case for creatign a second GUI - we already have it! EndSwitch ; All these events were in the Child GUI Case $CHILD Switch $aMsg[0] Case $GUI_EVENT_CLOSE ; We know this is the Child, so only close it, not full exit GUIDelete($CHILD) ExitLoop Case $Button2 MsgBox(8192, "2nd Msg", "hello this is child window") EndSwitch EndSwitch WEnd EndFuncI have commented liberally - I hope everything is clear. M23