
1of10
Members-
Posts
14 -
Joined
-
Last visited
Profile Information
-
Location
Unimatrix Z03, The Hive
-
Interests
COMPUTERS!!<br /><br />And some other stuff, in no particular order:<br />Ham Radio, Electronics, Electrical, Programming, Surfing �a la Web de la Wide World�, Movies, Music, Felines, «EQUINES», Canis-Lupus, Off-roading, General Laziness & Mastering the Art of Chesterfield Spuds
1of10's Achievements

Seeker (1/7)
0
Reputation
-
I'm trying to build a fully automated router restarter to handle the entire process of logging into my router, loading the page with the restart form on it, submitting the form and displaying the appropriate pages from the router. So far, I have built a GUI that performs all but the login correctly. What happens is the script will load the correct page that contains the restart form, but at the point of submitting the form -- to trigger the router to restart -- I get an IE error page that basically says it could not find the site. The strange thing is that it works perfectly if I have previously logged in successfully and saved the credentials in IE's password manager. It's like the script uses the authorization I send with the request for the page with the form on it, but then uses empty authorization to submit the form. Here's a snippet from my full script. I use the ActiveX IEObject.Navigate() to send the HTTP authorization header because I couldn't find an appropriate function in AutoIt3 or the IE UDF... (Did I over-look one?) The variables $RouterURL, $AuthStr and $FormNum are retrieved from an INI file, shown below. #Region >>> IE #include <IE.au3> $__IEAU3Debug = True _IEErrorHandlerRegister() $oIE = _IECreateEmbedded() $oSink = ObjEvent($oIE, "_IEEvent_", "DWebBrowserEvents") If @error Then MsgBox(0x10, Default, "DWebBrowserEvents Hook Error: 0x" & Hex(@error, 8) & " (" & @error & ")") Exit EndIf #EndRegion <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< #Region >>> GUI ;~ #include <GUIConstants.au3> ; 0x80CE0000 = PopUp+Caption+MinimizeBox+SizeBox+SysMenu ; 0x14CF0000 = Overlapped+Visible+ClipSiblings $InetGUI = GUICreate(StringTrimRight(@ScriptName, 4), 810, 240, Default, Default, 0x14CF0000) $InetObject = GUICtrlCreateObj($oIE, 1, 1, 800, 218) $InetStatus = GUICtrlCreateLabel("Status", 1, 221, 698, 18, 0x100B) ; (Sunken+Simple) $InetProgress = GUICtrlCreateProgress(700, 221, 100, 18, 0x0) ; (Smooth)=0x1 GUISetState() #EndRegion <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< #Region >>> Core ; SYNTAX: object.Navigate(url As String,[Flags As Variant,][TargetFrameName As Variant,][PostData As Variant,][Headers As Variant]) $oIE.navigate($RouterURL, "", "", "", "Authorization: Basic " & $AuthStr & @CRLF & @CRLF) _IELoadWait($oIE) $oForm = _IEFormGetCollection($oIE, ($FormNum - 1)) ; convert to zero array _IEFormSubmit($oForm, 0) ; no_wait Do ;~ Sleep(5) Until GUIGetMsg() = -3 ; $GUI_EVENT_CLOSE Exit #EndRegion <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< RouterURL=http://172.31.110.1/tshtml/tools/misc.html AuthStr=<Base64-encoded Username:Password String> FormNum=2 What I want is for this GUI to trigger the router to restart when launched from any user account, regardless of whether or not the account has previously logged into the router web configuration or saved the credentials in the password manager. In other words, I want the Guest account to be able to restart the router by simply running this script.
-
Question on windows Startup and autoit.
1of10 replied to Darkinspiration's topic in AutoIt General Help and Support
I have actually done such a thing: mapping drive letters to network shares before a user account is singled out at login. I used a Group Policy Machine Startup Script entry to map two drive letters that I wanted as global, or available-to-all, drive maps. It does work and users can access the mapped drive after logging in, even though the drive is mapped by NT AUTHORITY\SYSTEM, or such. In a way, it can make the drive mappings more secure, as the users can only use the mapped drive, not change or remove it. The only way, that I discovered after much balding of my own head , to alter the SYSTEM-owned maps is with a registry "hack." A user belonging to the Administrators group has to edit the Registry and manually delete, or alter, the mappings, then reboot the PC to apply the changes. Unfortunately, I can't recall right now where the mappings were stored, but it wouldn't be hard to find by simply searching the Registry for the share path used by the mapping. ...My $0.02... -
finding working directory for a program
1of10 replied to ahha's topic in AutoIt General Help and Support
@ahha: I believe I've got what you were originally hoping to find... Someone mentioned something about programs registering their location with Windows, so the path doesn't have to be specified in the Run dialog... I can't remember who, and it doesn't seem to be in the topic review while I'm posting here, but that's beside the point. Point is, you might be surprised at how many programs ARE registered with Windows... Anyway, here's my half-second AutoIt script to report the full executable path of my installed version of Acrobat Reader. Please be aware of the much discussed (so far) issue about the name of the actual EXE file -- acrobat.exe vs. acrord32.exe. Your mileage may vary with this script, but you can't go wrong if you try reading both acrobat.exe and acrord32.exe, then evaluating @error after each RegRead()... MsgBox(0x0, "Acrobat AppPath", RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe", "")) The Registry location is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppPaths Under the above-listed key, you'll find numerous other keys, their names matching those of the main EXE file of many programs installed on any Windows -- maybe just 2K and XP -- computer. Inside the EXE-named keys, you'll find, usually, two values: (Default) and Path. Path sometimes isn't there... Hope this helps! -
Trojan Horse In AutoIT3?
1of10 replied to NinerSevenTango's topic in AutoIt General Help and Support
AVG isn't the only anti-virus package that's picking up AutoIt v3 compiled scripts as infected. I use AntiVir, and it's recently -- over the past couple of months -- started picking up more and more AutoIt v3 compiled scripts as all sorts of infectious malware on my system. The big "WTF!?" on the subject was when the on-access scanner picked up a compiled script I had completed no more than a week previous... From the sound of things, I should use the built-in feature to package the quarantined files and send them off to Avira -- the company -- for analysis, so they can correct their databases. (FYI, I watch all aspects of my system like a hawk. It's a rare treat when a REAL piece of malware gets past my scrutiny! Is it still hiddensoft.com for the compiled.html information that references anti-virus software authors? Or is that now via autoitscript.com? (Has the compiler front-end/wrapper been updated to add the correct URL to the compiled scripts resources information, if it has changed?) URLs for the interested: [ http://www.free-av.com/ | http://www.antivir.de/ ] -
Just wanted to add my two bits worth of WeawyWoadedWeb spam on this topic... Boy, am I ever a statistic... I bet this would explain the odd behaviour I've been considering with regards to my Anti-Virus scanner, AntiVir. In the configuration for AntiVir, I've specified several process names that I wanted it to IGNORE for on-access scanning. I've been in the over-used habit of turning off on-access scanning way too often, though. Every time I looked at a process list on my Windows 2000 system, I was never satisfied that AntiVir truely was ignoring the processes I specified. It must be due to this internal process name length limit. There's never been a problem with running programs that have a file name longer than what TaskMgr.exe, or any other task management program -- ProcExp, from SysInternals, for example -- could display as a process name. But now, I'll bet, if I re-configure the AntiVir on-access scanner to ignore processes exactly as they appear, character-for-character, in a process list, it just might ignore them for the first time, ever! I'll have to remember never to develop a program that has a name longer than 15 characters, which relies heaviliy upon it's own process name. And, to back up the other side of the data, Windows XP process lists, I have seen the same processes I run on my Windows 2000 showing their full file name, including extension, in a Windows XP process list. No "640K ought to be enough for anyone" limitation there...
-
Question on RC.EXE and Resource Hacker.
1of10 replied to Giuseppe's topic in AutoIt General Help and Support
I'm having much the same issue with my setup... What's driving me bonkers is I can't, for the life of me, figure out why it doesn't work now, when it worked perfectly fine the last time I wrote an AutoIt3 program! First, some background: I've been using a customized CompileAU3.ini file since, I think, AutoIt v3.1.1.76. That's about the time I discovered I could specify where my ResHacker.exe and RC.EXE/RCDLL.DLL files were located, thus avoiding duplicate copies -- even the temporary ones extracted from CompileAU3 itself. The last time I wrote a program using SciTe4Au3 and all the usual suspects... erm, Tools , Beta development was at v3.1.1.117. I recently re-installed practically everything: AutoIt v3.1.1 (Production), AutoIt v3.1.1.131 (Latest Beta) and SciTe4Au3 plus the update to bring the tools up to v3.1.1.131 support. I noticed that my customized CompileAU3.ini was copied/renamed to AutoIt3Wrapper.ini, and placed in the new directory. I spent a moment checking out the new compiler directives, so I could make sure my wrapper custom INI was up-to-date -- I like to have ALL the options listed as a quick reference, rather than opening the Directives.au3 every time. The aneurysm began when I consistently received a compile-time error stating my program would not have it's resources information updated. My first thought was, "Rats, did I delete MASM32 when I was ``cleaning shop'' of old, rarely used programming resources?" But, I still have a complete MASM32 directory tree, including RC.EXE and RCDLL.DLL. My second thought was, "I'll bet it's an old path that wasn't corrected when things got swapped around on network shares/drive mappings..." But, that was shot down; I have MASM32 on a local hard drive. The path had not been changed since I first discovered I could tell the compiler front-end -- CompileAU3 -- where to find my own copy of the Resource Compiler. My next thought was along the lines of some obscure version conflict. So, I removed the path for RC.EXE from the AutoIt3Wrapper.ini -- I left the option, just made it equal nothing, like 5/8ths of the other options in there. I tried compiling my program again, this time relying on the included copy of RC.EXE. I was stumpted when I didn't see ANY change in the contents of my temporary files directory. I didn't see RC.EXE/RCDLL.DLL briefly flash through, like with previous versions of the front-end/wrapper. I didn't see any "temp.rc" file, either! Odly enough, the progress dialogue shown during compilation took the expected amount of time to "create resource file." To my, almost, relief, I did see a file in the temporary files directory called rc.log. I had found that EXTREMELY useful when I was tinkering with specifying the location to my own RC.EXE way back when ... Upon opening the log file, I was stumped yet again! The error message, from RC.EXE, said, and I copy'n'paste, "RC : fatal error RC1110 : could not open temp.RC" I looked in all the directories I thought it could have ended up in, due to some bizzar path issue. Unfortunately, I found nothing. I even tried re-compiling AutoIt3Wrapper myself, adding trace and debug lines on several occasions... Painfully, that wouldn't compile, either. "Rant, rant, rant, ..." I did, however, learn that everything should be processing as it should. I just can't find any sign of temp.rc anywhere! And, since it gets deleted after use, tracking it down with a complete system, and network, search would probably leave me headless, little bits of brain matter all over the walls, ceiling and furniture! (Pleasant thought, yes, no? ) Have I gone into more than enough detail yet? Okay, let's get the final details over and done with before we all turn to fossils. OS = Windows 2000 CSD0400 / SP4 %TEMP% = C:\WINNT\TEMP\1of10 C:\WINNT\TEMP is an NTFS Junction/Hardlink to D:\TMP, making %TEMP% physically = D:\TMP\1of10 AutoIt3Wrapper trials: - With own RC.EXE path - Without own RC.EXE path - Without custom AutoIt3Wrapper.ini Output from last attempt to compile my program: ~ ~ ~ ~ CUT HERE ~ ~ ~ ~ >"D:\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.exe" /Beta /in "D:\PRJ\PROG\AUT\CleanPol.au3" /autoit3dir "D:\AutoIt3\BETA" > Running:COPY /V /Y C:\WINNT\REG.EXE "D:\PRJ\PROG\AUT" > Running:COPY /V /Y C:\WINNT\system32\PSAPI.DLL "D:\PRJ\PROG\AUT" >Running AU3Check (1.54.1.1) params: from:D:\AutoIt3\BETA +>AU3Check ended.rc:0 ! RC.Exe (1) : Error : Resources information will not be updated in target program! >Running:(3.1.1.131):\AutoIt3\BETA\aut2exe\aut2exe.exe +>Aut2exe.exe ended.rc:0 >Running:ERASE /F /Q "D:\PRJ\PROG\AUT\REG.EXE" >Running:ERASE /F /Q "D:\PRJ\PROG\AUT\PSAPI.DLL" + Updated the Source Version to:1.3.131.5 >Exit code: 0 Time: 54.277 ~ ~ ~ ~ CUT HERE ~ ~ ~ ~ I would like to note that initial attempts to compile did show that the wrapper was using RC.EXE from D:\masm32\bin, which was how I had it set since around AutoIt v3.1.1.76 - v3.1.1.80. And, for the final spam of the day -- at least, from me -- my original custom AutoIt3Wrapper.ini: ~ ~ ~ ~ CUT HERE ~ ~ ~ ~ # CompileAU3 Configuration File # # This file serves two purposes: # • Configure location of ResHacker.exe and RC.EXE. # • Default directives applied to all compiled scripts. # # Directives in here can be overridden by a script's own INI file, or by # #Compiler_* directives in a script itself; the latter always has final say. # # The Run_Before and Run_After directives can use these special variables: # %in%, %out%, %icon%, %fileversion%, %scriptfile%, %scriptdir% # # The #Compiler_Res_Field directive can use these special variables: # %AutoItVer%, %Date%, %LongDate%, %Time% # # Use the PlugIn_Funcs directive for a comma delimited list of function names # from plug-ins, to avoid AU3Check errors. [Config] ResHackerPath=Y:\ResHacker RCExePath=D:\masm32\bin [AutoIt] Aut2Exe= Icon=D:\AutoIt3\BETA\Aut2Exe\Icons\AutoIt_HighColor.ico OutFile= OutFileType=exe Allow_Decompile=1 PassPhrase= UseUpx=1 Compression=2 [Res] UpdateInformation=1 Comment= Description= LegalCopyright=©2006 One of Ten <OneOfTen@gmail.com> FileVersion=1.00.0000.0000 FileVersion_AutoIncrement=Y Field1Name= Field1Value= Field2Name= Field2Value= [Other] Run_AU3Check=Y AU3Check_Stop_OnWarning=Y AU3Check_Parameter= PlugIn_Funcs= Run_Before= Run_After= Run_cvsWrapper=Y ~ ~ ~ ~ CUT HERE ~ ~ ~ ~ I think my bulb is almost burned out ... I'm probably overlooking the simplest little detail on my hunt for the ludicrously over-sized bug. 1,000 praises to the Gee-uru, or is it Gu-eek-ru, who can figure out this clutter! PS: I forgot to mention the compiler directives section in my script itself... Here it is: ~ ~ ~ ~ CUT HERE ~ ~ ~ ~ #Compiler_Prompt=Y #Compiler_Aut2Exe=D:\AutoIt3\BETA\Aut2Exe\Aut2Exe.exe #Compiler_icon=D:\PRJ\VIS\ICO\MISC\GPEdit002.ico #Compiler_OutFile_Type=exe ;~ #Compiler_PassPhrase= #Compiler_Allow_Decompile=Y #Compiler_UseUpx=N #Compiler_Compression=0 #Compiler_Res_Comment=Purges System and User account(s) of configured Windows® security policies. Program will only run on Windows® NT™ variant. User running program MUST belong to Administrators group! #Compiler_Res_Description=Purge System/User Security Policies #Compiler_Res_FileVersion=1.3.131.5 #Compiler_Res_FileVersion_AutoIncrement=Y #Compiler_Res_LegalCopyright=©2006 One of Ten <OneOfTen@gmail.com> #Compiler_Res_Field=*AutoIt Version*|%AutoItVer% #Compiler_Res_Field=*Technical Detail*|http://www.autoitscript.com/autoit3/compiled.html #Compiler_Res_Field=*Build Timestamp*|%longdate% %time% #Compiler_Run_AU3Check=Y #Compiler_AU3Check_DAT=D:\AutoIt3\SciTE\Defs\Unstable\Au3Check\au3check.dat ;~ #Compiler_AU3Check_Parameters= #Compiler_AU3Check_Stop_OnWarning=1 #Compiler_Run_Before=COPY /V /Y C:\WINNT\REG.EXE "%scriptdir%"|COPY /V /Y C:\WINNT\system32\PSAPI.DLL "%scriptdir%" #Compiler_Run_After=ERASE /F /Q "%scriptdir%\REG.EXE"|ERASE /F /Q "%scriptdir%\PSAPI.DLL" #Compiler_Run_cvsWrapper=N ~ ~ ~ ~ CUT HERE ~ ~ ~ ~ -
Just wanted to point out the broken "Test Connection" feature... As written, it only tests "Client Web Site," due to the way the other hosts are tested to see if they are checked. The mistake is in the 5th Case in the GUIGetMsg loop, with the GUICtrlRead. Original: Case $msg = $Button1 For $p = 1 To UBound($pingitem) -1 If GUICtrlRead($pingitem[$p][1]) = 69 Then ; <== This doesn't work. ;MsgBox(0, "", $pingitem[$p][2]) _PingIt($pingitem[$p][2]) Correct: Case $msg = $Button1 For $p = 1 To UBound($pingitem) -1 If BitAND(GUICtrlRead($pingitem[$p][1]),$GUI_CHECKED) = $GUI_CHECKED Then ; <== Correct method of testing if checked. ;MsgBox(0, "", $pingitem[$p][2]) _PingIt($pingitem[$p][2]) There's a couple of things I would recommend that would make this program even better: Instead of duplicating the IPCONFIG /RELEASE & IPCONFIG /RENEW on the "Network Utility" menu, leave the first occurance, "Release/Renew," and replace the seperate menu items with a LAN Repair feature. Below, I've included the commands that are executed when you click the "Repair" button on a LAN Connection in Windows XP.I find it much easier to read the information placed in the $Edit1 GUICtrl if it's a fixed width font. Especially if you're just capturing command prompt text, which is aligned as fixed width to begin with.Probably the best suggestion would be a way to abort the current test. This would be most beneficial for the "Trace Route" function, which traces a route to a host over 30 with a timeout of five seconds. It took forever to complete when I traced to a host that refuses PING! The trace completed at about hop 15, but the command kept going for the remaining 15, waiting five seconds for each of the three pings made for each hop! (And yes, I know, I can force kill the process from a command prompt, or even from SciTe, but I wanted to experience the whole thing.) Here's the commands that are run behind the scenes when you click "Repair" on a LAN Connection in Windows XP: IPCONFIG /release IPCONFIG /renew ARP -d * NBTSTAT -R NBTSTAT -RR IPCONFIG /flushdns IPCONFIG /registerdns Oh, and it should be noted, just incase, that the subsequent commands are all dependant upon the first command completing successfully. I'm sure we've all seen that one error message about the DHCP server when clicking "Repair." That'll about do it for my two Rubles worth...
-
The CreateSemaphore function is available in ALL versions of Windows, since Windows 95, as documented by this MSDN article: http://msdn.microsoft.com/library/default....tesemaphore.asp Requirements: Client Requires Windows Vista, Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, or Windows 95.Server Requires Windows Server "Longhorn", Windows Server 2003, Windows 2000 Server, or Windows NT Server.Header Declared in Winbase.h; include Windows.h.Library Link to Kernel32.lib.DLL Requires Kernel32.dll.Unicode Implemented as CreateSemaphoreW (Unicode) and CreateSemaphoreA (ANSI). Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode.
-
Uhh... ... AWESOME!!! Script worked perfectly for me... Set it to use sounds by explicitly re-setting $MakeNoise to 1 after the If...Then...EndIf... Ran with AutoIt3 v3.1.1.103 -- didn't compile -- and it all worked great!
-
First thing I want to get out of the way is that I can't thank the coding Gurus, LazyCat and lookfar, enough for this remarkable AutoIt tool! I was putting off developing a lot of pointless GUIs simply because I didn't like the functionality of the existing GUI Builder, and didn't want to put in the effort to write the GUIs by hand. Yeah, I'm lazy... And now, for what I've discovered with the latest version of Koda, that comes packaged with SciTe4AutoIt3 v3.1.1.102... You may need to refer to one or more provided full screen capture(s), which will be uncompressed BMP, in order to maintain quality and clarity. As a result of the file sizes, the captures are stored on my own server -- it will be slow at times -- and linked here. Reference capture: KodaViaSciTe_LoadForm-110QH.bmp / 2.85MB / 1152x864x24bppCommand Line option "/Scite" passed to Koda when launched within SciTe. I gather this option tells Koda to paste into SciTe when selecting the Generate Code menu item, as opposed to just copying to the clipboard. When loading Koda this way, I can create a new form from Template -- LOVE the Gallery, BTW -- but I cannot File / Open an existing form or template. I get the error shown in the capture: "/Scite" is not a valid component name.Shown in the capture is everything mentioned above:AForm1, which is the default form opened when Koda opened.AForm2, which is the new form from template, DualListDlg.Error MsgBox, when I attempted to File / Open the AboutBox.kxf from the Templates directory.Reference capture: KodaViaCmd_NotDefaultStyle-110QH.bmp / 1.27MB / 861x517x24bppThis is a rather quirky issue with the style attributes. I've found that un-checking certain boxes causes other boxes to automatically un-check. I presume this is to avoid conflict of incompatible attributes when a prerequisite is no longer selected. I'm not sure if this is an "undocumented feature," but those same linked boxes do not automatically re-check when I re-check the box that initially turned the linked ones off. (I hope you followed that... I almost lost myself while typing it. )Another style attribute issue, or "undocumented feature," is related to generating the code. In the referenced capture, I have highlighted the WS_MINIMIZEBOX attribute in the Object Inspector. It took me a LONG time to figure out how to get that one to actually turn off, because, what I failed to notice each time I generated the code was that the styles position in the GuiCreate() is set to default (-1). I had to fiddle around until I found the right combination of attributes on and off that actually put something into that position -- the position, by the way, is highlighted in the code window. Maybe this is just my lack of understanding of the required links between attributes... I have also experienced the really fast click-and-accidentally-drag issue, mentioned about five pages, and several revisions, back in this thread.I've also had X,Y,W,H values change on me, without a click-drag, and without locking a control in place. Some of the controls seem to be permanently bound to the data, or contents, the control contains. In other words, a drop-down is a thin sliver horizontal line, because it has no content -- I was going to assign this later in my script, rather than the form itself. This, too, could be my lack of experience with GUI authoring tools... This true bug, which is also shown in the code window of KodaViaCmd_NotDefaultStyle-110QH.bmp, is the line that shows GUISetColor(0xFFFFFF). While testing the form shown in that capture, I had to comment-out or remove the GUISetColor() line, because it is not a valid AutoIt3 function. I don't know if it exists in the v3.1.1.0 release version, or if it was a briefly lived Beta function, but it does not exist in v3.1.1.103.Last, but not least, is a recommendation for the Templates Gallery view: larger samples of the forms. the current samples size is a little too small to make out what the form contains, at least on a screen resolution of 1152x864. Relevant details of my environment:AutoIt3 v3.1.1.0 and v3.1.1.103 (Beta) -- I usually develop in Beta.Koda v1.4.2.4 (WinPE FileVersion Tag) / v1.4.0 (Koda's own About Box)Windows 2000 Professional CSD0400 (more commonly known as Service Pack 4, via Windows Update)English language (en-CA/en)All related software installed under D:\AutoIt3 -- No spaces anywhere in any pathsD:\AutoIt3D:\AutoIt3\BETAD:\AutoIt3\SciTeD:\AutoIt3\SciTe\KodaAll of my project/work files, including my own Koda forms, are stored in a similar path-style:D:\PRJ\PROG\AUTD:\PRJ\PROG\AUT\KodaFormsOh, and if you need some help with any part of the development of Koda, be it Compiled HTML Help generation, additional coding assistance, pre-release-beta testing, etc., I'd be glad to help in any way I can. Looking forward to the next release, of Koda and AutoIt3...
-
I've just worked my way through this whole thread after downloading what I presume is the latest version. It's all the same link, right? Anyway, I used to have a really frustrating issue with version 1.6.2, where it would not download ANYTHING AT ALL! 1.6.3 is working perfectly for me! I did have to "correct" the Special ZIPs INI file, as I have one of the 99.99% typical paths -- C:\Program Files -- but didn't have any problem with spaces. However, the latter could be because I don't have AutoIt3 in C:\Program Files, only SciTe. AutoIt3 is installed to D:\AutoIt3 on my system, so I was putting Koda into D:\AutoIt3\Koda. I do have a couple of recommendations, though. For one, and this is something I noticed in 1.6.2 as well, the "AutoIt3 System Information" window fails to obtain version information for things I DO have installed. This is because you're referencing hard-coded file paths in the script. The better option would be to query the Registry for install paths. That way, it doesn't matter where 100% of Win-D'Ohs users choose to place files, you'll always have a valid location. My second recommendation is a very minor one: I think it would be better to make the Help / About window and the "AutoIt3 System Information" window AppModal, so they remain on top of the main window. I kept loosing the extra windows from Au3UpDate behind every other program I had open whenever I had to task switch. I had to move the main window to the side in order to close the system information, and again in another direction to locate the close button for the About window. Oh, and the edit window for Special ZIPs... I don't know where it went the first time I lost it, but I made sure to finish the edit and close that window before task switching again... I've attached a Window capture of the System Information, so you can see how it has failed to obtain some versions: SciTe, SciTeConfig, Tidy, Au3Record, FuncPopUp, CompileAu3, etc... They ARE installed, but not in the @ProgramFiles & '\AutoIt3\SciTe' folder that is default if no custom installations are done. Au3UpDate163_QUARTERHORSE.bmp And, I do have ResHacker on my system, but it's not "installed" in any generic folder. It resides in a folder I have designated as a network shared "sbin" folder (D:\110LANM\SBIN\ResHacker\ResHacker.exe would be my official path, which is also specified in the CompileAu3.ini file -- People, you need to read the source and figure out that you have to create this file yourself; upx.exe to decompress CompileAu3, then EXE2AU3 it.) Well, I think that should just about do it for my $2,000.00 worth... One of Ten Secondary Adjunct of Unimatrix Z03
-
It's not so bad... In fact, even though it didn't work for me how it seems to have worked for you, it's still a valuable reference on how to convert to Hexadecimal values. Incase you're curious about the results I got, here's the breakdown: Copied Func and Example directly from Topic into new AU3 Script; clean-up after Copy converted space-indents to tab-indents.Commented out Run(), because I was only interested in the results, not the automatic launching of any program.Commented out final assignment of $s_NUrl, because it's unnecessary the same result can be acheived by moving the right side of the assignment to the Return line, then enclosing the assignment inside brackets so that it's evaluated before the Return.Save, then Go!Result: http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%61/%66%69%72%65%66%6F%78?... Theory: from CMD.EXE, did «START http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%61/%66%69%72%65%66%6F%78?...Since Mozilla Firefox is registered in my system as the default browser, Firefox attempted to load the URL.Result: «404: No Such Domain (Privoxy v3.0.3)» It was attempting to load from «%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%61» Possibly the results I got could be different if I wasn't browsing through a proxy, but at least I now have an example of how to convert to Hexadecimal values. And that will come in very useful in the future. Possible improvements I can think of right now would be: Make the Func more intelligent, so that it only converts characters that would need to be converted, and only characters that appear after the page being requested. (I know the latter would be somewhat difficult considering some websites that pass parameters in the format of a path, such as server.com/path/file.ext/some+var/opt_05=y)I noticed that, when I changed the host part back to unencoded text and left everything after the "/" still encoded, the page loaded as expected. I would recommend instead of specifying some fixed value for the browser in the Run() function, use «@ComSpec & " /C " & Chr(34) & "START " & $Coded & Chr(34)», or somehow call the Windows® ShellExecute to launch the URL. Either one would allow the Script to load the URL in the system's default browser, no matter what it may be.Here's my slightly modified copy of the Func: CODEFunc _EncodeUrl($s_Url, $s_PreFix = 'http://') Local $s_NUrl = '' $s_Url = StringSplit($s_Url, '') For $i = 1 To $s_Url[0] If $s_Url[$i] = '/' OR $s_Url[$i] = '?' OR $s_Url[$i] = '=' Then $s_NUrl = $s_NUrl & $s_Url[$i] ContinueLoop EndIf $s_NUrl = $s_NUrl & '%' & Hex(Asc($s_Url[$i]), 2) Next ;$s_NUrl = $s_PreFix & $s_NUrl ;Return $s_NUrl Return ($s_PreFix & $s_NUrl) EndFunc ;http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%61/%66%69%72%65%66%6F%78?%63%6C%69%65%6E%74=%66%69%72%65%66%6F%78%2D%61%26%72%6C%73=%6F%72%67%2E%6D%6F%7A%69%6C%6C%61%3A%65%6E%2D%43%41%3A%6F%66%66%69%63%69%61%6C ;http://www.google.ca/%66%69%72%65%66%6F%78?%63%6C%69%65%6E%74=%66%69%72%65%66%6F%78%2D%61%26%72%6C%73=%6F%72%67%2E%6D%6F%7A%69%6C%6C%61%3A%65%6E%2D%43%41%3A%6F%66%66%69%63%69%61%6C $Coded = _EnCodeUrl('www.google.ca/firefox?client=firefox-a&rls=org.mozilla:en-CA:official') ConsoleWrite($Coded & @CRLF) ;Run('C:\Program Files\Internet Explorer\iexplore.exe ' & $Coded)