Falcone88

That would probably work if I had the filename, but unfortunately I only have the window title. Is there a way to get a process' file location? I know if I really wanted to I could find the PID from the window title.... EDIT: @maqleod WOW that might be exactly what I was thinking of... I'll check it out EDIT2: After some fiddling around I got it to work using GuiCtrlCreateIcon() Unfortunately it's quite slow, so I might fiddle around to see if I can make things more efficient. Thanks so much! You'll probably hear from me soon EDIT3: This is much faster for my purposes: Func _ProcessGetPath($iPid) $oWMI = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") if IsObj($oWMI) Then $colProcs = $oWMI.ExecQuery ("select * from win32_process") if IsObj($colProcs) Then For $oProc In $colProcs if $oProc.ProcessId == $iPid Then return $oProc.ExecutablePath EndIf Next EndIf EndIf return "" EndFunc I'll probably post what I used this for sometime in the near future

Is there a way to use an hwnd or the title of a window to locate its icon file, and use that in an autoit GUI? I've been searching for a while and haven't found anything related, but it seems like I have seen something similar before.... Thanks!

Updated to use the new Binary functions and such. That was a pain! Got logging in with Oscar to work! now just have to figure out why I can't send IMs.... See first post for updated _TocLib.au3

Got it! FINALLY it works! I had to do some fiddling with my parsing functions to deal with the receiving of data, but it works now. If you're interested, my new _BinaryNumber function is: Func _BinaryNumber($iNum, $iLength=2) Local $b, $numStarted=false, $out="", $prepend="" $b = Binary($iNum) for $i=BinaryLen($B) to 1 Step -1 if Chr( BinaryMid($b, $i, 1) ) <> Chr(0) or $numStarted Then if not $numStarted then $numStarted = true $out &= Chr( BinaryMid($b, $i, 1) ) EndIf Next if BinaryLen($out) < $iLength Then for $i=1 to $iLength-BinaryLen($out) $prepend &= Chr(0) Next EndIf return $prepend&$out EndFuncoÝ÷ Ø l¢Øb²+-çÚé¢ëAv«É+kxºw-ȺǬzÜz)íéh)ìz«ÇºØ­Á«'yç^w}ÚºÚ"µÍ[È[TÝ[È ÌÍÜÑ]JBBSØØ[ ÌÍØH[J ÌÍÜÑ]JBSØØ[ ÌÍÛÝ]H ][ÝÉ][ÝÂBYÜ ÌÍÚOLHÈ[S[ ÌÍØBBIÌÍÛÝ] [ÏH Ú[SZY ÌÍØ ÌÍÚKJH H BS^] ÌÍÛÝ] B[[

Yes, I think the problem is with how it gets sent over TCP, or rather the way TCP understand that data. I'm not sure how to word it correctly... The SOH and stuff, I guess, must just be how the old version represented the data; it's just the ascii representation of the byte value: http://www.autoitscript.com/autoit3/docs/appendix/ascii.htm I guess the new version displays the hex code value...? That still doesn't help me, though

Yes, but you can send raw ansii and such. TOC protocol uses plain text for its commands. I agree that [sOH] is how the console is displaying the data. It's just showing the ascii representation of the byte, I guess. What, specifically, would you like a screenshot of?

No, [sOH], etc. are single characters. It looks like SOH in white letters on a black, rounded-rectangle background. I can't copy it because it's not really ansii, I guess. Yes, I know about Binary. Unfortunately, using that doesn't work. I'm trying to send this data over TCP, and using that isn't accepted/understood by the server

Without couching it with String(), you can't see the value of _BinaryNumber() for 1, 32, and 128. It has chr(0) before it. 270 = [sOH][sO] (Those are just 1 char each, but I can't copy them properly) 1024 = [EOT] 5000 = [DC3]^ What I'm trying to do is get the raw bytes from a string or integer. In Java, you could just do stream.print( number.getBytes() ); but nothing like that exists in Autoit -- hence my rediculous _BinaryNumber() function. As I explained, it used to work great with the old implementation of BinaryString(), but now in the newer version of Autoit, it's broken (PS: The arrow thing was just me testing to make sure it gets decoded properly; I know the decode works) EDIT: Food for thought: Using this as a replacement for BinaryString, it *looks* the same as in the old version, but it is apparently not understood by Oscar. I guess it doesn't convert to Binary/byte type properly... Func BinaryString ($sData) ;return Binary( ($sData) ) Local $b = Binary($sData) Local $out = "" for $i=1 to BinaryLen($B) $out &= Chr( BinaryMid($b, $i, 1) ) Next return ($out) EndFunc

Thank you for the link, that's exactly what I was looking for. Even if you wanted the explanation, I probably couldn't give it. But the fact remains that it doesn't work for this problem. Thank you, though.

