Mobile

<br />
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]<br />
        [global::System.ComponentModel.DataObjectMethodAttribute(global::System.ComponentModel.DataObjectMethodType.Fill, true)]<br />
        public virtual int Fill(AppDatabase1DataSet.testDataTable dataTable) {<br />
            this.Adapter.SelectCommand = this.CommandCollection[0];<br />
            if ((this.ClearBeforeFill == true)) {<br />
                dataTable.Clear();<br />
            }<br />
            int returnValue = this.Adapter.Fill(dataTable); // here the error<br />
            return returnValue;<br />
        }

1. SHCMBM_OVERRIDEKEY – I’ve used SendMessage(… SHCMBM_OVERRIDEKEY, VK_TTALK, …), as described here, to request that TALK button events be passed to me as WM_HOTKEY events.
   
   
   
   1. What worked: The built-in phone app launch was bypassed, so that’s good. And I did get WM_HOTKEY events for the button presses.
      
   2. What didn’t work: I got WM_KEYUP events telling me the user had released the TALK button, but they came way too soon, while I was still holding the button down.
      
   
   
2. UnregisterFunc1(), UnregisterHotKey(), RegisterHotKey() – There’s a lot of discussion (here and here, e.g.) about this option. I’ve tried it and had problems similar to the ones I describe above.
   
   
   
   1. What worked: I avoided the phone app launch, and I did get WM_HOTKEY events for presses (and releases, too, if I recall correctly).
      
   2. What didn’t work: But the release events came too soon, as they did elsewhere. Also, after I exited my application, the connection between the TALK button and the built-in phone application was still broken. There’s probably a way I could restore that, but since the release events were no good, I doubt I’ll pursue this option.
      
   
   
3. SHSetAppKeyWndAssoc() – I had high hopes for this one (described here), and it did let me grab keys other than VK_TTALK, but I wasn’t able to get VK_TTALK with it at all, and even with the keys I could get, I didn’t see any notice of key release events.
   
4. SetWindowsHookEx() – I found some documentation of how to add a hook for low-level keyboard events (see here, e.g.) and tried it. I got the events, but they behaved just the same as SHCMBM_OVERRIDEKEY above. That is, I was told the button was pressed, and then told a too-short time later that it was released (when I was still holding it down).
   
5. GetAsyncKeyState() – I even considered polling methods. I thought maybe I could start with one of the above methods, which at least notified me on the button press, and then poll to watch for the user to subsequently release the button. GetAsyncKeyState() is supposed to tell you whether a given button is down or up. And it did correctly report the button as being pressed when the event came telling me that it was pressed. But when a subsequent event came telling me (incorrectly) that it had been released, GetAsyncKeyState() ALSO told me the button was not pressed. So that’s no help.