Leaderboard

antonioj84, I think I understand, but it will be tomorrow before I can do anything - see you then. M23

Here's a beginners' exercise. 1. How many mistakes can you spot in the following script? 2. Rewrite the script in a clear and consice manner. ; How many errors does this script contain? $iHour = @HOUR #include <MsgBoxConstants.au3> #include <Date.au3> If $iHour >= 12 Then MsgBox(0, "Message", "It's after midday!", $MB_OK) Exit ElseIf $iHour < 12 Then MsgBox(0, 'Message', "It's not yet midday!", $MB_OK) Exit EndIf Solution can be found here: https://www.autoitscript.com/forum/topic/188018-answers-to-exercises-for-autoit/ Do not look at the solution until you have tried to solve it yourself.

just like in my case ....

@Morientis you seem to have missed the forum rules on your way in. I suggest you read them now, especially the section regarding game automation, and you will see why this thread is locked. You will get no assistance on this topic.

satanico64, Combo cuebanners are funny things and will only display when the combo is not focussed. Focus on the edit by clicking it and the cuebanner appears in the combo. I will look at the UDF code and see if I can change this behaviour. M23 Edit: Hi, Subz! Edit 2: I see the problem - the _GUICtrlComboBox_SetCueBanner function does not have an optional parameter to display/hide the cue banner when focussed and just defaults to hide. If I add a parameter similar to the $bOnFocus parameter in _GUICtrlEdit_SetCueBanner you will be able to choose whether to see the cuebanner in all circumstances. I will amend the UDF accordingly. M23

FTP_Screen is like a very stripped down version of ShareX created by @Jex

It has great benefit IMHO.

@Melba23 - maybe time to rename that UDF. May I suggest "MelbaToast,au3"? I have seen your Toast.udf a million times - but all those potential sound bytes were hiding in plain sight. I apologize if that is only amusing to me ... on cold meds at the moment.

I think he meant this. It's some pretty good toast lol

Last post in the topic

