nitro322

Thanks, water. That was it. I was actually thinking I might have something on top of that button that was interfering with the click, but couldn't spot the issue. Thanks again. Much appreciated.

I have an odd problem with a simple GUI I've created. It has two buttons - one OK and one Cancel, with OK set as the default button. Everything works except for clicking the OK button. Specifically: If I press enter anywhere in the form, OK fires. If I tab to OK and hit space, OK fires. If I tab to Cancel or close the window, Cancel fires. If I click Cancel, Cancel fires. If I click OK... nothing happens. Can't for the life of me figure out what's causing that. Any idea what I'm overlooking? Here's the form: GUICreate("Set Password", 195, 110) ; Draw elements GUICtrlCreateLabel("Set new password:", 5, 5, 90, 20) local $pass1in = GUICtrlCreateInput('', 100, 5, 90, 20, $ES_PASSWORD ) GUICtrlCreateLabel("Confirm password:", 5, 25, 90, 90) local $pass2in = GUICtrlCreateInput('', 100, 25, 90, 20, $ES_PASSWORD ) local $ok = GUICtrlCreateButton("&OK", 10, 85, 80, 20) local $cancel = GUICtrlCreateButton("&Cancel", 105, 85, 80, 20) ; Set properties GUICtrlSetState($ok, $GUI_DEFBUTTON) ; Display GUI and wait for action GUISetState(@SW_SHOW) while 1 $action = GUIGetMsg() select ; Begin processing options case $action == $ok ; Validate input msgbox(0, 'test', 'OK button pressed 1') GUIDelete() exitloop ; Exit if Cancel clicked or window closed case $action == $GUI_EVENT_CLOSE OR $action == $cancel GUIDelete() return('') endselect sleep(10) wendWould appreciate any assistance, because I'm stumped. Thanks.

I know this is an old topic, but I just stumbled across it looking for info about this topic, and I figure this may be of use to others that find it in a search. The function posted by Varian works great (and thank you very much), but it's incomplete. The third argument, which appears to be used to determine whether an item is pinned or unpinned, isn't actually implemented. The result is that the function acts like a toggle - if the item is not pinned, it will be added; if the item is pinned, it will be removed. If you want to specifically remove something and it's not currently there, you'll just end up adding it instead. I updated the function to properly support this. Now, if $pin = true (default), the item will always only be added, and likewise $pin = false will cause the item to always only be removed. I had also converted the function to my personal style in the process, and I know it's not the preferred style for the forum, so apologies to anyone inconvenienced by that. Hope this helps. func pinitem($file, $loc = 'task', $pin = true) if @OSBuild < 7600 then return seterror(1) ; Windows 7 only if not fileexists($file) then return seterror(2) local $sFolder = stringregexpreplace($file, "(^.*\\)(.*)", "$1") local $sFile = stringregexpreplace($file, "^.*\\", '') $ObjShell = objcreate("Shell.Application") $objFolder = $ObjShell.Namespace($sFolder) $objFolderItem = $objFolder.ParseName($sFile) For $Val in $objFolderItem.Verbs() if $pin then if $loc = 'task' and $val() = "Pin to Tas&kBar" then $Val.DoIt() return elseif $loc = 'start' and $val() = "Pin to Start Men&u" then $Val.DoIt() return endif else if $loc = 'task' and $val() = "Unpin from Tas&kBar" then $Val.DoIt() return elseif $loc = 'start' and $val() = "Unpin from Start Men&u" then $Val.DoIt() return endif endif next endfunc

Sorry for the delayed response, but I just saw those last two replies. I haven't been doing much Windows development lately, so I haven't really been following these boards. As for your posts: Angel - sounds pretty cool. I'll definitely need to check it out. I have some similar functionality defined in my .vimrc file (eg., run the file with F5, compile with F6, etc.), but your plugin sounds much more complete. I'll give it a shot next time I'm working with AutoIt and let you know what I think (if you're still interested at that point :-) ). gamingmouse - I definitely like your ideas, and I've briefly looked into omnicompletion before, but it didn't really click with me. To be honest, I'm not very familiar with how syntax files are "supposed" to be written. I took over maintenance of an existing syntax script after the original author disappeared, and despite adding quite a bit to it over the years I'm still largely using his original structure. When I do my next update I'll look into this again, see if I have any better luck the second time around.