Perhaps a dev can explain what exactly changed between BinaryString() and Binary()? EDIT: Decided to throw a quick for-loop together to illustrate how it SHOULD work: loop: for $num = 240 to 270 $enc = _BinaryNumber($num, 4) $dec = _BinaryNumberDecode($enc) ConsoleWrite("("&$num&" -> "&$dec&") = " & String($enc) & @LF) output: (240 -> 240) = 0x000000F0 (241 -> 241) = 0x000000F1 (242 -> 242) = 0x000000F2 (243 -> 243) = 0x000000F3 (244 -> 244) = 0x000000F4 (245 -> 245) = 0x000000F5 (246 -> 246) = 0x000000F6 (247 -> 247) = 0x000000F7 (248 -> 248) = 0x000000F8 (249 -> 249) = 0x000000F9 (250 -> 250) = 0x000000FA (251 -> 251) = 0x000000FB (252 -> 252) = 0x000000FC (253 -> 253) = 0x000000FD (254 -> 254) = 0x000000FE (255 -> 255) = 0x000000FF (256 -> 256) = 0x00000100 (257 -> 257) = 0x00000101 (258 -> 258) = 0x00000102 (259 -> 259) = 0x00000103 (260 -> 260) = 0x00000104 (261 -> 261) = 0x00000105 (262 -> 262) = 0x00000106 (263 -> 263) = 0x00000107 (264 -> 264) = 0x00000108 (265 -> 265) = 0x00000109 (266 -> 266) = 0x0000010A (267 -> 267) = 0x0000010B (268 -> 268) = 0x0000010C (269 -> 269) = 0x0000010D (270 -> 270) = 0x0000010E Without the String(), all of the values of $enc are unreachable, due to the null padding before it. Here's an example with $iLength of 2, instead of 4 as with the above code: (240 -> 240) = (241 -> 241) = (242 -> 242) = (243 -> 243) = (244 -> 244) = (245 -> 245) = (246 -> 246) = (247 -> 247) = (248 -> 248) = (249 -> 249) = (250 -> 250) = (251 -> 251) = (252 -> 252) = (253 -> 253) = (254 -> 254) = (255 -> 255) = (256 -> 256) = (257 -> 257) = (258 -> 258) = (259 -> 259) = (260 -> 260) = (261 -> 261) = (262 -> 262) = (263 -> 263) = (264 -> 264) = (265 -> 265) = (266 -> 266) = (267 -> 267) = (268 -> 268) = (269 -> 269) = (270 -> 270) = Note that the weird characters (if they show up) aren't what you see in SciTE... Hope this helps

Nope. It's a bit more complicated. The first digit is an offset, and if you don't take that into account you lose value. 256 becomes 0, for example. Yes, it works for small numbers, but above that you get into problems

A valid question, but yes there is a reason: I don't control the server. This code is part of my in-devlopment _OscarLib to communicate with AOL's Oscar servers.

Hm... doesn't seem to work for me.... The extra loop is to ensure that it's the appropriate length. The default of 2 works just fine without the loop, but sometimes I need a DWORD value, which would be length 4. For values that aren't large enough to take up all four spaces by themselves, you need to pad with null character. If it helps, here is my decoding function which should still work just fine; it didn't use BinaryString: Func _BinaryNumberDecode($iNum);, $iLength=2) ; A shortcut! if StringInStr(String($iNum), "0x") Then $iNum = StringMid(String($iNum),3) return dec($iNum) EndIf $iOffset = 1 While StringMid(String($iNum),$iOffset,2) == "00"; or StringMid(String($iNum),$iOffset,2) == "0x" $iOffset+=2 WEnd $sTrim = StringMid($iNum, $iOffset) ;~ _DebugPrint("Trim: " & $sTrim) $iLength = StringLen( $sTrim ) $iVal = 0 for $i=1 to $iLength $iVal += Number( String( Asc( StringMid($sTrim,$i,1) ) ) ) * (16^ (2*($iLength-$i))) Next return $iVal EndFunc ;==>_BinaryNumberDecode

With some fiddling, numbers >= 255 seem to work alright: Func _BinaryNumber($iNum, $iLength=2) Local $ret="", $iOffset, $iVal if $iNum < 255 Then $ret = StringLeft( Binary( $iNum ), 1 ) Else $iOffset = Floor( $iNum / 256 ) $iVal = Mod( $iNum, 256 ) $ret = Binary( Chr($iOffset) ) & Binary( chr($iVal) ) EndIf if StringLen($ret) < $iLength Then ConsoleWrite("Foo") Do ConsoleWrite( BinaryLen($ret) & "="& $iLength & "," & String( StringReplace($ret, chr(0), "00")) & @LF ) $ret = ( Chr(0) ) & ($ret) Until StringLen($ret) >= $iLength Else return BinaryToString($ret) EndIf return ($ret) EndFunc ;==>_BinaryNumber

