Custom Query (3931 matches)
Results (202 - 204 of 3931)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #203 | Rejected | AutoIt3Wrapper - Work on backup files | ||
| Description |
It would be very nice if there was an option ,when compiling scripts,to apply Tidy,Obfuscator,etc on a backup file instead of the real one,this way the original script would not get stripped,allowing testing with "real world" configurations without messing everything up. |
|||
| #204 | Rejected | GUICtrlCreateListViewItem() - new optional parameter IconIndex | ||
| Description |
GUICtrlCreateListViewItem() - new optional parameter IconIndex $iImage - Zero based index of the item's icon in the control's image list This new parameter will be optional so no backward compatibility problems. It should be the same as it's in _GUICtrlListView_AddItem() UDF _GUICtrlListView_AddItem($hWnd, $sText[, $iImage = -1]) $iImage - Zero based index of the item's icon in the control's image list Maybe the same apply also for GUICtrlCreateTreeViewItem() _GUICtrlTreeView_Add($hWnd, $hSibling, $sText[, $iImage = -1[, $iSelImage = -1]]) $iImage - Zero based index of the item's icon in the control's image list $iSelImage - Zero based index of the item's icon in the control's image list * Idea comes from my Log_View project (see my sig on the forum) where I create many ListView items by GUICtrlCreateListViewItem() and then I use GUICtrlSetImage(-1, @ScriptFullPath, $index) to set icon for just created ListViewItem item based on index from EXE icons in resources. But this is very slow because there is internally called ExtractIcon (fileoperations) and so on - for each item inside LOOP. $index = ... GUICtrlCreateListViewItem($itemtext, $ListView1) GUICtrlSetImage(-1, @ScriptFullPath, $index) should be $index = ... GUICtrlCreateListViewItem($itemtext, $ListView1, $index) Of course at start of script will be _GUICtrlListView_SetImageList () in this case. |
|||
| #205 | No Bug | [Vista64] PixelGetColor returns color of desktop picture instead of directX window | ||
| Description |
When trying to determine the color of a pixel via PixelGetColor in a directX window (eve online to be precise). When one tries to do so in Vista64 (sp1) with aero turned on it always returns 0 when the directX window is active. If one turns off aero then PixelGetColor returns whatever is under that directX window (eg the window below or if nothing is below the desktop background) instead of the directX windows color at that pixel. When running the exact same script with windows xp sp2 the problem does not occur, the correct color is returned. Steps to reproduce: 1) Download eve online from http://www.eve-online.com/download/ (free download, download the non premium version for a faster download), install it and launch it. 2) Run the following autoit code:
This will return the colors of a small area. With aero turned on pixelgetcolor will return 0. With aero turned off the color returned will be what ever the color below the eve window is (set your background to white for example to easily see that the color returned is wrong). |
|||