If the AutoIt Window Info tool isn't able to detect a control the standard way to proceed is to try with the UI Automation framework, which has been the Microsoft automation platform for the last 10 years. You should start by checking if the UI Automation framework is able to detect your control. The easiest way to do that is to use Inspect.exe which is a Microsoft tool. You can find Inspect.exe in the bin-folder of the Windows 10 SDK (can also be installed on windows 7/8). The Windows 10 SDK takes up about 2.5 GB of diskspace. If you only need Inspect.exe you can copy the 32 and 64 bit versions of the program and then uninstall the SDK again (installing the SDK is the only legal way to get a copy of Inspect.exe). You can also find a copy of Inspect.exe here (the RAR-file can be extracted with 7-Zip). Double click Inspect.exe to start it and hover the mouse pointer over the control. You'll probably see a lot of information. In a Combo box in upper left corner of Inspect.exe you can switch between UI Automation mode (default) and MSAA mode (Microsoft Active Accessibility). MSAA mode can be useful if your program is very old (more than 10 years old). If Inspect.exe can identify your control you can use the AutoIt implementation of the UI Automation framework to automate the control. Here is an example with the TreeView in Windows/File Explorer left pane window. The Intel folder on the C-drive is selected: Inspect.exe can identify the TreeView item and extract a lot of information. The Action menu is opened and the Expand action is highlighted: When the Expand menu item is clicked the TreeView is expanded: With Inspect.exe you can test if the TreeView can be automated with UI Automation code. And you can perform the test without writing a single line of code. In the next two pictures the Intel folder is collapsed again. With Inspect.exe you can relatively easily get an impression of whether you're able to automate the window or control. And you can figure it out before you start writing code. The code box shows how to automate the manual procedure above with UI Automation code. Windows/File Explorer must be open and the C-drive must be expanded as shown in the last picture. The code expands and collapses the Windows folder: #include "CUIAutomation2.au3" Opt( "MustDeclareVars", 1 ) Example() Func Example() ; Flag to handle Windows XP Local $fXP = ( @OSVersion = "WIN_XP" ) ; Get window handle for Windows/File Explorer on XP, Vista, 7, 8, 10 Local $hWindow = WinGetHandle( "[REGEXPCLASS:^(Cabinet|Explore)WClass$]" ) If Not $hWindow Then Return ConsoleWrite( "$hWindow ERR" & @CRLF ) ConsoleWrite( "$hWindow OK" & @CRLF ) ; Activate the window WinActivate( $hWindow ) ; Create UI Automation object Local $oUIAutomation = ObjCreateInterface( $sCLSID_CUIAutomation, $sIID_IUIAutomation, $dtagIUIAutomation ) If Not IsObj( $oUIAutomation ) Then Return ConsoleWrite( "$oUIAutomation ERR" & @CRLF ) ConsoleWrite( "$oUIAutomation OK" & @CRLF ) ; Get UI Automation element from window handle Local $pWindow, $oWindow $oUIAutomation.ElementFromHandle( $hWindow, $pWindow ) $oWindow = ObjCreateInterface( $pWindow, $sIID_IUIAutomationElement, $dtagIUIAutomationElement ) If Not IsObj( $oWindow ) Then Return ConsoleWrite( "$oWindow ERR" & @CRLF ) ConsoleWrite( "$oWindow OK" & @CRLF ) ; Condition to find the Windows folder in the TreeView ; We use two conditions to find the Windows folder ; A condition to find the folder as a TreeView item ; A condition to find the folder by name (Windows) ; TreeView item Local $pCondition1 $oUIAutomation.CreatePropertyCondition( $UIA_ControlTypePropertyId, $UIA_TreeItemControlTypeId, $pCondition1 ) If Not $pCondition1 Then Return ConsoleWrite( "$pCondition1 ERR" & @CRLF ) ConsoleWrite( "$pCondition1 OK" & @CRLF ) ; Folder name Local $pCondition2 ; Note that $UIA_NamePropertyId ia a CASE SENSITIVE condition $oUIAutomation.CreatePropertyCondition( $UIA_NamePropertyId, ( $fXP ? "WINDOWS" : "Windows" ), $pCondition2 ) If Not $pCondition2 Then Return ConsoleWrite( "$pCondition2 ERR" & @CRLF ) ConsoleWrite( "$pCondition2 OK" & @CRLF ) ; And condition Local $pCondition $oUIAutomation.CreateAndCondition( $pCondition1, $pCondition2, $pCondition ) If Not $pCondition Then Return ConsoleWrite( "$pCondition ERR" & @CRLF ) ConsoleWrite( "$pCondition OK" & @CRLF ) ; Find folder Local $pFolder, $oFolder $oWindow.FindFirst( $TreeScope_Descendants, $pCondition, $pFolder ) $oFolder = ObjCreateInterface( $pFolder, $sIID_IUIAutomationElement, $dtagIUIAutomationElement ) If Not IsObj( $oFolder ) Then Return ConsoleWrite( "$oFolder ERR" & @CRLF ) ConsoleWrite( "$oFolder OK" & @CRLF ) If Not $fXP Then ; For visual verification ; XP: SetFocus expands the folder $oFolder.SetFocus() ; Not necessary ConsoleWrite( "SetFocus OK" & @CRLF ) EndIf ; ExpandCollapse pattern object ; Pattern objects are used for ACTIONS Local $pExpandCollapse, $oExpandCollapse $oFolder.GetCurrentPattern( $UIA_ExpandCollapsePatternId, $pExpandCollapse ) $oExpandCollapse = ObjCreateInterface( $pExpandCollapse, $sIID_IUIAutomationExpandCollapsePattern, $dtagIUIAutomationExpandCollapsePattern ) If Not IsObj( $oExpandCollapse ) Then Return ConsoleWrite( "$oExpandCollapse ERR" & @CRLF ) ConsoleWrite( "$oExpandCollapse OK" & @CRLF ) ; Wait 5 seconds Sleep( 5000 ) ; Expand folder $oExpandCollapse.Expand() ConsoleWrite( @CRLF & "Expand OK" & @CRLF ) ; Wait 5 seconds Sleep( 5000 ) ; Collapse folder $oExpandCollapse.Collapse() ConsoleWrite( @CRLF & "Collapse OK" & @CRLF ) EndFunc Output in SciTE console: $hWindow OK $oUIAutomation OK $oWindow OK $pCondition1 OK $pCondition2 OK $pCondition OK $oFolder OK SetFocus OK $oExpandCollapse OK Expand OK Collapse OK The code is tested on Windows 10, 7 and XP. The zip file contains the example code and CUIAutomation2.au3. Run the code in SciTE. Explorer.7z An alternative to Inspect.exe is the simplespy.au3 script which is included in UIA_V0_63.zip in bottom of first post in the UI Automation thread. Another alternative to both Inspect.exe and simplespy.au3 is UIASpy - UI Automation Spy Tool. Examples of UIASpy use are found in Using UI Automation Code in AutoIt. With the code in post 71 of the UI Automation thread you can print information in SciTE console about the controls in a window. The information is printed in a hierarchical structure like a treeview.

