-Ultima-

Kind of anyway You'll find that AutoIt uses copy-on-write optimization for arrays, so that unless the array is modified in the the function, the array never actually gets copied. In that case, the performance difference between ByRef and non-ByRef array parameter passing is absolutely negligible. There probably is still a tiny bit of overhead for not passing ByRef to functions that perform read-only operations on the array, but we're talking microseconds/milliseconds even over many iterations.

Well, at the very least, it seems to me like you're calling BeginBufferedPaint and EndBufferedPaint completely incorrectly. That is, your DllCall()s to BeginBufferedPaint and EndBufferedPaint don't pass the correct arguments. Func WM_PAINT($hWnd, $Msg, $wParam, $lParam) $tRect = _WinAPI_GetClientRect($hWnd) Local Const $tagPAINT = "handle hdc; BOOL fErase; int Left;int Top;int Right;int Bottom; BOOL fRestore; BOOL fIncUpdate; BYTE rgbReserved[32]" $tPaint = DllStructCreate($tagPAINT) $pPaint = DllStructGetPtr($tPaint) $res = DllCall($dllUser32, "hwnd", "BeginPaint", "hwnd", $hWnd, "ptr", $pPaint) Local $hDC_New = _WinAPI_CreateCompatibleDC(0) Local Const $BPBF_COMPATIBLEBITMAP = 0 Local $hDC_New $res = DllCall($dllUxTheme, "hwnd", "BeginBufferedPaint", "handle", $res[0], "ptr", DllStructGetPtr($tRect), "DWORD", $BPBF_COMPATIBLEBITMAP, "ptr", 0, "handle*", $hDC_New) ; ConsoleWrite(_WinAPI_GetLastError() & @tab & $res & @tab & IsArray($res) & @tab & $hDC_New & @crlf) $res = DllCall($dllUxTheme, "hwnd", "EndBufferedPaint", "handle", $res[0], "bool", 1) $res = DllCall($dllUser32, "hwnd", "EndPaint", "hwnd", $hWnd, "ptr", $pPaint) Return $GUI_RUNDEFMSG EndFunc ;==>WM_PAINT_Double_BufferedThis is a more literal translation of the code in the link you posted above, but clearly, it isn't actually preventing flickers, but is instead, causing more. At the very least, it's doing something by passing what should be more correct parameters. Don't know what to say about the flickering though, since I'm not quite familiar with drawing contexts and all.

Eh, edited first post with a slightly updated pack of these UDFs. The changes are relatively minor, but I've had them lying around for a very long time now, and don't feel right just leaving them alone. As originally stated in the first post, I was hoping this set of UDFs could/would be used as a thin wrapper around WinINet to provide a base for other UDFs requiring functionlity provided by WinINet (like FTP.au3), but lack of momentum and motivation set it back. At this point, most (if not all) of the important WinINet functions are implemented, and should be usable in normal circumstances. The are a few example scripts, but they are far from complete. The FTP functions should have fairly complete usage examples, though. And yes, WinINetConstants.au3 is still very much unorganized, and may conflict with other includes. If anyone else feels like they have the time and energy to pick this project up and run with it (assuming there's anything left to do), they're more than welcome. Just try to keep the original vision in mind: this is supposed to be a thin wrapper, so don't try to do too much with each function. That is, avoid building combo functions that call multiple WinINet functions just for convenience, because those probably belong on a different level than this low-level wrapper (or I suppose they could go in some *Ex() function). Of course, the alternative is to leave feedback with potential changes for me to make. I'll still be around to check this thread from time to time, and might update the UDF set myself should the need arise, but at this point, I don't feel there is much left to do with this set of UDFs -- it's more-or-less complete. Its main problem is lack of examples to help get people started (and to be used as something like basic unit tests to verify functionality). Too, I'm not sure if it's formatted acceptably to be included as part of the standard UDFs, which is partly why I haven't bothered to push for inclusion (the other reason being that FTPEx.au3 provides duplicate functionality in some cases, and I can't be bothered to update that set of UDFs too to wrap it around this set of UDFs).

Tomboy is written in C#. AFAIK, Mono compiles code into EXE files, even in Linux. Doesn't mean it's the same kind of EXE as in Windows though. In the end, Tomboy is a Linux software made for Gnome using Gtk+ bindings, which is why it interfaces with Gnome. The same can't be said for any Windows application, not even those running under Wine. That includes AutoIt.

Because you're still not reading carefully. StringRegExp() is not StringRegExpReplace(). And once again, that regular expression you're using has a syntax error, so it won't work no matter what function you use it in anyway. SmOke_N's StripEnd() works perfectly well. Why are you avoiding it?

It works. I see the following output in the console: The following will get stripped: The following will not get stripped: r00r

