Имитировать щелчок мышью в MSPaint

Как и было обещано, я вчера сам протестировал - если честно, мой курсор просто двигался, но не в окне и без какого-либо влияния - при отладке я увидел, что var hwndMain = FindWindow("mspaint ", null); было значением 0. Я думал, что это должно быть проблемой, поэтому я взглянул на другую тему stackoverflow, из которой вы получили свой код. Я понял, что решение использует другое имя окна, которое они искали в FindWindow(), поэтому я попытался.

var hwndMain = FindWindow("MSPaintApp", null);

После изменения вызова метода это сработало для меня - хотя - после перемещения MsPaint туда курсор все еще оставался в исходной открытой позиции - вы можете подумать об этом и, возможно, спросить окно о его позиции. Возможно, имя изменилось с Win7/8/10?

Изменить:

В Windows 10 название Paint, кажется, изменилось — так что я думаю, у вас все еще есть проблемы с получением правильного дескриптора окна — это было доказано Хансом Пассантом, который хорошо объяснил, в чем проблема с обработчиком (ссылка ниже). Один из способов решить эту проблему — получить обработчик из самого процесса, а не из FindWindow().

Я предлагаю вам изменить OpenPaint() следующим образом:

 private IntPtr OpenPaint()
 {
    Process process = new Process();
    process.StartInfo.FileName = "mspaint.exe";
    process.StartInfo.WindowStyle = ProcessWindowStyle.Maximized;
    process.Start();
    // As suggested by Thread Owner Thread.Sleep so we get no probs with the handle not set yet
    //Thread.Sleep(500); - bad as suggested by @Hans Passant in his post below, 
    // a much better approach would be WaitForInputIdle() as he describes it in his post.         
    process.WaitForInputIdle();
    return process.MainWindowHandle;
 }

Ссылка на Hans Passant decription для объяснения, почему Thread.Sleep() просто плохая идея.

Далее последовал звонок:

IntPtr hwndMain = OpenPaint(); // Method that opens MSPaint

Таким образом, вы должны получить правильный дескриптор окна, и ваш код должен работать, независимо от того, как Microsoft назвала его в win10.

IntPtr hwndMain = FindWindow("mspaint", null);

Это не достаточно хорошо. Распространенная ошибка в коде pinvoke: программисты на C#, как правило, слишком сильно полагаются на исключение, чтобы спрыгнуть с экрана и дать им пощечину, чтобы сказать им, что что-то пошло не так. .NET Framework делает это необычайно хорошо. Но это не работает так же, когда вы используете API, основанный на языке C, например winapi. C — язык-динозавр, и он вообще не поддерживал исключения. Это все еще не так. Вы получите исключение только в случае сбоя подключения pinvoke, обычно из-за неправильного объявления [DllImport] или отсутствующей DLL. Он не сообщает об успешном выполнении функции, но возвращает код возврата ошибки.

Это делает полностью вашей собственной работой обнаружение и сообщение о сбое. Просто обратитесь к документации MSDN, он всегда говорит вам, как функция winapi указывает на сбой. Не совсем совместимо, поэтому вам нужно посмотреть, в этом случае FindWindow возвращает null, когда окно не может быть найдено. Поэтому всегда кодируйте это так:

IntPtr hwndMain = FindWindow("mspaint", null);
if (hwndMain == IntPtr.Zero) throw new System.ComponentModel.Win32Exception();

Сделайте это и для всех остальных пинвоков. Теперь вы можете двигаться вперед, вы гарантированно получите исключение вместо того, чтобы работать с неверными данными. Что, как это часто бывает с плохими данными, не так уж и плохо. NULL на самом деле является допустимым дескриптором окна, ОС предположит, что вы имели в виду окно рабочего стола. Ой. Вы автоматизируете совершенно неправильный процесс.

Понимание того, почему FindWindow() терпит неудачу, требует некоторого понимания, это не очень интуитивно понятно, но хорошее сообщение об ошибках имеет решающее значение. Метод Process.Start() только гарантирует, что программа запущена, он никоим образом не ждет, пока процесс завершит свою инициализацию. И в этом случае он не ждет, пока создаст свое главное окно. Таким образом, вызов FindWindow() выполняется примерно на пару десятков миллисекунд раньше. Дополнительное недоумение, поскольку он отлично работает при отладке и пошаговом выполнении кода.

Возможно, вам знакома такая ошибка, это ошибка гонки потоков. Самый подлый вид программной ошибки. Печально известен тем, что не вызывает постоянных сбоев и его очень сложно отлаживать, поскольку гонки зависят от времени.

Надеюсь, вы понимаете, что предложенное решение в принятом ответе тоже недостаточно хорошо. Произвольное добавление Thread.Sleep(500) просто повышает вероятность того, что теперь вы будете ждать достаточно долго, прежде чем вызывать FindWindow(). Но откуда вы знаете, что 500 достаточно? Достаточно всегда?

Нет. Thread.Sleep() никогда не является правильным решением для ошибки гонки потоков. Если машина пользователя медленная или слишком сильно загружена из-за нехватки доступной неотображенной оперативной памяти, то пара миллисекунд превращается в секунды. Вам приходится иметь дело с наихудшим случаем, и это действительно наихудший случай, всего ~10 секунд — это обычно минимум, который вам нужно учитывать, когда машина начинает дергаться. Это становится очень непрактичным.

Надежная блокировка — настолько распространенная потребность, что ОС имеет для этого эвристику. Должен быть эвристическим, а не вызовом WaitOne() для объекта синхронизации, поскольку сам процесс вообще не взаимодействует. Как правило, вы можете предположить, что программа с графическим интерфейсом достаточно продвинулась, когда она начинает запрашивать уведомления. «Прокачка цикла сообщений» на просторечии Windows. Эта эвристика также попала в класс Process. Исправить:

private static void OpenPaint()
{
    Process.process = new Process();
    process.StartInfo.FileName = "mspaint.exe";
    process.StartInfo.WindowStyle = "ProcessWindowStyle.Maximized;
    process.Start();
    process.WaitForInputIdle();          // <=== NOTE: added
}

Было бы упущением, если бы я не указал, что вы должны использовать для этого встроенный API. Вызывается Автоматизация пользовательского интерфейса, умело обернутая в пространство имен System.Windows.Automation. Позаботится обо всех этих неприятных мелочах, таких как гонки потоков и превращение кодов ошибок в хорошие исключения. Наиболее подходящее руководство находится вероятно здесь.