TechCoder

The UDF from worked for me, though trying to stop it, etc. didn't.
What I wanted is to have a way to take a picture 'at will', then show that latest picture for as long as I wanted, then switch back to the webcam when I wanted (in other words, some sort of control over what is happening as well as getting that latest pic to show - in the same spot as the webcam).
My total application is not done, so there may be more features I'll put in overall, though here's some code (tested, working on my system) that might be of use to others.  Note that it uses 'brute force' methods as I'm still new to GUI, etc. but the end result is that it works!
#include <GUIConstants.au3> #include <WebcamUDF.au3> ; create webcam $webcamgui = GUICreate("webcam", 250, 192, @DesktopWidth/2 - 250/2,@DesktopHeight/2 - 192/2, $WS_POPUP) _WebcamInit() _Webcam($webcamgui, 250, 192, 0, 0) GUISetState(@SW_SHOW) $picgui = GUICreate("picture", 251, 192, @DesktopWidth/2 - 250/2, @DesktopHeight/2 - 192/2, $WS_POPUP) GUISetState(@SW_HIDE) ; create controls $gui = GUICreate("controls", 250, 80, @DesktopWidth/2 - 250/2, @DesktopHeight/2 - 192/2 + 192,$WS_POPUP) $button = GUICtrlCreateButton("picture", 10, 10) $webcam = GUICtrlCreateButton("webcam", 90, 10) $snapit = GUICtrlCreateButton("Take Picture", 160,10) $closeit = GUICtrlCreateButton("Close",90,50) GUISetState() While 1 $msg = GUIGetMsg() Switch $msg Case $GUI_EVENT_CLOSE,$closeit _WebcamStop() Exit Case $button ; create picture $picgui = GUICreate("picture", 250, 192, @DesktopWidth/2 - 250/2, @DesktopHeight/2 - 192/2, $WS_POPUP) $picshow = GUICtrlCreatePic("snapshot.bmp", 0, 0, 250, 192) GUISetState(@SW_SHOW) Case $webcam GUIDelete($picgui) case $snapit GUIDelete($picgui) ConsoleWrite("Taking snapshot ..." & @CRLF) _WebcamSnapShot() ConsoleWrite("Snapshot taken !" & @CRLF) EndSwitch WEnd