Because there was a slight syntax error in the matching pattern (notice the extra closing parenthesis at the end?), which SmOke_N already fixed (Edit: Bah, SmOke_N got to it first ). Also, StringRegExpReplace() doesn't modify the input string -- it returns the new string, so you're supposed to do something like $pattern = StringRegExpReplace(...) anyway. @SmOke_N: Yeah, I'm not entirely proficient in regex (though I can usually get my way around given a fair amount of time), so I didn't feel like thinking up anything more than an extremely sparse/simple regular expression ;D Edit: @jerem488: The only thing you really need to be careful with is the case insensitivity. If you do want it to strip something like "R00R" (because the "R"s are uppercase), then you need to remove the "(?i)" from the regular expression.

...? Local $sWillGetStripped = "The following will get stripped: ABCD" Local $sWillNotGetStripped = "The following will not get stripped: r00r" ConsoleWrite(StripEnd($sWillGetStripped) & @CRLF) ConsoleWrite(StripEnd($sWillNotGetStripped) & @CRLF) Func StripEnd($sString) If Not StringRegExp($sString, "r\d{2}r$") Then $sString = StringTrimRight($sString, 4) Return $sString EndFunc Is this what you're looking to do? Your post isn't exactly clear, and your example code doesn't help us figure out what it is you mean. There are too many contradictions between what you said and what you coded.

(The only time DllCall() doesn't return an array is when an error occurrs with DllCall() itself, in which case @error is set to a non-zero value) Indeed, returning False would definitely be a certain sign that there is no Internet connection, but that's more a sufficiency argument than it is a necessity argument. Meaning it won't be of much help for people wanting to find out whether there is a connection So, to get this thread back on track... Nice work on the example martin, it makes use of an interesting workaround to script delays while waiting for a result to be returned (Sorry for the slight detour I may have partly caused)

... martin never mentioned InternetCheckConnection. If you were replying to anyone with that particular line, who else could I have assumed it to be for besides me, the only person to have mentioned that particular function in this thread? But whatever, I really don't want to hijack martin's thread, and I don't want to have a debate over something as silly as this At any rate, there couldn't have been a problem with DllCall() not returning an array, as testing @error immediately after the DllCall() takes care of that. InternetGetConnectedState just doesn't work for what martin intends for this script do.

@trancexx: Your example still shows that InternetGetConnectedState doesn't work as you're expecting. I just disconnected my computer's Ethernet cord (its only connection to the Internet), and the script continued to tell me that I was online. If you have a LAN set up, WinINet seems to assume you have an Internet connection, regardless of whether it's actually active. InternetGetConnectedStateEx tells you the name of the connection WinINet is assuming works. (In my case, it always returns "LAN Connection" in the provided struct, whether or not the Ethernet cord is connected.) And yes, I know InternetCheckConnection pings. I said it was the WinINet analogue to Ping(), did I not?

Indeed, that would be a drawback to InternetGetConnectedState/InternetGetConnectedStateEx. InternetCheckConnection would probably be the more appropriate WinINet analogue/alternative for your Ping() usage (it allows you to test against a specific host URL). It's not an asynchronous call, though, so it does still lock script execution if it's having trouble connecting. And thus, it's useless an alternative (at least no more useful than using Ping() ). Edit: Perhaps you may be able to play with InternetSetStatusCallback, but I've never tried it, so I don't know for sure how/whether it would work with InternetCheckConnection.

Notice the name of the file you downloaded -- autoit-docs-v3.3.0.0-src.exe. The last open source version of AutoIt was v3.1.0 (autoit-v3.1.0-src.exe).

I can't say I'm familiar with handling COM objects in AutoIt, but from looking at the docs for ObjCreate(), it seems to me that you're using it incorrectly. The second parameter is supposed to be the name of the remote computer, not a CLSID. As well, the first parameter is supposed to be a class name -- I'm not sure if AutoIt accepts CLSIDs for that either. The DllCall doesn't look right either. Unless you already have a handle opened for some DLL, the first parameter is supposed to be a filename, not an integer. Is there any reason the iTunes UDF wouldn't suffice?

* dereferences a pointer (gets you an alias for the data pointed to by the pointer) ++ pre-increments the pointer (it's basically like an inline $ptr += (something), where (something) is the size of the item pointed to by the pointer) << is a bitwise left-shift on the dereferenced value in this case (can be performed using BitShift($ptr, -(number to right of <<))) | is a bitwise or (meaning you'd need to use BitOR(), not just a logical OR) Since there are no native pointers for AutoIt variants, I'm not sure there is any direct way to translate the code (specifically, the pointer incrementing and dereferencing). You might be able to play with an AutoIt array (or depending on the data type, the DllStruct*() functions) to achieve the desired effect, but that will most likely require changes in other parts of the code outside of this function.