Leaderboard
Popular Content
Showing content with the highest reputation on 11/28/2024 in all areas
-
Mr es335, Very understandable. However; you do not have a pea-sized intellect. Get rid of that negative self-deprecation, as you are only making it harder on yourself with that thinking. We all want to run, but we all have to learn to walk first. Take short breaks. Do something else like play an ES335. Programming does seem to be new to you. Programming is hard. The first programming language anyone learns is usually the hardest. Again, one has to learn how to walk before one can run, and we all want to run. As you already know; Programs get complicated fast. Your mind will adjust if you stay with it long enough. AutoIt is probably the easiest dynamic programming language to learn. Learning to write programs does take time. A lot of time. A very large investment of time spent coding is required to become really good at coding. I have days where I just suck at it. So I smile, I take a break, and come back to it. The devil smiles at us all, all anyone can do is smile back.2 points
-
ioa747, Example #1: $g_GlobalFolder Yes, I do believe that I "get it"! Why pass a global variable as a parameter when that parameter already exists globally? Duh! As you noted, "...If you keep the parameter in the _OpenFolder function, it can lead to confusion,..." So true!! Example #2: Yes! As with Example #1, no need to pass global variables!! And yes...the second example is indeed, much easier to read. And by-the-way, why is it that programmers have a seeming propensity for getting sick? Because, as programmers, they are alwyas getting "head codes"!!1 point
-
In real life in _WithGlobalVariables.au3 e.g. Case $_sCol3Row3 _BrowseForFolder() _LaunchWavFolder($g_SetNameWave) _CreateTextListing($g_SetNameWave) _LaunchTextListing($g_SetNameWave) ... ... ... Func _LaunchWavFolder($g_SetNameWave) ShellExecute($g_SetNameWave) ; ----------------------------------------------- Sleep(250) ; ----------------------------------------------- WinMove($g_SetNameWave, "", 970, 100, 550, 650) EndFunc ;==>_LaunchWavFolder Func _CreateTextListing($g_SetNameWave) Local $MyT1List = '' ; ----------------------------------------------- ; Assign $MyPath to $MyT1List and create the array $MyT1List = _FileListToArray($g_SetNameWave) ; Create the data file _FileCreate($g_SetNameWave & "\FileListing.txt") ; Write the array to the data file _FileWriteFromArray($g_SetNameWave & "\FileListing.txt", $MyT1List) EndFunc ;==>_CreateTextListing Func _LaunchTextListing($g_SetNameWave) ShellExecute($g_SetNameWave & "\FileListing.txt") ; ----------------------------------------------- Sleep(250) ; ----------------------------------------------- WinMove($g_SetNameWave & "\FileListing.txt", "", 400, 100, 550, 650) ; ----------------------------------------------- EndFunc ;==>_LaunchTextListing It would be clearer and easier to read. Case $_sCol3Row3 _BrowseForFolder() _LaunchWavFolder() _CreateTextListing() _LaunchTextListing() ... ... ... Func _LaunchWavFolder() ShellExecute($g_SetNameWave) ; ----------------------------------------------- Sleep(250) ; ----------------------------------------------- WinMove($g_SetNameWave, "", 970, 100, 550, 650) EndFunc ;==>_LaunchWavFolder Func _CreateTextListing() Local $MyT1List = '' ; ----------------------------------------------- ; Assign $MyPath to $MyT1List and create the array $MyT1List = _FileListToArray($g_SetNameWave) ; Create the data file _FileCreate($g_SetNameWave & "\FileListing.txt") ; Write the array to the data file _FileWriteFromArray($g_SetNameWave & "\FileListing.txt", $MyT1List) EndFunc ;==>_CreateTextListing Func _LaunchTextListing() ShellExecute($g_SetNameWave & "\FileListing.txt") ; ----------------------------------------------- Sleep(250) ; ----------------------------------------------- WinMove($g_SetNameWave & "\FileListing.txt", "", 400, 100, 550, 650) ; ----------------------------------------------- EndFunc ;==>_LaunchTextListing and it wouldn't change anything in the flow of the script1 point
-
Global $g_GlobalFolder = @ScriptDir & "\GlobalFolder" DirCreate($g_GlobalFolder) _Example() Func _Example() Local $sLocalFolder = @ScriptDir & "\LocalFolder" DirCreate($sLocalFolder) _OpenFolder($sLocalFolder) EndFunc ;==>_Example Func _OpenFolder($g_GlobalFolder) ConsoleWrite("$g_GlobalFolder=" & $g_GlobalFolder & @CRLF) ShellExecute($g_GlobalFolder) EndFunc ;==>_OpenFolder #CS What do I mean by this example? If you want the _OpenFolder function to go to $g_GlobalFolder, it would be better to omit the $g_GlobalFolder parameter from the _OpenFolder function. This is because the function can access the global variable directly without having to pass it as a parameter. Func _OpenFolder() ShellExecute($g_GlobalFolder) EndFunc If you keep the parameter in the _OpenFolder function, it can lead to confusion, and it can make it difficult to keep track of the variable referred to in the function, especially if $g_GlobalFolder is referred to multiple times. Alternatively, change the name of the parameter to e.g. $Folder Func _OpenFolder($Folder) ShellExecute($Folder) EndFunc #CE If this makes any sense1 point
-
DEMO VIDEO DBUG demo Update 4, files are changed! 28-jan-2010 - new buttons for debugging and managing the expressions list (add, delete, save, restore) - button images - pause button - mouse over variable names in the source code displays the current variable value as tooltip! Features - Debug the complete script or just parts of it - Display run status (linenumber of currently executed function) - GUI default always-on-top in the upper right corner for comfortable debugging - WM_NOTIFY and WM_COMMAND hook to prevent interference with possible message handlers - Display scope, type and value of variables, expressions, macro's and constants (global AND function local) - Execute commands in an immediate window. Can be expressions, functions and assignments - Detailed display of array, struct and object variables - Dynamic display of variable value in the source code (under cursor) Useage 1) #include <dbug.au3> as first line of the script to debug (after placing dbug.au3 in the include folder of course) 2) copy the images in a folder IMAGES on the same level as the Include folder 3) run the script! That's all. Take special care when debugging message handlers, when they don't return fast enough, strange things may happen. To prevent this, you may add a line ;STOP DBUG before the part you want to exclude from debugging until the line ;START DBUG (or the end of the script). Update 3, files are changed! Extended to debug complete scripts, not just lines. Update2 Although the GUI looks the same, the script is completely rewritten. Changes: - More reliable: debugger doesn't fail on constants and not declared variables. - No limitation to the count of variables that are read. - Determination of variable scope is correct. - Indication of breakpoint line when used with SciTE. - Re-entry of the debugger is prevented and indicated. Update Damn, I found a serious flaw in the script. The basic idea is to Execute() a function with the local variables as arguments. To be changable at debug time they are passed ByRef. This works wonderfull for variables but when constants are passed then the Execute() fails silently. I don't see how I can prevent this, anybody any idea? Original post Hi Gents, when playing with AutoIt I felt the need of an easy way to debug a bit more sophisticated then endless adding msgbox and consolewrites to my scripts. After looking around I start thinking of a way to make local variables visible outside there scope and came up with Dbug.au3. It's far from perfect but I wanted to share with you. Hope to hear your comments and maybe you find it usefull. By now the features are: - display scope, type and value of variables, expressions, macro's and constants (global AND function local) - execute commands in an immediate window. Can be expressions, functions and assignments - detailed display of array, struct and object variables - set a breakpoint expression Limitations are there also: - max 20 variables to display - scope display is not as reliable as it should be - when there is a not declared variable in the debugged function, debugging fails without an errormessage (Opt('MustDeclareVars', 1) helps) - multiple debug windows not allowed (but who does need them anyway?) - and without doubt more not yet discovered bugs! Examples: display: binary($var), @scriptdir, $var_a & $var_b, $arr[1][2], timerinit(), etc commands: $a = $b, ($c >= $d), $struc, $arr[3][4] = 'testDBUG', StringRegExp('TestDBUG', 'D(.*)', 2), etc, etc Usage: - Include the debug script dbug.au3 in the script you want to debug. - Write Execute(_debug()) on every line you want to inspect. - That's all! To play right away I supplied a little test script too (TestDBUG.au3) Files: dbug.au3 - debug script (Update 3 downloads: 94) IMAGES - Folder with fancy button images TestDBUG.au3 - declaration of some variables and calls to debugger I really like to know what you think of it and if you can use it. I spent far more time on it then planned So feedback is appreciated! IMAGES.ZIP Dbug.au3 TestDBUG.au31 point