Leaderboard

Try this -- #include <MsgBoxConstants.au3> Test1() ; This example demonstrates a basic replacement. It replaces the vowels aeiou ; with the @ character. Func Test1() Local $sInput = "Hello ☺ «everybody» Love ♥ and peace" Local $sOutput = StringRegExpReplace($sInput, "[^\x00-\x7F]+", " ") Display($sInput, $sOutput) EndFunc ;==>Test1 Func Display($sInput, $sOutput) ; Format the output. Local $sMsg = StringFormat("Input:\t%s\n\nOutput:\t%s", $sInput, $sOutput) MsgBox($MB_SYSTEMMODAL, "Results", $sMsg) EndFunc ;==>Display

ah yes, sorry, it was so easy to correct it ... I was almost near to correct it myself too. Thanks again (damn regexp )

So... just modify it accordingly. Try this instead -- Local $sOutput = StringRegExpReplace($sInput, "[^\x20-\x7F]+", " ")

Use Exitloop not Exit

Indeed, here it is: Global Const $WorkDir = 'C:\curl-7.60.0-win64-mingw\bin' ; PATH TO CURL.EXE ; "FIRST YOU CALL 'CurlInitiate' TO LOG IN AND THEN YOU USE 'CurlThat' THE SAME WAY YOU WOULD USE _INetGetSource" Func CurlInitiate($login, $pass) ; "NAVIGATE TO SIGNIN, SAVE THE COOKIE AND GET THE VERIFICATION TOKEN" $Search = 'curl -c cookie-jar.txt https://www.geocaching.com/account/signin' $iPID = Run(@ComSpec & " /c " & $Search, $WorkDir, @SW_HIDE, 2) ProcessWaitClose($iPID) $sOutput = StdoutRead($iPID) $aToken = StringRegExp($sOutput, '__RequestVerificationToken\s*" type="hidden" value="([^"]+)', 3) If @error Then MsgBox(16, "Error", "Token regex error.") EndIf ; "PASS TOKEN, COOKIE AND YOUR LOGIN INFORMATION TO LOG IN TO THE SITE" $SearchPre = '__RequestVerificationToken=' & $aToken[0] & '&ReturnUrl=/play/search&UsernameOrEmail=' & $login & '&Password=' & $pass ; $Search = 'curl -b cookie-jar.txt -c cookie-jar.txt "https://www.geocaching.com/account/signin" -d "' & $SearchPre & '"' $iPID = Run(@ComSpec & " /c " & $Search, $WorkDir, @SW_HIDE, 2) ProcessWaitClose($iPID) $sOutput = StdoutRead($iPID) ; "READ $sOutput TO CHECK WHETHER LOGIN SUCCEEDED" EndFunc Func CurlThat($sURL) $Search = 'curl -b cookie-jar.txt "' & $sURL & '"' $iPID = Run(@ComSpec & " /c " & $Search, $WorkDir, @SW_HIDE, 2) ProcessWaitClose($iPID) $sOutput = StdoutRead($iPID) Return $sOutput EndFunc

@ZLP, I am still missing an answer to this question: while you continue asking questions about the same script. Please provide that answer now first. * Everybody else: please stay out for the moment. * Jos

You can do it like this, also gives your function some error checking to see why it's coming back blank. The message boxes are only for demonstration purposes, you can put whatever you'd like in their place. #include <GUIConstants.au3> #include <Constants.au3> #include <GUIConstantsEx.au3> #include <ButtonConstants.au3> #include <WindowsConstants.au3> #include <EditConstants.au3> Opt("GUIOnEventMode", 1) Global $g_idExit _Main() Func _Main() Global $GUI1 = GUICreate("Template", 450, 150) $idPM11031 = GUICtrlCreateButton("CTE", 10, 30, 100, 30) GUICtrlSetOnEvent($idPM11031, "PM11031") $g_idExit = GUICtrlCreateButton("Exit", 120, 90, 100, 30) GUICtrlSetOnEvent($g_idExit, "OnExit") GUISetOnEvent($GUI_EVENT_CLOSE, "OnExit") GUISetState() ; display the GUI While 1 Sleep(10) WEnd Exit EndFunc ;==>_Main Func PM11031() $UserData = _InputBox("Enter Data") Switch @error Case 0 Run("notepad.exe") WinWaitActive("Untitled - Notepad") Send("data 1 is: " & $UserData[0] & "data 2 is: " & $UserData[1] & "data 3 is: " & $UserData[2] & "data 4 is: " & $UserData[3] & ".") Send("{ENTER}") Case 1 MsgBox($MB_SYSTEMMODAL, "Closed", "User closed GUI") Case 2 MsgBox($MB_SYSTEMMODAL, "Cancelled", "User hit Cancel") EndSwitch EndFunc ;==>PM11031 Func _InputBox($Title) Dim $data[4] Local $GUI2 = GUICreate($Title, 256, 509, 314, 374) Local $Input1 = GUICtrlCreateInput("", 19, 40, 213, 21) Local $Input2 = GUICtrlCreateInput("", 19, 102, 213, 21) Local $Input3 = GUICtrlCreateInput("", 19, 164, 213, 21) Local $Input4 = GUICtrlCreateInput("", 19, 228, 213, 21) Local $SetError = 0 GUICtrlCreateLabel("Data1", 18, 18, 180, 17) GUICtrlCreateLabel("Data2", 20, 80, 150, 17) GUICtrlCreateLabel("Data3", 20, 142, 150, 17) GUICtrlCreateLabel("Data4 ", 20, 204, 200, 17) $Button1 = GUICtrlCreateButton("OK", 18, 458, 101, 29, $BS_DEFPUSHBUTTON) $Button2 = GUICtrlCreateButton("Cancel", 126, 458, 101, 29, 0) GUISetState(@SW_SHOW) Opt("GUIOnEventMode", 0) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE ;~ Exit $SetError = 1 ExitLoop Case $Button1 $data[0] = GUICtrlRead($Input1) $data[1] = GUICtrlRead($Input2) $data[2] = GUICtrlRead($Input3) $data[3] = GUICtrlRead($Input4) $SetError = 0 ExitLoop Case $Button2 ;~ Exit $SetError = 2 ExitLoop EndSwitch WEnd Opt("GUIOnEventMode", 1) GUIDelete($GUI2) Return SetError($SetError, 0, $data) EndFunc ;==>_InputBox Func OnExit() Exit EndFunc ;==>OnExit

