Syrin

Yeah... a google for "IE9 COM" doesn't help so much. Oh well, the deadline is upon me, so I just have to leave it running using MouseClick instead. Thanks for the help.

Nope, I only just downloaded it a couple days ago. Should be release version.

I have, it was one of the first things I tried. No dice.

Ugh. I can do it manually - I have a version set up that just uses the MouseClick() AutoIt function... I just prefer elegant solutions to hamfisted hackeries. Oh well. If it works, it works, I guess.

I'm just asking here in case somebody has experience with the IE9 COM. For some reason, I can't do certain things (such as the .click() or .focus() methods on any elements), and I couldn't find any information about what might be stopping me from doing so. Here's a quick example that shows what I mean. #include <IE.au3> $oIE = _IECreate("http://www.google.ca/") _IELoadWait($oIE) local $t = _IEGetObjByName($oIE,"q") ;This works, properties seem to work fine. $t.value = "Test 1" ;This also works, so it isn't a problem with methods. $t.insertAdjacentText("afterBegin","Test 2") $t = _IEGetObjByName($oIE,"btnG") ;This does nothing. $t.click() I've also tried it without IE.au3 functions, just using normal COM syntax according to documentation on the MSDN library, no luck. I've also tried it with LuaCOM, so I don't think it's a problem with AutoIT, but with IE9.

But that's gross, I don't want the key-capturing functionality of HotKeySet() :/ This is the key I needed, thanks. Completely forgot about it, but that would cause precisely the problems I'm having.

Because the accelerator functionality isn't sufficient to do what I desire. I only want the hotkey to work while the listview has focus, and one of the items is selected. And the code that I have now does that - it's just weird because I had to do some unintuitive things to fix what was wrong, so I'm curious if it's a problem with my machine, or if what "should be correct" is not, in fact, what is correct (i.e, the given documentation about the structure of the $ilParam DllStruct for an $LVN_KEYDOWN event is, in fact, completely 100% wrong) Edit: Ah! There is, apparently, documentation, and it's on the microsoft website! I guess I was just googling the wrong things. According to the microsoft website, the StructureConstants.au3 definition is correct (except maybe that align 1 thing? I have no idea what that does), so I guess my laptop is just fucked, I dunno. Can anybody at least run that example code and corroborate that pressing the "Delete" key while one of the items is selected will place the selection's number into the edit box? Because then at least it won't just be me.

Well, that solves it - but my curiosity remains. Why would something as seemingly innocuous as the order of these two operations which (I thought) ought to be independent have an effect like this?

