Greenhorn

Hi, as far as I know (and from my experiences) you can not create a message loop with GetMessage in AutoIt. Because the main function of the AutoIt-Interpreter has already a message loop for the running thread. If you still do it, AutoIt crashes or never stops running. But you can call GetMessage sporadically, that's OK. Regards Greenhorn

Hi, please post the output. Without this info I just can guess ... Which version of AutoIt do you use? Regards Greenhorn

Updated to Unicode use and some little Bugfixes ... Regards Greenhorn

Yes, I think with the optimization switches on, the compiler should do it in this way ... I've just tested the function in 64 bit Debug configuration and I had a lot more bytes than 39. EDIT: Your right Valik, I've tested it in Release configuration and the generated listing file shows the same ... Here is trancexx's function... ?ChrInStr@@YAHPEB_W_W@Z PROC ; ChrInStr, COMDAT ; 225 : if (sString == NULL) return 0; ; 226 : ; 227 : for(INT i = 0; sString[i]; ++i) 00000 0f b7 05 00 00 00 00 movzx eax, WORD PTR ?szTitle@@3PA_WA 00007 33 c9 xor ecx, ecx 00009 8b d1 mov edx, ecx 0000b 66 85 c0 test ax, ax 0000e 74 1d je SHORT $LN2@ChrInStr 00010 4c 8d 05 00 00 00 00 lea r8, OFFSET FLAT:?szTitle@@3PA_WA ; szTitle $LL4@ChrInStr: ; 228 : { ; 229 : if (sString[i] == sFind) return i; 00017 66 83 f8 69 cmp ax, 105 ; 00000069H 0001b 74 13 je SHORT $LN9@ChrInStr ; 225 : if (sString == NULL) return 0; ; 226 : ; 227 : for(INT i = 0; sString[i]; ++i) 0001d 41 0f b7 44 50 02 movzx eax, WORD PTR [r8+rdx*2+2] 00023 48 ff c2 inc rdx 00026 ff c1 inc ecx 00028 66 85 c0 test ax, ax 0002b 75 ea jne SHORT $LL4@ChrInStr $LN2@ChrInStr: ; 230 : } ; 231 : ; 232 : return 0; 0002d 33 c0 xor eax, eax ; 233 : } 0002f c3 ret 0 $LN9@ChrInStr: ; 228 : { ; 229 : if (sString[i] == sFind) return i; 00030 8b c1 mov eax, ecx ; 233 : } 00032 c3 ret 0 ?ChrInStr@@YAHPEB_W_W@Z ENDP ; ChrInStr ...and here is mine... ?ChrInStr_@@YAHPEB_W_W@Z PROC ; ChrInStr_, COMDAT ; 237 : if (szString) ; 238 : { ; 239 : for(INT i = 0; szString[i]; i++) 00000 0f b7 05 00 00 00 00 movzx eax, WORD PTR ?szTitle@@3PA_WA 00007 33 c9 xor ecx, ecx 00009 8b d1 mov edx, ecx 0000b 66 85 c0 test ax, ax 0000e 74 1d je SHORT $LN2@ChrInStr_ 00010 4c 8d 05 00 00 00 00 lea r8, OFFSET FLAT:?szTitle@@3PA_WA ; szTitle $LL4@ChrInStr_: ; 240 : { ; 241 : if (szString[i] == chFind) 00017 66 83 f8 6e cmp ax, 110 ; 0000006eH 0001b 74 13 je SHORT $LN9@ChrInStr_ ; 237 : if (szString) ; 238 : { ; 239 : for(INT i = 0; szString[i]; i++) 0001d 41 0f b7 44 50 02 movzx eax, WORD PTR [r8+rdx*2+2] 00023 48 ff c2 inc rdx 00026 ff c1 inc ecx 00028 66 85 c0 test ax, ax 0002b 75 ea jne SHORT $LL4@ChrInStr_ $LN2@ChrInStr_: ; 243 : } ; 244 : } ; 245 : return 0 ; 0002d 33 c0 xor eax, eax ; 246 : } 0002f c3 ret 0 $LN9@ChrInStr_: ; 242 : return i ; 00030 8b c1 mov eax, ecx ; 246 : } 00032 c3 ret 0 ?ChrInStr_@@YAHPEB_W_W@Z ENDP ; ChrInStr_ If you want to get it smaller in size (and maybe a few clocks faster), then you should write your own proc in assembly, as Valik already pointed to ... Regards Greenhorn

You save at least two bytes: "xor eax, eax" at "if (szStrig == 0) return 0 ;".If you take a look at the generated listing file or the disassembly in the debugger, you'll see. Regards Greenhorn

Hi, maybe this will shrink the code at 3 bytes ... INT WINAPI ChrInStr (LPCWSTR szString, WCHAR chFind) { if (szString) { for(INT i = 0; szString[i]; i++) { if (szString[i] == chFind) return i ; } } return 0 ; } Regards Greenhorn

Puuuh, then I'm glad that it is not my code sequence but it's taken from Holger's ModernMenu UDF ...

Oh, I'm sorry, Jos. I confused the issue with au3check ... Regards

Hi Jos, will this bug(?) also be fixed in the new version ? If Not IsDeclared("MY_CONST") Then Global Const $MY_CONST = 0x0001 Regards Greenhorn

Hi, WS_EX_COMPOSITED is buggy (on XP) because the buttons of the system menu in the title bar (minimize, maximize and close) are not highlighted anymore. There is no general concept to eleminate flickering from your application. Some hints: Don't use CS_HREDRAW/CS_VREDRAW in your window classHandle the WM_ERASEBKGRND with return value TRUETake a look at WS_CLIPSIBLINGS/WS_CLIPCHILDRENDon't use MoveWindow () in WM_SIZE message, use BeginDeferWindowPos, DeferWindowPos and EndDeferWindowPosUse a memory DC and BitBltAnother workaround I sometimes use is something like this:Handle the messages WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE and (un)set the WS_EX_COMPOSITED style with SetWindowLongPtr. EDIT: The style WS_EX_COMPOSITED now IS declared in WindowsConstants.au3. Regards Greenhorn

Thank you very much for that feature, Nutster.

Hi, I just want to push up the request that Tweaky made: How is it possible to inform Jon about the new translation status, or how could we leave a sticky notice, that would be visible to him when he arrives back here in some time. Thanks in advance, Greenhorn p.s. The (new) german translation page is available here.

Thanks and yes, you're right, I slept while I edited the example script ... And also yes, I use ResHacker in this script, if somebody includes resources in another way, please adjust the script. I fixed the example script, so test it again, please ... Once more, thanks to all for your replies. Greets Greenhorn

Little Update ... Greets Greenhorn

Hi, maybe I'm a little bit dazed and confused ... Please, tell me on which system your script is running and which system shall "see" the stick under the drive letter "Z:", WinPE or your PC system ... To see the full actually code and a description of a scenario would help better to understand and help you. Sorry, english isn't my native language ...