Example #1
0
int keyboard()
{
 int ret=-1, go=1;
 char cmd1[]= "AT*EAID=1,1,\"Press the keys to simulate key presses on the computer\"\r";
 char cmd2[]= "AT+CMER=3,2,,,\r";
 char cmd3[]= "AT+CMER=0,0,,,\r";
 char buf[MAXLEN]="", *key;
 int status, keycnt;

 Display *dpy = XOpenDisplay (NULL);

 if(dpy==NULL) return -1;
 writeport(cmd1, strlen(cmd1));
 if(waitfor("OK", 1, TIMEOUT) != 1) go = 0;
 
 writeport(cmd2, strlen(cmd2));
 if(waitfor("OK", 1, TIMEOUT) != 1) go = 0;
 
 while(go)
 {
  buf[0]=0;
  ret = readport(buf, MAXLEN, TIMEOUT);
  if( (ret <= 0 && ret != -EINTR) || strncmp(buf, "ERROR", 5)==0 )
  {
   ret=-1;
   break;
  }
  if(strncmp(buf, "*EAII: ", 7)==0 || strncmp(buf, "*EAAI", 5)==0)
  {
   ret=1;
   break;
  }
  if(strncmp(buf, "+CKEV: ", 7)==0)
  {
   status=strchr(buf,',')[1]-'0';
   strchr(buf,',')[0]=0;

   key=buf+7;
   /* Correct for bug in T610 */
   if(key[0]==0x1B && key[1]==0x14)
   {
    key[0]='^';
    key[1]=0;
   }
   
   keycnt=0;
   while(keycnt < conf->keymapcnt && strcmp(conf->keymap[keycnt].name,key)) keycnt++;
   if(keycnt < conf->keymapcnt)
    key_down_up(dpy, conf->keymap[keycnt].val, status);
  }
 }
 
 writeport(cmd3, strlen(cmd3));
 if(waitfor("OK", 5, TIMEOUT) != 1) ret = -1;
 
 XCloseDisplay (dpy);
 return ret;
}
Example #2
0
HWND SetForegroundWindowEx(HWND aTargetWindow)
// Caller must have ensured that aTargetWindow is a valid window or NULL, since we
// don't call IsWindow() here.
{
  DWORD target_thread;
  HWND orig_foreground_wnd;
  HWND new_foreground_wnd;
  int is_attached_my_to_fore;
  int is_attached_fore_to_target;
  DWORD fore_thread;
  int i;
  int show_mode;

  if (!aTargetWindow)
    return NULL ;  // When called this way (as it is sometimes), do nothing.

  // v1.0.42.03: Calling IsWindowHung() once here rather than potentially more than once in AttemptSetForeground()
  // solves a crash that is not fully understood, nor is it easily reproduced (it occurs only in release mode,
  // not debug mode).  It's likely a bug in the API's IsHungAppWindow(), but that is far from confirmed.
  target_thread = GetWindowThreadProcessId(aTargetWindow, NULL) ;
  /*   if (target_thread != g_MainThreadID && IsWindowHung(aTargetWindow)) // Calls to IsWindowHung should probably be avoided if the window belongs to our thread.  Relies upon short-circuit boolean order. */
  /*     return NULL                             ; */

  orig_foreground_wnd = GetForegroundWindow() ;
  // AutoIt3: If there is not any foreground window, then input focus is on the TaskBar.
  // MY: It is definitely possible for GetForegroundWindow() to return NULL, even on XP.
  if (!orig_foreground_wnd)
    orig_foreground_wnd = FindWindow("Shell_TrayWnd", NULL) ;

  if (aTargetWindow == orig_foreground_wnd) // It's already the active window.
    return aTargetWindow                    ;

  if (IsIconic(aTargetWindow))
    show_mode = SW_RESTORE;
  else
    show_mode = SW_SHOW;
  ShowWindow(aTargetWindow, show_mode);



  // if (g_os.IsWin95() || (!g_os.IsWin9x() && !g_os.IsWin2000orLater())))  // Win95 or NT
  // Try a simple approach first for these two OS's, since they don't have
  // any restrictions on focus stealing:
#ifdef _DEBUG_WINACTIVATE
#define IF_ATTEMPT_SET_FORE if (new_foreground_wnd = AttemptSetForeground(aTargetWindow, orig_foreground_wnd, win_name))
#else
#define IF_ATTEMPT_SET_FORE if (new_foreground_wnd = AttemptSetForeground(aTargetWindow, orig_foreground_wnd))
#endif
  IF_ATTEMPT_SET_FORE
    return new_foreground_wnd               ;
  // Otherwise continue with the more drastic methods below.

  // MY: The AttachThreadInput method, when used by itself, seems to always
  // work the first time on my XP system, seemingly regardless of whether the
  // "allow focus steal" change has been made via SystemParametersInfo()
  // (but it seems a good idea to keep the SystemParametersInfo() in effect
  // in case Win2k or Win98 needs it, or in case it really does help in rare cases).
  // In many cases, this avoids the two SetForegroundWindow() attempts that
  // would otherwise be needed ; and those two attempts cause some windows
  // to flash in the taskbar, such as Metapad and Excel (less frequently) whenever
  // you quickly activate another window after activating it first (e.g. via hotkeys).
  // So for now, it seems best just to use this method by itself.  The
  // "two-alts" case never seems to fire on my system?  Maybe it will
  // on Win98 sometimes.
  // Note: In addition to the "taskbar button flashing" annoyance mentioned above
  // any SetForegroundWindow() attempt made prior to the one below will,
  // as a side-effect, sometimes trigger the need for the "two-alts" case
  // below.  So that's another reason to just keep it simple and do it this way
  // only.

#ifdef _DEBUG_WINACTIVATE
  char buf[1024]                          ;
#endif

  is_attached_my_to_fore = 0;
  is_attached_fore_to_target = 0;
  if (orig_foreground_wnd) // Might be NULL from above.
    {
      // Based on MSDN docs, these calls should always succeed due to the other
      // checks done above (e.g. that none of the HWND's are NULL):
      fore_thread = GetWindowThreadProcessId(orig_foreground_wnd, NULL) ;

      // MY: Normally, it's suggested that you only need to attach the thread of the
      // foreground window to our thread.  However, I've confirmed that doing all three
      // attaches below makes the attempt much more likely to succeed.  In fact, it
      // almost always succeeds whereas the one-attach method hardly ever succeeds the first
      // time (resulting in a flashing taskbar button due to having to invoke a second attempt)
      // when one window is quickly activated after another was just activated.
      // AutoIt3: Attach all our input threads, will cause SetForeground to work under 98/Me.
      // MSDN docs: The AttachThreadInput function fails if either of the specified threads
      // does not have a message queue (My: ok here, since any window's thread MUST have a
      // message queue).  [It] also fails if a journal record hook is installed.  ... Note
      // that key state, which can be ascertained by calls to the GetKeyState or
      // GetKeyboardState function, is reset after a call to AttachThreadInput.  You cannot
      // attach a thread to a thread in another desktop.  A thread cannot attach to itself.
      // Therefore, idAttachTo cannot equal idAttach.  Update: It appears that of the three,
      // this first call does not offer any additional benefit, at least on XP, so not
      // using it for now:
      //if (g_MainThreadID != target_thread) // Don't attempt the call otherwise.
      //	AttachThreadInput(g_MainThreadID, target_thread, TRUE) ;
      if (fore_thread && g_MainThreadID != fore_thread)
        is_attached_my_to_fore = AttachThreadInput(g_MainThreadID, fore_thread, TRUE) != 0 ;
      if (fore_thread && target_thread && fore_thread != target_thread) // IsWindowHung(aTargetWindow) was called earlier.
        is_attached_fore_to_target = AttachThreadInput(fore_thread, target_thread, TRUE) != 0 ;
    }

  // The log showed that it never seemed to need more than two tries.  But there's
  // not much harm in trying a few extra times.  The number of tries needed might
  // vary depending on how fast the CPU is:
  for (i = 0; i < 5; ++i)
    {
      IF_ATTEMPT_SET_FORE
        {
#ifdef _DEBUG_WINACTIVATE
          if (i > 0) // More than one attempt was needed.
            {
              snprintf(buf, sizeof(buf), "AttachThreadInput attempt #%d indicated success: %s"
                       , i + 1, win_name);
              FileAppend(LOGF, buf);
            }
#endif
          break;
        }
    }

  // I decided to avoid the quick minimize + restore method of activation.  It's
  // not that much more effective (if at all), and there are some significant
  // disadvantages:
  // - This call will often hang our thread if aTargetWindow is a hung window: ShowWindow(aTargetWindow, SW_MINIMIZE)
  // - Using SW_FORCEMINIMIZE instead of SW_MINIMIZE has at least one (and probably more)
  // side effect: When the window is restored, at least via SW_RESTORE, it is no longer
  // maximized even if it was before the minmize.  So don't use it.
  if (!new_foreground_wnd) // Not successful yet.
    {
      // Some apps may be intentionally blocking us by having called the API function
      // LockSetForegroundWindow(), for which MSDN says "The system automatically enables
      // calls to SetForegroundWindow if the user presses the ALT key or takes some action
      // that causes the system itself to change the foreground window (for example,
      // clicking a background window)."  Also, it's probably best to avoid doing
      // the 2-alts method except as a last resort, because I think it may mess up
      // the state of menus the user had displayed.  And of course if the foreground
      // app has special handling for alt-key events, it might get confused.
      // My original note: "The 2-alts case seems to mess up on rare occasions,
      // perhaps due to menu weirdness triggered by the alt key."
      // AutoIt3: OK, this is not funny - bring out the extreme measures (usually for 2000/XP).
      // Simulate two single ALT keystrokes.  UPDATE: This hardly ever succeeds.  Usually when
      // it fails, the foreground window is NULL (none).  I'm going to try an Win-tab instead,
      // which selects a task bar button.  This seems less invasive than doing an alt-tab
      // because not only doesn't it activate some other window first, it also doesn't appear
      // to change the Z-order, which is good because we don't want the alt-tab order
      // that the user sees to be affected by this.  UPDATE: Win-tab isn't doing it, so try
      // Alt-tab.  Alt-tab doesn't do it either.  The window itself (metapad.exe is the only
      // culprit window I've found so far) seems to resist being brought to the foreground,
      // but later, after the hotkey is released, it can be.  So perhaps this is being
      // caused by the fact that the user has keys held down (logically or physically?)
      // Releasing those keys with a key-up event might help, so try that sometime:
        key_down_up(VK_LMENU);
        key_down_up(VK_LMENU);
      //KeyEvent(KEYDOWN, VK_LWIN)                    ;
      //KeyEvent(KEYDOWN, VK_TAB)                     ;
      //KeyEvent(KEYUP, VK_TAB)                       ;
      //KeyEvent(KEYUP, VK_LWIN)                      ;
      //KeyEvent(KEYDOWN, VK_MENU)                    ;
      //KeyEvent(KEYDOWN, VK_TAB)                     ;
      //KeyEvent(KEYUP, VK_TAB)                       ;
      //KeyEvent(KEYUP, VK_MENU)                      ;
      // Also replacing "2-alts" with "alt-tab" below, for now:

#ifndef _DEBUG_WINACTIVATE
      new_foreground_wnd = AttemptSetForeground(aTargetWindow, orig_foreground_wnd) ;
#else // debug mode
      IF_ATTEMPT_SET_FORE
        FileAppend(LOGF, "2-alts ok: ", false)  ;
      else
        {