I've noticed another rash of unhelpful opinionated comments from you lately. Look through the history of this forum and you will see many times where we've helped people transition from AHK to AutoIt, as there are many here who do know both languages. If you "have no intent of learning it" great, or have nothing to actually add to a post, keep moving and let someone who does want to help do so.

For people new to SQLite, I'd recommend following the step by step approach: o) First install a nice 3rd-party SQLite DB manager named SQLite Expert o) Used this to design your DB o) Use the SQL tab to run the various SQL queries and statements you expect to be using o) Fine-tune the design as necessary o) Only then start coding your fancy GUI app.

Triblade, what an interesting question. Under the waters, any array is just an address of where to start finding the values in memory. Say you're storing 32-bit integers in an array, this will be stored in a contiguous block of memory. If we were to look at the memory, it would look like: base address (start) and then 4 bytes integer, 4 bytes integer, 4 bytes integer, and so on. If the base address of this array is 50, array index 2 is going to be at 50 + (2 x 4) where 4 is the size in bytes of the integer. In statically typed languages, the number of bytes for your value is determined at compile time so this can be 'baked' into the program to avoid any calculations. In AutoIt, a dynamically typed language, there exists something called a variant (based on 2005 source but probably not changed) which can store any type of data: Int, long, double, window handle, and such small data types easily fit in the variant structure. These are stored sequentially for optimization reasons with a minor overhead. Large values such as strings are stored in another location and the variant simply holds the address to this string memory, so this types of data are exceptional and should be considered carefully when thinking about performance. Multidimensional arrays get turned into flat arrays, where the indexes are multiplied by one another. So $closed[3][4] is just $closed base address + ((3 * 4) * 4). Again taking 4 bytes for each integer. So you can consider $closed[3][4] to be another syntax for $closed[3*4]. This is really not a special case for the underlying language. The CPU is incredibly fast. He always copies data from RAM to cache in sizes which are called a block. This is mostly 4K of memory at once copied from RAM, which take about 120+ CPU cycles to get into cache. Modern CPU have 3 levels of cache, called L3, L2 and L1. Depending on manufacturer, these caches have different sizes and this is a large contributor into what makes some modern CPU's feel fast and some slow apart from just raw clock speed. Accessing arrays requires the CPU to multiply the indexes and then get the whole block of memory into cache. Multiplying the dimensions for your array in your script, 0 by 0, is trivial. This takes only 1 or 2 CPU cycles. Actually retrieving the memory from RAM takes 120+ cycles. Once this memory is in cache, it will take less than 20 CPU cycles to retrieve it again. How do we know if memory is still in cache? This depends on a lot of factors, but the main factor here is your operating system. Your operating system slices the total CPU time up into what are called slices. Each thread on the operating system gets a time slice according to some prioritization mechanism. Familiarity with this might include opening up task manager, seeing the total amount of threads on the system, and changing the priority of a process to High or Realtime. Now do not be alarmed at the 2000+ something threads running on your system. A vast majority of these threads are in sleep mode, and the scheduler simply skips over them. Our program will be executing within one of these time slices. This means at the start of the time slice, our CPU will get RAM into cache and will as quickly as possible execute our program. The realistic expected time frame of accesses to the same point in memory should be around 120 cycles for the first access and 20 cycles afterwards. As long as we write our code in tight loops, where we are not voluntarily relinquishing CPU time back to the operating system when we are waiting for something, our data should still be in cache. Realistically, data still being in cache is determined by a cache eviction policy/algorithm and there is really nothing you can do about this other than not submit to thread switches and perhaps write a nice letter to Intel/AMD where you offer a couple of beers and to sacrifice a goat. Each vendor individually has their own cache eviction policy and I believe in x86 or x86-64 these are not standardized and therefore make for a source of competition for these companies.(Citation needed) Strings and large memory structures are special. In this case, the variant does not hold the data directly but holds a reference to where the data is really stored. This means the CPU must get the array from memory, which points to other blocks of memory which must also be gotten from RAM. This means not only one of those terrible 120+ cycle accesses, but several, just to access one item. There is really no good solution for this with arrays. Other data types which allow elements to be of non-uniform length might be better suited for the application. This is more or less the same for statically typed languages. THIS COVERS ARRAY ACCESS. Now keep in mind that code is just another form of data. The code must also be read into CPU cache before it can be executed. If the AutoIt language makes some bad choices regarding caches; this will severely impact performance and may invalidate some or all of the above. For example, code pointing to other code, to other code, which must all be gotten from cache in sequence is going to make a practical program - which follows all the correct performance guidelines - very, very slow. This is why the community prefers to do benchmarks - but there's nothing wrong with a little theory from time to time. I believe AutoIt to do this mostly pretty OK in practice. The AutoIt source from 2005 seems to confirm this and that's really the best I can do on this part. Disclaimer: I've had to dumb this down, and only somewhat reflects the intricacies of modern computing.