Maybe this ? #include <GuiConstantsEx.au3> #include <Windowsconstants.au3> #include <SendMessage.au3> #include <WinAPI.au3> Global Const $SC_DRAGMOVE = 0xF012 HotKeySet("{ESC}", "On_Exit") ; Set distance from edge of window where resizing is possible Global Const $iMargin = 4 ; Create GUI $hGUI = GUICreate("Y", 120, 120, -1, -1, $WS_POPUP, BitOr($WS_EX_LAYERED, $WS_EX_COMPOSITED, $WS_EX_TOPMOST)) GUISetBkColor(0x00FF00) $btn = GuiCtrlCreateButton("close", 20, 20, 60, 25) GuiCtrlCreateLabel("", 10, 10, 100, 100) GUICtrlSetBkColor(-1, 0xABCDEF) GUICtrlSetResizing(-1, $GUI_DOCKBORDERS) GUISetState() _WinAPI_SetLayeredWindowAttributes($hGui, 0xABCDEF) ; Register message handlers GUIRegisterMsg($WM_MOUSEMOVE, "_SetCursor") ; For cursor type change GUIRegisterMsg($WM_LBUTTONDOWN, "_WM_LBUTTONDOWN") ; For resize/drag While 1 $msg = GUIGetMsg() Switch $msg Case $btn On_Exit() EndSwitch WEnd ; Set cursor to correct resizing form if mouse is over a border Func _SetCursor() Local $iCursorID Switch _Check_Border() Case 0 $iCursorID = 2 Case 1, 2 $iCursorID = 13 Case 3, 6 $iCursorID = 11 Case 5, 7 $iCursorID = 10 Case 4, 8 $iCursorID = 12 EndSwitch GUISetCursor($iCursorID, 1) EndFunc ;==>SetCursor ; Check cursor type and resize/drag window as required Func _WM_LBUTTONDOWN($hWnd, $iMsg, $wParam, $lParam) Local $iCursorType = _Check_Border() If $iCursorType > 0 Then ; Cursor is set to resizing style so send appropriate resize message $iResizeType = 0xF000 + $iCursorType _SendMessage($hGUI, $WM_SYSCOMMAND, $iResizeType, 0) Else Local $aCurInfo = GUIGetCursorInfo($hGUI) If $aCurInfo[4] = 0 Then ; Mouse not over a control _SendMessage($hGUI, $WM_SYSCOMMAND, $SC_DRAGMOVE, 0) EndIf EndIf EndFunc ;==>WM_LBUTTONDOWN ; Determines if mouse cursor over a border Func _Check_Border() Local $aCurInfo = GUIGetCursorInfo() If @error Then Return -1 Local $aWinPos = WinGetPos($hGUI) Local $iSide = 0 Local $iTopBot = 0 If $aCurInfo[0] < $iMargin Then $iSide = 1 If $aCurInfo[0] > $aWinPos[2] - $iMargin Then $iSide = 2 If $aCurInfo[1] < $iMargin Then $iTopBot = 3 If $aCurInfo[1] > $aWinPos[3] - $iMargin Then $iTopBot = 6 Return $iSide + $iTopBot EndFunc ;==>_Check_Border Func On_Exit() Exit EndFunc