Yeah, I now see what it is...... - you are trying too hard!
Not sure what all that Array stuff is - you don't need it when working with JSON - it, by definition, is an array-decrypter (of sorts) - whatever you call it, JSON is a method in/of itself and you are trying to tear it apart yourself, then looking for the tools to do the work.
Don't try so hard!  
Basically, all you need when using this UDF: 
1. take the incoming JSON code (in your case, coming from a .txt file - it might come from a result or anywhere... - but LEAVE IT ALONE AS JSON)
2. JSMN_DECODE it to an object.  
3. use JSMN_GET.  
That's it!
This works (using the demo from JSMN and your data to show you the full results) - notice you only need ONE include, which is this UDF!
#include "JSMN.au3" local $Json1 $Json1 = FileRead("TestHistory.txt") Local $Data1 = Jsmn_Decode($Json1) ; ************************************************************************************ ; these lines are NOT NEEDED in your live system, just here to show the output Local $Json2 = Jsmn_Encode($Data1, $JSMN_UNQUOTED_STRING) Local $Data2 = Jsmn_Decode($Json2) Local $Json3 = Jsmn_Encode($Data2, $JSMN_PRETTY_PRINT, " ", "\n", "\n", "") ConsoleWrite("Test3 Unquoted Result: " & $Json2 & @CRLF) ConsoleWrite("Test3 Pretty Result: " & $Json3 & @CRLF) ; the above lines are not needed in a live system ; ************************************************************************************ $resault = Jsmn_Get($Data1, '[0]["Sysinfo"][0]["Properties"][0]["Name"]') ConsoleWrite($resault & @CRLF) and, for future reference, when you post code - go ahead and put in the #includes you are using (makes it simpler for someone testing your code, as well as know what you are using - it might be that you have the wrong includes sometimes....)
So, end result - let the tool do the work.  
(BTW, my 'tip' on going step at a time didn't work on this - because it starts off with an array - the data I have been working with is a bit different and that stepping through worked for me - guess it all depends on the data    However, the 'replace [{ with [0] works on your data as well as mine, so that seems a good 'rule'... )

Below you will find both a new Marquee UDF (many W3C/HTML5 features and more) as well as a user-friendly program that both serves as an example script, as well as it will create the code for any particular marquee for you!  Enjoy!   ~~~~~~~~~~~~~~~~~  BACKGROUND on <marquee> ~~~~~~~~~~~~~~~~~ <marquee> has been classed as "non-standard" and "non-conforming" as an HTML element   (http://www.w3.org/wiki/HTML/Elements/marquee)  There is no promise that it will continue to be supported in the future, though it is obvious that many people have a need for this feature and it has remained in the major browsers for years.....   <marquee> was originally built into Internet Explorer only, now supported in other browsers, though some original features do not work in IE either - it is clearly trying to be phased out, though a 'replacement' of sorts is coming around, using HTML5 components, so I think it will never totally go away. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   For a project I'm working on, I need a way to create a LOT of different marquees.  I thought it simpler to have a program create the code needed, and built the attached 'user interface' program using various references to the feature.   THE USER PROGRAM IS BACKWARD COMPATIBLE WITH THE EXISTING UDF FROM Melba23   I also needed some features that are not part of the UDF from Melba23 that are direct references to current (HTML5) recommendations from http://www.w3.org/TR/CSS2/, so I modified the current UDF to create the additional functions, which make the UDF more HTML5 compliant (some of the features I built in have no HTML5 component, existing functions were updated only where needed for the first release - perhaps someday the rest can be done, though no immediate plans)    *******************************************************************************************************************************    KNOWN ISSUES and/or LIMITATIONS within the user program   - Tip text NOT IMPLEMENTED (from _GUICtrlMarquee_SetDisplay $sTipTxt) - I had no use for it in my project, though it is not difficult to add if you need to   - border styles do not correspond to w3.org settings (not the program's fault...) This article (http://webdesign.about.com/od/beginningcss/a/aa091207.htm) states that IE does not support 'groove', 'ridge', 'inset' or 'outset' styles, yet does support 'dotted', 'dashed' and 'double'.   Testing has proven this is true for IE (11), however, in testing AutoIt (with the Marquee UDF), which I thought uses IE (?), it appears that just the OPPOSITE of this is true.  Another item for further testing/study.........   - 'Align' feature not working 100% on all fonts (not the program's fault! the initial version of <marquee> (designed for IE and copied to other browsers later) contained an element called 'align', which has long been obsolete in favor of css 'vertical-align', however, it is not a direct replacement  and does not work inside <marquee>.     Several alternatives were tried (including 'line-height' and even 'vspace', which may also soon be phased out) and nothing works 'perfectly' (search the web on font sizing and spacing - you will see this is extremely difficult).        This program works around these challenges in a 'best effort' way, using calculations and 'top-margin' (or vspace) spacing.        'Recommended' fonts (http://www.autoitscript.com/autoit3/docs/appendix/fonts.htm) will be set to 'center' or 'bottom' (within a pixel or 2), while other fonts may be off by several pixels (something in the font is different..).        If you need the other fonts, a bit of testing would give some offset numbers that could result in better display. (this is NOT on my list to do, though maybe someone would want to take that on???)   - You can create 'unreadable', 'unusable' and even 'UGLY' marquees (not the program's fault, either!) While a bit of effort was put into limiting things, there is no cross-checking to make sure your marquee will look 'nice'.  All parameters within the marquee feature have been tested to their max/min limits (and pushed well past the documented limits for speed and delay - you can make a  F A S T  or  S L O W  marquee well outside the published specs!) and set accordingly.   Any/all color scheme, font size, etc. can be used (no matter how horrible the outcome...) so have fun and create what you like!    *******************************************************************************************************************************   Additional recommendations from w3.org built into Marquee_W3C.au3 UDF   1. Border thickness (width) refered as "thin", "medium" and "thick" or <length> (any number - to infinity)      (http://www.w3.org/TR/CSS2/box.html#border-properties)     (http://www.w3schools.com/jsref/prop_style_borderwidth.asp) Marquee_W3C UDF allows any number as an entry, as well as the more 'friendly' named terms   2. Border Style is included in Marquee_W3C UDF (not in the current UDF, therefore, none of the settings in the user program do anything if you use the old UDF, so it is set to $GUI_DISABLE.)   3. use of PIXELS and EM for formatting text instead of POINTS      http://www.w3.org/TR/CSS2/fonts.html#font-size-props use <length> paramaters      http://www.w3.org/TR/CSS2/syndata.html#value-def-length with named length units (em, ex, cm, in, px, etc.)   POINTS are used in typsetting, while PIXELS, and EM are more correct methods of sizing fonts on modern monitors (one good article on this topic can be found at http://webdesign.about.com/cs/typemeasurements/a/aa042803a.htm )   NOTE: The user program is backward compatible with the UDF from Melba23 that uses POINTS and auto-sets the parameter with the chosen UDF.    
Marquee_W3C.au3
MarqueeMaker.au3

"Interesting"? Perhaps the most interesting bit was the fact that jchd has more knowledge about sql in the tips of his little fingers that I have acquired in twenty-something years (well, maybe that isn't "interesting", but it certainly became very clear very quickly!)
I'd say there where too many 'take-aways' from the PMs, etc. to possibly list, though we (I can only use that term loosely as it was much more "under much appreciated, patient guidance - even when I didn't want to believe it, but did it anyway and found it was right.....") found where the slowdown occurs, I learned a LOT about how/where to clean up my code (both in this project and in general for all projects since) and even though I wound up spending a couple weeks cleaning and reworking things, it was well worth the time and experience.
Guess I hadn't really said THANK YOU (not publicly anyway), but I know if I have any further challenges with anything like this, jchd is very high on my list of 'go to' people.
As for what was found?  A portion of the slowness was my 'lazy' code.  Once I cleaned that up, I sped things up a bit (don't have the numbers now, but it was something like 3% faster).
The real significant time factor change was when I figured out the 'serious' slowdown was NOT SQLite and NOT AutoIt, but actually the INTERFACE between them (going through the .dll - massive time killer!)  
Once I learned that, the only answer to 'speed tweaking' everything was to do the massive rewrite to eliminate that from the program as much as possible (not easy for me as I've always done server-side code and running to the database with any sort of change has been my practice for years).
End result?  Moving everything from 'database reliant' to using arrays made the end product at least 'liveable' timewise.  Still nothing like the php version (which is constantly calling the database), but we got it down to around 45 seconds for the total process.  Also, to make the user presentation feel more 'speedy', I broke the processing in half and presented the user with the first report to look over, which happens 'quick', then we process the second half and give that report (the php version gives the reports on both portions at the end).  Makes it feel like 'something is happening' a lot better.
I believe I cut it down to something like three database calls instead of the dozen or so I was using for each run of the process. 
Constant testing of each feature/sort/etc. showed that it was possible to work with arrays for most things (my data requirements were 'on the edge' of really needing more than arrays would support, but I opted for speed over the 'edge' scenarios {ie., the customers that would kick into that area would likely be in a position to upgrade their system memory, etc.}) and where AutoIt doesn't really have quick functions (multiple sorting on cross-referenced data), I used the database, which excels in that.
I guess the biggest 'take away' was just learning what tool to pick up for the right job - using each in the way it works best, for the job it was designed.

sounds more like most of the programmers I know....... 

@TechCoder,
im no expert, but it seems like you should pass pointers to strings to those functions, I fiddled around mainly since you bothered to to put up a testing page and this seems to work :
#include <libcURL.au3> Global $bMyData = Binary("") _Demo1() Func _Demo1()  Local $user = "AutoItuser"  Local $pass = "AutoItuser"  Local $testit = InputBox("SELECT", "Enter 1 for 'CURLOPT_POST as in php'" & @CRLF & "2 for 'CUSTOMREQUEST as works in php'" & @CRLF & "or anything else for 'best AutoIt so far'", 1)  Local $sURL = "http://cashflowproducts.com/test/Booked/Web/Services/Authentication/Authenticate"  Local $body = '{"username":"' & $user & '","password":"' & $pass & '"}'  Local $header_type = "POST"  Local $hcurl = _curl_easy_init()  ConsoleWrite("body is " & $body & @CRLF)  If($hcurl) Then   ; setup the URL   Local $tCURLSTRUCT_URL = DllStructCreate("char[" & StringLen($sURL) + 1 & "]")   DllStructSetData($tCURLSTRUCT_URL, 1, $sURL)   _curl_easy_setopt($hcurl, $CURLOPT_URL, DllStructGetPtr($tCURLSTRUCT_URL))   ; set up for output of callback   Local $handle = DllCallbackRegister("_my_vwrite", "uint:cdecl", "ptr;uint;uint;ptr")   _curl_easy_setopt($hcurl, $CURLOPT_WRITEFUNCTION, DllCallbackGetPtr($handle))   Local $tbody = DllStructCreate("char[" & StringLen($body) + 1 & "]")   DllStructSetData($tbody, 1, $body)   Local $theader_type= DllStructCreate("char[" & StringLen($header_type) + 1 & "]")   DllStructSetData($theader_type, 1, $header_type)   _curl_easy_setopt($hcurl, $CURLOPT_VERBOSE, 1)   If $testit = 1 Then ; STANDARD POST    _curl_easy_setopt($hcurl, $CURLOPT_POST, True);    _curl_easy_setopt($hcurl, $CURLOPT_COPYPOSTFIELDS, DllStructGetPtr($tbody));   ElseIf $testit = 2 Then ; using    _curl_easy_setopt($hcurl, $CURLOPT_CUSTOMREQUEST, DllStructGetPtr($theader_type));    _curl_easy_setopt($hcurl, $CURLOPT_COPYPOSTFIELDS, DllStructGetPtr($tbody));   Else    _curl_easy_setopt($hcurl, $CURLOPT_HTTPPOST, $body);   EndIf   Local $iRes = _curl_easy_perform($hcurl)   If $iRes > $CURLE_OK Then    ConsoleWrite("!CURL; " & _curl_easy_strerror($iRes) & @CRLF)   ElseIf $iRes = $CURLE_OK Then    ConsoleWrite("+>CURL; Success!" & @CRLF)    Local $sContentType    $iRes = _curl_easy_getinfo($hcurl, $CURLINFO_CONTENT_TYPE, $sContentType);    If $iRes = $CURLE_OK Then     ConsoleWrite("+>CURL; We received Content-Type: " & $sContentType & @CRLF);     $reply = BinaryToString($bMyData)     ConsoleWrite(@ScriptLineNumber & " " & " this is the reply we got =>>" & @CRLF & $reply & @CRLF & "<<=" & @CRLF)    EndIf   EndIf   _curl_easy_cleanup($hcurl)  EndIf EndFunc   ;==>_Demo1 Func _my_vwrite($buffer, $size, $nmemb, $stream)  Local $vData = DllStructCreate("byte[" & $size * $nmemb & "]", $buffer)  $bMyData &= DllStructGetData($vData, 1)  Return $size * $nmemb EndFunc   ;==>_my_vwrite

depending on your encryption technique, you may have to break long strings into segments, encrypt each, then tie the string back together.  One of the UDFs I found on this forum has a limit to 16 characters, which makes it more difficult to deal with, but once the programs are written to encrypt and decrypt, the length of string really doesn't matter too much (though there will be more processing time used, so balance things as best you can).
It is actually not a bad idea to keep strings small to encrypt then tie back together in a 'bundle' - it makes it a degree of difficulty harder for someone to decrypt it.  I would further suggest you vary the length of the breaks and rarely (if ever) break out a key pieces of data to encrypt by itself (as discussed in the other thread, say, for instance, you are going to grab the UUID, drive info, motherboard, etc. of a computer, you should tie them together, then break in various locations, encrypt each and put it all back into one string.)
Example (not all the code, but the comments!)
; gather data that we want to encrypt (UUID, drive info, motherboard in this example)
; get UUID
$UUID = (function to get the UUID)
; get disk drive info
$DriveInfo = (function to get the drive info)
; get computer board number
$CompBoardNo = (function to get that data)
Now, say we have
$UUID (10 characters)
$DriveInfo (15 characters)
$CompBoardNo (8 characters)
; put them all together in one string
$sStringToEncrypt = $UUID & $DriveInfo & $CompBoardNo
; break the string into small groups (if you make this various sizes, you will be more 'secure' (somewhat more difficult to decrypt/understand)
For this example, let's divide it into 4 parts(i.e., we decided not to use the above option - see how it is up to you how 'difficult' you want to make things and it will give a different result!)
There's 33 characters total, so 4 parts would be 3 with 8 and one with 9 characters (already different lengths)
; encrypt each part
$eString1 = _my_encrypt_function($sString1_toencrypt)
$eString2 = _my_encrypt_function($sString2_toencrypt)
$eString3 = _my_encrypt_function($sString3_toencrypt)
$eString4 = _my_encrypt_function($sString4_toencrypt)
  ; put them back together $eStringToProcessFurther = $eString1 & $eString2 & $eString3 & $eString4   to decrypt, just reverse the process.

you stated
 
though the instructions on the code you copied clearly stated
you need to use the password as instructed when you log in.
Why?
$username = mysql_real_escape_string( $_POST['username'] ); $password = sha1( md5( PASSWORD_SALT ) . $_POST['password'] . PASSWORD_SALT); $query = "SELECT * FROM `{$db_table}` WHERE `username`='{$username}' AND `password`='{$password}'"; $username is not changed in any way (taken directly from the POST data and checked against the database)
$password IS changed from the POST data, encrypted prior to being saved in the database (which stops people from getting into your database and stealing all the passwords - including YOU....)
In other words, the 'fix' is for you to follow the instructions given and use 'test' as a password and NOT what you see in the database (and your 'abc' user will never be able to log in as the password of '123' is not properly encrypted, so you might as well delete it).  If you want to add an account, add it using the AutoIt function and NOT directly in the database.

I believe that shows the base very well, so I believe 'create a .php and .sql for check' has been addressed.
I also believe the 'teach me' has been addressed in my addition of ideas/suggestions/etc that can make the base code more secure.
Perhaps your 'teach me' means 'show me where I could do better in the code'.  If so, you will find help here - by showing your code and asking for help in areas you get stuck.
It seems, though, that your 'teach me' means more 'do it for me' - that is not going to happen, for multiple reasons including the fact that creating security for your product is best done yourself (through taking the ideas/hints/suggestions given in this thread).  Certainly any code I create for security on my products will not be posted publicly and anyone that would post such would be wasting their time in creating it!
So, this is an area where 'ask for help when you get stuck' is the best (and IMHO, only) approach to going further.

A couple of 'step up security' things I did in a php-only project that I'm now porting to AutoIt (the php code required a bit too much 'techie' from the user end, and had other issues, so porting it all over......)
AutoIt side security code not yet started - too many other things to do getting the features working, then I'll tie in the security stuff just before public release, so below is just 'concept', though it works well in the php-only version.  Also note that this is a bit of 'overkill' for the OP's question, though relates to the subject and other question about a 'Microsoft-ish' code.  
This is only one way to do it - the more 'mixed' you get, the better!
'Simple' Online Security Check To Create Unlock Code For Only One Machine
IMPORTANT: The first thing for you to understand is that NO method of encryption, obfuscation or anything else will guarantee the code won't be cracked.  Much like putting a security system in a house, there are various 'layers' you can provide to deter a 'common thief', but a determined pro can still get in.  What you are looking to achieve is something that will make a hacker think "it is easier to just buy it than to crack it" - kind of like putting a lock on a glass window (generally, what is the point? though, it will give protection to some level)
NEVER put anyone's personal information at risk by including it in your security check!
(end of soapbox speech ...
Note: this method does not 'require' an ssl connection, but it never hurts!
1. read the details from the machine they are on (there's a nice UDF for that) - UUID, board info, CPU, drive info, etc. (NO PERSONAL DATA!)
2. sprinkle in your feature unlock bits throughout the generated code (this serves to further 'lock the window'), putting the bits scattered around where only you know where they are (do not put them 'every 3rd character' or something - make it more difficult!)  One thing you can do here is to take the first (for instance - be creative and use what you like!) character and 'key' off that to further tell where the feature bits are hiding (so, if the first character is '4', you might divide the string by 4, then look at the second character and go that many characters ahead, etc. - yes, it gets confusing - isn't that the point???  But, remember that you only have to do this once - for each side, then the programs talk automatically.)
3. encrypt that data using your own known 'salt' (there's a UDF for that...) - what you will come up with is a string that is something like 200 characters long (recommended to be 'long', but not 'massive' - you want it to transfer quickly)
4. send that string to the php side (similar to the above code)
5. the php side unravels what you put together into a) 'ID' code and 'Features' code (just like you put in)
6. Check the 'ID' code against the SQL server (I suggest you break out all the UUID, disk info, board, etc. and then do a 'percentage match' in case the user changes out a drive or something later)
7. Create a 'valid' string for various features (for instance, if the user has purchased the feature from a website, turn that on and next time they run the security check, that feature will be added)
================== NOW, DO IT IN REVERSE! ============================
8. Use a DIFFERENT 'salt' and 'secret mix' in the server to create a string to return to the user computer.
9. Unravel that string in the local software and turn on the features.
See, 'simple'!  (less than 10 steps!)  

After years of wanting a replacement for 'Media Player' as a background player (and suffering the last time with it picking the same 'random' songs over and over...) - I decided to make something in AutoIt as a 'relaxing' project.
Within about an hour I had a nice working start and was playing music, thanks to _SoundPlay, FileOperations.au3 and gui tools.  I now play truly random songs from my folder and NEVER repeat until the list has been gone through completely (should have done this LONG ago!)
However, I'm getting the occasional song that comes up with no sound.
I've checked the file, works fine in MP as well as re-running it in my program (as the only selected song).
Code is simple - needs a lot of work to be 'releasable' (including some code to reload the files and/or {more likely} a database... - hey, it is 0.0.0.1!), but it suits my purpose well, for now (I've got about 300 hours of songs, so a bit of time before worrying about that).
But, these 'silent' songs are driving me crazy!  Any ideas welcome!

What I'm hearing your IT manager say is "I don't know how to do that or even what you're talking about and will not be admitting it to you today".

That's one of the 'dangers' of going directly to the IT guys (sadly, most have an attitude of power...) and exactly why I suggested some other paths.  I'd try going through your manager - presuming you have permission and a requirement to gather it for your job, and permission from your boss to work on the program project - seems a more politically correct path ("It will help me in my job as well as X people in the group, etc.").
You really need to have some 'hard numbers' on the time/work savings and for how many, etc. to get this access, even though it isn't asking much, IMHO....  Write up some numbers, make a small report, etc. and give it to your boss.
Once the boss buys into the project and sees value, plus has a report in hand that shows how much the group will save (thus, handing him/her all the data they need to go further with no effort on their part and getting all the credit....... - yeah, becoming the boss' idea....), then IT has no option but to open a link for you.  
Also, a bit of 'power' for your end on the report - as you are not asking for anything other than the data already shown, the command you need is nothing other than the one being used now, so there should be less than 10 minutes work on the part of IT (i.e., no unreasonable burden).  All you need is the sql command, or a program that does that and puts the data to an external flat file (if they bring up the argument of giving you access directly into the database, etc.) and it is the same data, just output in a different manner where you can then process it fast and give additional value to 'millions' (ok, maybe not, but quantify it!)
Oh, and since you have already taken it to IT, you can use that info in your report - in a positive way, though!  What were the IT guy's issues (probably feeling like it was a lot of extra work to them, etc.)?  Make sure you address anything they said to you, whatever it was.  That way, when the boss takes "his" idea to the IT guy, he already has the answers to those issues, written in a nice report.....  (i.e., don't give IT any way to let the boss look bad - that backlashes pretty heavily!)
Looking at your program, I think you might speed it up slightly going a different route,  though not likely worth the effort to even evaluate different methods.  The only way to 'significantly' speed it (which is what you need to make it worthy of doing the project at all) is to get direct access to the data.  So, before you mess with the code any more, use your time to write a comprehensive report that the boss can take to the big boss - that is the best use of your time, and the way you will get the results.

I think you want Eval(...).

'?do=embed' frameborder='0' data-embedContent>>

first, let me clarify......   "tow time" = TWO TIMES (@Danyfirex explained it though I thought you might still miss that finer point.  I've been married to a Russian woman for 20 years and I'm now living in Ecuador, so I'm used to reading and speaking 'non-native', though not everyone is)
on the array - glad my crude diagram helped (again, living with and teaching technology to non-native English speakers has given me some 'talent' for KISS training......  
To your question - it could be that you would want to create an array like that, though what you are doing in your example is creating an array of folder names to a path - not at all what I would call 'common' use, but again, you could - after all, it is just "words on a page" (as I like to call it - others call it "data"....) - and while those 'words' mean something to someone, part of your task as a programmer is to forget about what those things do/say/spell/mean and simply manipulate them around as you need them.  (this is probably a different concept for you, so don't worry if you don't grasp it first time, but the closer you get to separating yourself from the 'meaning' of what is moving around, the faster you can learn what arrays (and database segments, etc.) can do for you.  
They are just storage locations for 'words' (or pictures, or....... - data!)
keeping my piece-o-paper vision handy, look at arrays another way - think of a school locker, or perhaps a row of post office boxes, stacked on top of each other.  For our example, think of ONE row only!  (either vertical or horizontal, though typically arrays are thought of in a vertical stack - like the piece of paper....)  Arrays can grow to many rows and columns (if you have dealt with spreadsheets, these terms are easier to understand), but we are talking about a simple array, one 'stack' (or column if you prefer...)
Now, getting back to your example of 'folder1folder2folder3 - if what you are doing is breaking up pathnames, then you seem to be getting the idea very well.  You break the data by whatever delimiter you can (which sometimes is a or comma, or even X characters - whatever it is...) and you put the bits, one per each location, into each 'storage box' (or locker, or 'stack location' - again terms are not important other than your understanding).
So, in your example, if you have an array called $pathtofolder and you did a split of the pathname 'folder1folder2folder3 by , you would have
$pathtofolder[0] = 3   <<======  this is how AutoIt handles things most of the time (it is a bit confusing because it is not always done this way - see below)
$pathtofolder[1] = folder1
$pathtofolder[2] = folder2
$pathtofolder[3] = folder3
So, yes, you are on the right track, I think.
Now, I won't go into detail on the [0] array bit - AutoIt handles it in various ways and you should read the docs for some details on when/why/how it might change, but know that 1) you have control over how it works and 2) AutoIt gives variations that are very powerful when used correctly (i.e., I was very confused at first, but after a few days of messing with it, I have grown to really like the use of the [0] array bit and think it is quite a handy tool).
Keep studying on arrays and think of stacks of boxes (or whatever) and then you can put something in each one, as/where you like.  As long as you have some way to keep track of where that thing is, you can easily go get it, use it and put it back (changed or not - your decision) in the same place, or add it to another box, throw it away, etc. (i.e., manipulate the data as you like)
Hope this helps.

I had seen the UDF (in one of my searches around), and have considered it, though haven't had the time to learn about it along with all the other new things I'm digesting (sometimes I feel like I'm getting fed info about AutoIt about as fast as a whale scooping up krill - though still in human form.......) - it is on my list of things to study further and I will likely use the UDF - moving from disk to memory was my first thought when I had some speed issues, though the tip on BEGIN/COMMIT (I think it was from one of your posts - seeing the avatar, I know I've read a lot of your info) worked very well for my current project.
Your comment about 'such a tiny DB' also encourages me.  The world I've been around calls 50k records (of 20-30 columns with various data up to 300 characters) 'big' - I've always felt that a few times that is 'medium' perhaps, though I have seen discussions on millions of records being considered 'small'.  It all depends on your project and point of view, though with my current skills and knowledge, I would not consider using AutoIt with SQLite for such a database in my project, which is not a persistent DB, it is rebuilt from filenames on every run (the only way we can guarantee the data and then properly manipulate it).  We aren't doing a 'build it and then search many', we are (simply?) processing current filenames, manipulating the data, reformatting according to various rules and options, then updating the file names to be in a consistent manner.  The process is only run a few times and all filenames are updated, so 'long' process times of 3-5 minutes isn't horrible.  One similar product takes up to 20 minutes to update their database, so I'm not unhappy with my times, just looking for ideas on if I'm burning up resources I shouldn't.  Seems I'm in the ballpark though.
I will look at the UDF again as I get the project nearer completion (i.e., finish all these last features up, clear some bugs, etc.) - for now it may become a future update function.
While we are on the 'speed' discussion, I do have an issue with processing that I was thinking of making a new topic with - if that is best, let me know.
While I'm running a process (reading the filenames, manipulating them, etc. - all in AutoIt and memory (i.e., no disk activity), though building the SQLite commands, if I go to another program (while I'm waiting I read forum posts, help files, etc. to learn something else, or do a bit of coding - whatever), it seriously affects processing time.  Again, I'm used to php and server processing in the back-end, with massive processing power, multi-tasking, etc. going (I'm not all that familiar with the details, but I know it is a different method altogether than GUI and user-side processing) so never worried about such things, but my time to process some 30000 records I have in a test base goes from ~3 minutes (when just watching the program) to  L O N G  - sometimes 10+ minutes or more when I am off looking at other things.
I know this has to do with keeping window focus on the process - I can, at any time, click on the progress window and it speeds up quickly (I have it updating a progress meter with 'time spent' every few hundred records to see the progress) and I wonder if I could/should use something like (I know this is not the program and I will figure out all the correct commands, I'm just wondering if this is the right approach);
Local $mywindow,$activewindow while 1 $activewindow = _WinAPI_GetFocus() If Not $mywindow Then Static $mywindow = $activewindow EndIf _WinAPI_SetFocus($mywindow) ; process a bit - maybe a few hundred records = ~ 300ms _WinAPI_SetFocus($activewindow)   If (identify 'all records processed') Then ExitLoop EndIf WEnd to keep the focus 'somewhat' on my program (allowing the user to do other things, though with an understood 'cost')
Perhaps WinActivate is more correct, etc. - again, I am not asking for a written program, I'm happy to do that, just want to understand if I'm on the right track with the best method to pursue (i.e., 'focus switching') when I get to the point this feature moves up on the priority list.  I do a lot of 'look-ahead' thinking on every program part, when I see a potential for a customer complaint I try to make sure I know the direction that I need to study long before getting into that part of the programming - to me, that is 'best practice' instead of waiting until it is urgent and then having to piece-meal some bit of patch-up code to cover - and.....  worse thing ....having to go back and fix all the mess later.
We are currently covering this 'known issue' with documentation (stating that they need to stay on this window or processing time will suffer) - or is there some other way to achieve the same/better results in AutoIt?

Nice tutorial - hadn't seen that page - learned a lot about what, to me, has been the most confusing part of moving to AutoIt.
I come from years in php - tossing variable names in/out/around at whim (and often getting lost in a mistyped letter that takes hours to find..... - one of the things I really like about AutoIt is helping me catch that stuff).  From the tutorial I see that AutoIt actually gives Global to variables in the script and Local to function variables - I've taken to using the AutoItSetOption("MustDeclareVars", 1) directive to help break myself of willie-nillie naming (and have seen my code tighten up dramatically - finding that using ONE Global variable called $temp very useful for doing minor checks that I only need for a couple lines.  Sure keeps the page cleaner!
One thing, though, from the tutorial that I still don't quite understand is shown below
Foo() Foo() Foo() Func Foo() ; Set the flag only on the first entry into the function ; This assignment will be ignored on subsequent entries Local Static $fFoo_First_Pass = True ; Check the flag If $fFoo_First_Pass Then ; Immediately clear the flag to prevent running on subsequent passes $fFoo_First_Pass = False ; Run on first pass because flag is set ConsoleWrite("First pass" & @CRLF) Else ; Flag remains cleared for subsequent passes ConsoleWrite("Not first pass" & @CRLF) EndIf EndFunc ;==>Foo I believe I understand it now (though just looking at the code, it certainly requires an understanding of the Static declaration), however, I was confused by the text
Perhaps (at least, for me), it would be more easily understood to change 'assignment' to "re-assignment attempt" - or something like that.  What I thought, at first, is that the INITIAL assignment is ignored, though that would, of course, negate the function of Static....  
Anyway, I now understand what it can do - just have to find a great use for it, then use it over and over a few times - in the meantime, I'm bookmarking that page!
One other 'take away' from reading this tutorial that I really was happy to get clear is the ByRef.  That had me totally baffled until I read this.  Now, I see why all the 'pros' using AutoIt run everything in functions - I was just making main code with functions as a by-product (php style I have used for years).  ByRef can certainly be used to great advantage - though I am not planning to go back to all my previous AutoIt scripts and change things, I am going to be using these powerful tools to make things easier in the future! 
One question that came to mind in digesting all this (and it has a direct reflection on the project I'm working right now) - what is the 'best practice' and 'fastest', perhaps 'prefered' (terms that are, I know, difficult to scope, however.....) way to manipulate data of small-medium (in my world) lists of text (in this case, the 'core customer' will often be dealing with some 50k songs - not very big, though some will reach in the 100K - 200K range and I wonder more about if my code is right for them).  
I read the filenames, dissect and manipulate them in various fashion (breaking out the Artist, Title, etc.), then rename/manipulate as/when needed (fixing caps, spelling, fname/lname switch around, etc.)  Lots of features/functions, though lots of potentially wasted time doing too many disk writes).  I wrote all this in php and was very satisfied with the processing times I got using MySQL on a local server base, though when I found how unsecure it all was, I got into AutoIt and am porting everything over.
I'm getting fast times using SQLite (thanks to a tip from the forum to use BEGIN/COMMIT - brought the time to process the list down about 90%) - ~30 seconds to do the first run for 32K files (compared to the MySQL times of ~30 seconds to do all the runs, it is quite a bit slower, though 'acceptable'.)
I'm wondering about holding 'all that' data (perhaps it isn't much in today's world of multi-gig memory??) in arrays when there is 5X that.  I've not run into any problems with my 'small' list, but I am doing a 'safety save' of the data in the middle of processing to make sure we have the changes, then reading it back to a clean array (in a slightly different, smaller manner - that could easily be taken care of in memory) before going on with the re-work part of the program to make sure the larger data sets are as protected as possible (of course, the customer will let me know if things crash!).
Any tips on how 'best' to handle things are much appreciated.   (and, sorry for swinging the topic a bit, though I believe the original question is answered)

also being new to autoit, I, too, am having challenges understanding what these are/do, though I have found the best teacher to be experience in this matter (I read all the materials and still was left with questions.
So, I went into the SciTE editor, copied over some files from the Help and ran them, changing Dim, Local and Global around a bit to see the difference.  Most of the time, there isn't much difference you can see, but after writing my own program and putting all of these to 'Global' (I had thought, why not, "Global" sounds good - I can use them anywhere and not have to mess with all this again!") - well, let's just say that setting everything to Global is NOT a good idea!
So, what is the right idea?  When do you use which one?
Again, I'm no expert, but here is how I am currently seeing these work:
Global - use when you really (and I mean 'really') need to have a variable available anywhere in your code.  Sparingly is a good thing to think about here.  I don't know why, but using it all the time does cause problems, so I use it now on just a few things that I have to have and it works better.
Local - use this "all the time" - it is good for things you need to declare for something 'small', like something you use in a function.  My current thinking (as/until I learn more) is to write my programs with Local on all variables then 'see what happens' and when an error shows up on that variable, I try Global.  Most of the time now (after just a few programs) I am learning how/why/when Global should be used, but still I fall back to this as a first step.
Dim - well, so far, I haven't had to use it so I don't know much about it (and I'm well into my 5th autoit program and in this one I have nearly 3000 lines of code).  I'd say it isn't as required as the others, though I'm sure it has valuable reason for being.  I have used ReDim quite a bit, which resets the size of arrays. 
That is a 'newbie' look at these commands.  Like all, though, the more you program and practice, the more likely you will NEED one of them - that is when you really learn about them (i.e., my recommendation is to get out of the books and into a PROJECT of some sort - makes you dig in a different way.)

well, there you go!  One of the (oh, so very few, IMHO) 'useful' docs put out by 'the horse'....
that link goes into my bookmarks.

I used to have a bookmark for dos command prompt commands, though can't seem to find it - haven't used it in a long ( L O N G ) time......
but a quick search on Google came up with dozens of 'how to' links.  first one I looked at seems about as 'standard' as any (you really should try those searches - loads of great data and by reading several sites, you will always get your own 'best' knowledge - some sites may have wrong or missing data, but you hit 4-5 of them and you will find the 'common thread' of information.  Doing a bit of reading on each site will get you tons of knowledge fast.  And, you may find one that just happens to have a new command you never saw (though DOS has been out so long with no changes it is very well documented) - that is how I learned to program php years ago - and still constantly search for various ways to do things.
want more direct info?  then formulate an idea of what you want to achieve (not just 'learn about CMD' - that is very vague....) - then ask yourself a question about getting it done.  put that question in the search engine - you will be amazed......

I believe this is better suited to what you want to do......
https://www.autoitscript.com/autoit3/docs/functions/ProcessClose.htm

thanks for the correction on that.  I'm pretty new to AutoIt and only used the 'most' option so far, though I read about the OnEventMode and will, one day, mess around with it to see how it works (my latest project is rather large - porting over a package of tools from .php to run on a local machine with GUI, etc...) and OnEventMode looks like it may be a good choice for my programming style, though trying to learn the basics right now.

EDIT: (I tried the code - it works like 
JLogan3o13  says. - even complied)

in every _GUI function in AutoIt you will see something like this
    While 1
        $GUIMsg = GUIGetMsg()

        Switch $GUIMsg
            Case $GUI_EVENT_CLOSE
                ExitLoop
        EndSwitch
    WEnd
that is needed to be able to close the window when clicking on the red X in the corner.
Also, I don't know about others, but I think you should post your code in this forum, not on another where things need to be downloaded, etc.