FYI, I just attached v1.9 to the parent post, which is updated for version 3.3.0.0.

I have to check out supertab. Thanks for the tip.

Added update for AutoIt 3.2.12.1.

FYI, I just uploaded version 1.7 of the script, which has been updated for AutoIt 3.2.10.0.

Thanks for the suggestion, MsCreatoR. I had actually thought about using a regex function shortly after posting, and came up with this: $temp = stringregexp($line, "\S+", 3) Pretty close to your suggestion, though a slightly different approach. Thanks for taking the time to reply. I do appreciate it.

I want to split a string into chunks using whitespace. StringSplit() seems like the obvious choice, but it doesn't behave as expected. Eg: $test = '12 34 56 78 90' $test2 = stringsplit($test, ' ') _arraydisplay($test2, 'test') I would expect to get back: [0]|5 [1]|12 [2]|34 [3]|56 [4]|78 [5]|90 Instead, I get this back: [0]|11 [1]|12 [2]|34 [3]| [4]|56 [5]| [6]| [7]|78 [8]| [9]| [10]| [11]|90 I can take a guess at why it's going this, but I don't think this should be considered "desired" output. I'm choosing to split on spaces; why would I want any of the elements to be nothing but a space? Any suggestions on how I can make this work right? Are there any other split/explode functions that will do what I need? Thanks.

FYI, I just uploaded version 1.6 of the script, which has been updated for AutoIt 3.2.4.9. As noted previously, support for AutoIt is now included in the official Vim release, beginning with 7.1. Keep in mind, though, that only version 1.5 of the script is included; to add support for the latest AutoIt syntax, download the newest version from http://www.vim.org/scripts/script.php?script_id=1239 (or from the first post of this thread) and replace the copy of autoit.vim that was installed with Vim.

I'm troubleshooting a file search function (specifically, a slightly modified version of this one) under Windows 98. The function seems to lock up the AutoIt executable whenever it's called. After a bit of testing it appears that the dir command works fine under 9x, and nothing else in that function appears to be NT-specific. I searched the help file, and it doesn't specify that StdoutRead() requires an NT-based kernel, but I can't find anything else that may cause the problem. So, does StdoutRead() require @OSType == WIN32_NT, or should it work under Windows 9x as well? If it should work under either, does anyone have any other suggestions why this function won't work? Thanks.

FYI, I just uploaded version 1.5 of the script, which has been updated for AutoIt 3.2.2.0. I've also exchanges a few e-mails with the Vim author, and this version of the syntax file should be included with the next official release of Vim. w00t. I still plan on updating the file as needed, though, so check http://www.vim.org/scripts/script.php?script_id=1239 for updates.

So... no suggestions?

This is very quick and dirty, but it works on my laptop: dim $profile $current = regread('HKLM\SYSTEM\ControlSet001\Control\IDConfigDB', 'CurrentConfig') if @error then msgbox(0, 'Test', 'failed') for $i = 1 to 10 $key = regenumkey('HKLM\SYSTEM\ControlSet001\Control\IDConfigDB\Hardware Profiles\', $i) if @error then continueloop if stringright($key, 1) == $current then $profile = regread('HKLM\SYSTEM\ControlSet001\Control\IDConfigDB\Hardware Profiles\' & $key, 'FriendlyName') msgbox(0, 'Test', 'Current Profile: ' & $profile) endif ;if @error then ;msgbox(0, 'Test', 'failed') next if not $profile then msgbox(0, 'Test', 'failed') It's pulling the value from the registry rather than the GUI. If you have more than 9 profiles, it won't work (thought the code could be modified to support that). Also, if you prefer to go through the GUI (which may be more reliable; I've never messed with hardware profiles before), you can open the Hardware Profiles dialog much more easily than you're doing above: run('rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl,,2') winwaitactive('System Properties') send('!p')