fopetesl, The problem is your use of @TABs within the string to display. The UDF uses the GetTextExtentPoint32W DLL call to get the width of the text and this function is not too keen on accurately expanding @TABs. So if asked, the UDF replaces any @TAB character with " XXXXXXXX" when measuring but displays with the original tabs. This ensures that the EMB is always at least wide enough to contain the text - but often at the expense of being too wide (as in first of your images). Trying to reduce the max width of the EMB (as in the second image) will merely force the text to be wrapped. The discussion earlier in the thread where it was discussed. EMBs are not designed to display huge walls of text - and given the known limitations of @TAB use - certainly not when the @TABs form the majority of the text. If the elements of the data to be displayed are always of the relatively small size shown above I would strongly suggest using a ListView (as I suggested in the thread when you first mentioned the requirement) as you can then define the column width more closely. In fact using my StringSize UDF (the same as is used internally by EMB) on each element would allow you to create a custom sized dialog very easily (it is basically what is done inside _ArrayDisplay). If you were to start a new thread we could work together to produce something suitable for you - perhaps along these lines: #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include <GUIListView.au3> ; Original array Global $aElements[17][13] For $i = 0 To 16 For $j = 0 To 12 $aElements[$i][$j] = "Data" & $i & " - " & $j Next Next ; Define required ListView size and titles $iRows = 12 $iCols = 8 ; Array to display - element contents show which element of data array to display Global $aDisplay[$iRows][$iCols] = [["Hauteur", "", "", "", "Barbe", "", "", ""], _ ["6-4", "6-5", "", "", "6-9", "6-10", "", ""], _ ["7-4", "7-5", "", "", "7-9", "7-10", "", ""], _ ["8-4", "8-5", "8-6", "8-7", "8-9", "8-10", "8-11", "8-12"], _ ["9-4", "9-5", "9-6", "9-7", "9-9", "9-10", "9-11", "9-12"], _ ["10-4", "10-5", "10-6", "10-7", "10-9", "10-10", "10-11", "10-12"], _ ["11-4", "11-5", "11-6", "11-7", "11-9", "11-10", "11-11", "11-12"], _ ["12-4", "12-5", "12-6", "12-7", "12-9", "12-10", "12-11", "12-12"], _ ["13-4", "13-5", "13-6", "13-7", "13-9", "13-10", "13-11", "13-12"], _ ["14-4", "14-5", "14-6", "14-7", "14-9", "14-10", "14-11", "14-12"], _ ["15-4", "15-5", "15-6", "15-7", "15-9", "15-10", "15-11", "15-12"], _ ["16-4", "16-5", "16-6", "16-7", "16-9", "16-10", "16-11", "16-12"]] ; Fill display array For $i = 0 To $iRows - 1 For $j = 0 To $iCols - 1 $aSplit = StringSplit($aDisplay[$i][$j], "-") If Not @error Then $aDisplay[$i][$j] = $aElements[$aSplit[1]][$aSplit[2]] EndIf Next Next ; Define button size $iButton_Width = 80 $iButton_Height = 30 ; Now create a GUI $hGUI = GUICreate("", 500, 500) ; Create ListView Local $cListView = GUICtrlCreateListView("", 10, 10, 480, 450, BitOr($LVS_SHOWSELALWAYS, $LVS_NOCOLUMNHEADER)) _GUICtrlListView_SetExtendedListViewStyle($cListView, BitOr($LVS_EX_FULLROWSELECT, $WS_EX_CLIENTEDGE)) For $i = 0 To 7 _GUICtrlListView_AddColumn($cListView, "", 100) Next ; Fill ListView _GUICtrlListView_BeginUpdate($cListView) _GUICtrlListView_AddArray($cListView, $aDisplay) _GUICtrlListView_EndUpdate($cListView) ; Determine required ListView size $iLV_Width = 0 For $i = 0 To $iCols - 1 _GUICtrlListView_SetColumnWidth($cListView, $i, $LVSCW_AUTOSIZE) $iLV_Width += _GUICtrlListView_GetColumnWidth($cListView, $i) + 5 Next $hHeader = _GUICtrlListView_GetHeader($cListView) $aHdrPos = WinGetPos($hHeader) $aRect = _GUICtrlListView_GetItemRect($cListView, 0) $iLV_Height = $aHdrPos[3] + (($aRect[3] - $aRect[1] + 1) * $iRows) ; Resize GUI and ListView GUISetState(@SW_HIDE, $hGUI) ; Must display before changing size WinMove($hGUI, "", Default, Default, $iLV_Width + 20, $iLV_Height + 60 + $iButton_Height) WinMove(GUICtrlGetHandle($cListView), "", 10, 10, $iLV_Width, $iLV_Height) ; Create buttons using a simple algorithm to correctly place them $cButton_1 = GUICtrlCreateButton("One", (($iLV_Width + 20) / 2) - $iButton_Width - 10, $iLV_Height + 20, 80, 30) $cButton_2 = GUICtrlCreateButton("Two", (($iLV_Width + 20) / 2) + 10, $iLV_Height + 20, 80, 30) GUISetState(@SW_SHOW, $hGUI) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd M23

Mirror: Direct3D Br, UEZ

Seems quite realistic. Something is wrong with the heightsmap though. Using a Perlin noise, I manage to get smooth transitions and no overlapped triangles. Also, it's quite a bumpy terrain. Try using cell spacing of 15 and a scale factor of 3. It's about taste, so don't judge me. ;] Your next task is to implement a per-pixel lighting shader. It'll increase the realism of the terrain dramatically.

Thanks trancexx. Can't wait for the new AutoItObject UDF to come out. I thought of encapsulating all the vectors and matrices intrinsic operators (fake) in classes. So.. does the next version of AutoItObject support object methods naturally? i.e without callbacks? Edit: You can do as Firefox did and open a topic about it in the general forum. Changing the function prototype doesn't change how you call it. Make sure you call it with the correct values. P.S. Can you also somehow help to eliminate the "ptr", Number(DllStructGetPtr(..)) thing?

Func _TerrainCreate($pDevice, $sHeightMapFile, $iVertsPerRow, $iVertsPerCol, $iCellSpacing, $nHeightScale = 1) ; ... You should play with the cell spacing and height scale values. High cell spacing on a 64x64 heightsmap generate a lower resolution terrain but can be generated faster. Then you can apply a scale factor of 3 or 5 to increase the (now stretched) terrain bumpiness. That terrain is just an example, if you're aiming toward faster approaches you'll need to split the mesh into smaller meshes and handle each individually. Usually, for such tasks, people store a few sized .x files of the flat terrain mesh and generate and apply the heightsmap on the fly. Search for Perlin noise if you're interested. P.S. The _TerrainCreate function spends most of it's time on generating the terrain texture. Try to load a 512x512 heightsmap file without auto generating the texture. I guess it'll take half the time it takes with texture generation.