I'm going about setting up a "delete" hotkey for a listview in my GUI, and so I decide to search it up. I see a bunch of examples of the form DllStructCreate($tagNMLVKEYDOWN,$ilParam), and I was confused as I had never seen the global $tagNMLVKEYDOWN before. So, I tracked it down to StructureConstants.au3, examined it, accepted it, and went back to debugging what the hell was going wrong. See, in the WM_NOTIFY function I have set up, it wasn't detecting DllStructGetData($thestruct,"VKey") as the Delete key - in fact, it wasn't doing anything. So I output it to a quickly crafted text box, and it seems like no matter what, the value of "VKey" is 0 - except when I press two keys at the same time, then it's 65535. So, okay, weird. What should be the code of the pressed key is in fact either 0x0 or 0xFFFF. And then I tried the "Flag" portion of the DllStruct instead. In that case, it was jumping all over the place - but it never seemed to correspond to the key pressed either. So, since I have no prior experience with Dlls or any of this stuff, I had to go look up the functions, and find out that the "align" keyword in the StructureConstants.au3 definition of tagNMLVKEYDOWN might be out of place, who knows. So I give it a shot, and take it out, and use this: DllStructCreate("hwnd hWndFrom;uint_ptr IDFrom;INT Code;word VKey;uint Flags",$ilParam) VKey is still wrong! Augh. So, I decide to try Flags instead and - for some reason - it works. DllStructGetData(DllStructCreate("hwnd hWndFrom;uint_ptr IDFrom;INT Code;word VKey;uint Flags",$ilParam),"Flags") returns what SHOULD be held in the "VKey" spot. Is the structureconstants.au3 definition just, wrong? or something? Or is the pointer being passed to WM_NOTIFY messed up on my machine? Actually, on that note, is there some documentation somewhere on the expected values stored at the location pointed to by $ilParam (and, of equal importance, what the values mean/indicate)? Some quick example code to show what I mean #include <GUIListView.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> Opt("GUIOnEventMode",1) $main = GUICreate("Test",500,300,-1,-1,$WS_TILEDWINDOW) GUISetOnEvent($GUI_EVENT_CLOSE,"Terminate") $list = GUICtrlCreateListView(" ",-1,-1,100,280,BitOR($LVS_SHOWSELALWAYS,$LVS_NOCOLUMNHEADER,$LVS_SINGLESEL)) GUICtrlSetResizing(-1,$GUI_DOCKWIDTH) For $i = 1 to 5 GUICtrlCreateListViewItem("Item " & $i,$list) Next _GUICtrlListView_SetColumnWidth(GUICtrlGetHandle($list),0,95) $edit = GUICtrlCreateEdit("",100,-1,400,280) GUICtrlSetResizing(-1,BitOR($GUI_DOCKRIGHT,$GUI_DOCKLEFT)) GUISetState(@SW_SHOW) GUIRegisterMsg($WM_NOTIFY,"WM_NOTIFY") While 1 Sleep(1000) WEnd Func WM_NOTIFY($hWnd, $iMsg, $iwParam, $ilParam) Local $tNMHDR, $tInfo,$hWndListView $hWndListView = GUICtrlGetHandle($list) $tNMHDR = DllStructCreate($tagNMHDR, $ilParam) If (HWnd(DllStructGetData($tNMHDR, "hWndFrom")) = $hWndListView) And (DllStructGetData($tNMHDR, "Code") = $LVN_KEYDOWN) Then #cs The original version (which DOESN'T work) is: $tInfo = DllStructCreate($tagNMLVKEYDOWN, $ilParam) If BitAND (DllStructGetData ($tInfo, "VKey"), 0xFFFF) = 46 Then #ce $tInfo = DllStructCreate("hwnd hWndFrom;uint_ptr IDFrom;INT Code;word VKey;uint Flags", $ilParam) If BitAND (DllStructGetData ($tInfo, "Flags"), 0xFFFF) = 46 Then GUICtrlSetData($edit,_GUICtrlListView_GetSelectedIndices($hWndListView)+1) EndIf EndFunc Func Terminate() Exit 0 EndFunc

In the course of making myself an AutoIt program, I've come across this phenomenon, and I have no idea why it happens. I'm trying to make an "options" window, with standard options window behaviour. However, when it closes, the main window immediately loses focus. The only remedy is using WinActivate($main), but sometimes there's a slight flicker, and I find it to be rather unseemly. Why does this happen, and is there any prettier way of going about this? #include <GUIConstantsEx.au3> #include <EditConstants.au3> #include <WindowsConstants.au3> Global $main,$toolsmenu,$options CreateMainGUI() CreateOptionsGUI() While 1 Sleep(1000) WEnd Func CreateMainGUI() Opt("GUIOnEventMode",1) $main = GUICreate("Example Window",500,300,-1,-1,$WS_TILEDWINDOW) GUISetOnEvent($GUI_EVENT_CLOSE, "Terminate") $toolsmenu = GUICtrlCreateMenu("Tools") GUICtrlCreateMenuItem("Options",$toolsmenu) GUICtrlSetOnEvent(-1,"OpenOptions") GUISetState(@SW_SHOW) EndFunc Func CreateOptionsGUI() $options = GUICreate("Options",250,200,-1,-1,BitOR($WS_CAPTION,$WS_SYSMENU),-1,$main) GUISetOnEvent($GUI_EVENT_CLOSE, "CloseOptions") EndFunc Func OpenOptions() GUISetState(@SW_SHOW, $options) GUISetState(@SW_DISABLE, $main) EndFunc Func CloseOptions() GUISetState(@SW_HIDE, $options) GUISetState(@SW_ENABLE, $main) ;WinActivate($main); <---when this is commented out (like it is currently), ;the window loses focus once the options window closes. EndFunc Func Terminate() Exit 0 EndFunc