@Smoke: Yes, I still have the original with old version of autoit on my old computer. 1024 = [EOT] (It's white letters on a black background... couldn't copy it) 256 = [sOH] (see above) Numbers less than 256 don't show up in the console as raw, probably because they're padded with chr(0) at the beginning. But, if you run string() on it: 200 = 0x00C8 @vintorecavaj: I tried already with BinaryToString and it didn't seem to work @Siao: It is "basically" converting it to hex, but not really. What I'm doing is converting an integer to the a word or dword, for $iLength 2 and 4 respectively, to be sent over TCP. I will experiment with your suggestions, however.

Unfortunately, that doesn't work Thank you, though

Hi, I just got my new laptop and installed the latest version of AutoIt, and was puzzled to find that what I had working for my _OscarLib project didn't work anymore. I located the problem as being with my binary number conversion function, with the source being the removal of BinaryString (well, renaming to Binary). I checked the history and it says that they were rewritten and scripts will have to be changed... How should I go about changing them to get the old functionality back? Thanks! If it helps you, this was my _BinaryNumber() function: Func _BinaryNumber($iNum, $iLength=2) Local $ret="", $iOffset, $iVal if $iNum < 255 Then $ret = StringLeft( BinaryString( $iNum ), 1 ) Else $iOffset = Floor( $iNum / 256 ) $iVal = Mod( $iNum, 256 ) $ret = BinaryString( Chr($iOffset) ) & BinaryString( chr($iVal) ) EndIf if StringLen($ret) < $iLength Then Do $ret = BinaryString( Chr(0) ) & $ret Until StringLen($ret) == $iLength EndIf return $ret EndFunc ;==>_BinaryNumber

Just a quick update on _OscarLib: I've finally fixed _BinaryNumberDecode! When I get back from Europe I'll update _TocLib with it. _BinaryNumber probably needs fixing, but that's another thinking thing. Anyway, got to the next step in signon for Oscar, thanks to that fix. Should be relatively easy to get the rest working... it'll just take a while. There are 14+ steps for protocol management in Oscar! Jeez!

Okay, so apparently TOC doesn't support the +(phonenumber) format of SNs, so you can't use this to text your cell, like I thought you could. It still works for receiving... but whatever. In other news, my AIM client has a huge memory leak somewhere (If you leave it alone for half a day it starts using 100% of the CPU...) so that project is on hold. I've narrowed it down to the buddy update handling function, but I'm too lazy to find exactly what at the moment. I was surprised to find that the GUI update functions weren't the cause... Maybe the arrays.... Anyway, I'm more interested in cell phone interaction, so I've started to (very slowly) implement the Oscar protocol, which I know for a fact works with cell phones. It's going fairly well so far... I can connect to the auth server and retrieve BOS login info... Now I've slowed down at the extremely excessive protocol negotiation, partly due to SNAC packets, I think. Also, my laziness in hardcoding the _BinaryNumberDecode function is coming back to haunt me.... It shouldn't be too hard of a fix, I'm just too tired to really think atm So wish me luck with Oscar! If/when I ever get it done, I'll hopefully make a config for my myCommands script and release what will be v5. Maybe someday I'll try to fix the leak in my AIM client....

Uploaded version 2.2.0.0 with a few more changes: _TocNormalizeString was renamed to _TocNormalizeName. _TocNormalizeString is a new function that properly parses any strings. So, you can now use HTML properly! I think there were a few minor fixes, but I forget now.... My AIM client is close to being done, but there's a weird bug where its CPU usage goes ridiculous after a while, and I'm working on fixing that.... I may post it and ask for help, though. We'll see!

Another brief but important update. Sending IMs with quotes in them broke previously, but they work now If there are other characters that need to be caught, let me know EDIT: I went ahead and took into account a few other characters, just in case. The [] characters were causing problems, so I'm guessing that <> and a few others will too... Again, if you see more, let me know

Updated the file with a new function and a new feature. Also, made a list of all the function names. Please see first post

What do you mean by ID? Do you mean can more than one script use the same AIM functionality? If so, then at the moment the answer is no. I haven't figured out a way to open a previously open tcp connection from a separate program, but I haven't really looked into it much. If someone else has an idea, I'd be thrilled

Well, even without suggestions I finally figured out the proper format for those numbers in the FLAP header. As far as I know, everything works perfectly I removed the old file and uploaded the updated one. See first post. Development on my AIM client can now continue. Stay tuned Any more questions/comments? I'm surprised more people aren't interested... you can use this and AIM's cell-phone communication abilities to do some interesting things. I also have a program I made to take advantage of that which I'm updating to use this new udf...

You're using the _TocParseIM() function, right? The first index of the array that returns is the username of the person who sent it.... Am I misunderstanding the question?