Добрый день, господа!
Возникла такая задача.
Имеется пользовательское приложение под Win32 (GUI), работающее, скажем, как калькулятор:
пользователь мышкой или клавиатурой вводит некоторые данные, она (программа) что-то
считает, выдаёт их пользователю. Всё через GUI.
Сейчас возникла необходимость обработки больших объёмов данных, а вводить их вручную как-
то не улыбается. Хотелось бы как-то автоматизировать и ускорить этот процесс.

Собственно, что необходимо? Использование функциональности данной программы, но в обход
клавиатурного или мышиного управления ей.

Первое, что приходит в голову, это сообщения. Т.е. можно написать некий автомат, который будет
брать данные из базы, посылать их программе, имитируя пользовательский ввод, потом забирать
полученное обратно.
Преимущества данного подхода? Простота реализации. Недостатки - медленная работа.
Вот, кстати, парочка вопросов по этому способу:
1) Что будет быстрее, послать сообщение (WM_SETTEXT, WM_GETTEXT, WM_COMMAND) из
другого приложения (процесса) или из того же процесса, но с другой нити (thread)? Точнее, если внедрить свою библиотеку в адресное пространство целевого процесса, то ускорится ли обмен данными с ним, посредством сообщений?
2) Куда лучше посылать сообщения: главному окну (или дочерним) посредством WM_COMMAND
или самим элементам управления (кнопке, окну редактирования)? Мне кажется, что первое.
3) Если с edit'ами всё более-менее понятно, то как быть с RichEdit'ом? Нужно вставить в строку текст, а потом "нажать" Enter, т.к. по этому событию висит обработчик.

Далее. Для ускорения обмена данными теоретически можно напрямую вызывать обработчики
событий, которые программа повесила на элементы управления. Т.е. размещаем данные куда нужно и
сразу вызываем функцию их обработки, минуя посылку WM_COMMAND. Это, на мой взгляд, ещё
быстрее, но нужно найти обработчики событий. Существуют ли какие-нибудь методы, приёмы для этого?
Понятно, что придётся вдумчиво вникать в дизассемблерный листинг, но есть ли информация, в какую сторону копать?
Скажем, если используются MFC, то можно ли найти нужные места, не зная самих классов и их
работы (MFC)?

И ещё один подход, на мой взгляд, самый лучший. Вызывать не обработчики событий, а сами
функции программы для обработки данных. Т.е. как обычно делается? При нажатии на кнопку "Вычислить"
её обработчик забирает из Edit'ов данные, проверяет различные опции и вызывает функцию
(функции) обработки и вычисления этих данных, после чего разкидывает полученные данные по
графическим элементам. Значит, теоретически можно найти "главную" функцию обработки данных, после чего просто вызывать её, передавая ей необходимые данные. Но для этого потребуется детальное изучение
кода программы, а в случае MFC — не знаю, можно ли будет отыскать в куче кода нужные функции.

Поэтому хотелось бы узнать, а есть ли ещё какие-нибудь варианты управления приложением?
Командную строку оно не поддерживает, да и сомневаюсь я в эффективности её использования; интерфейса
плагинов тоже, естесственно, нет. Точнее, я имею ввиду плагины не для расширения функциональности
самого приложения, а возможность использования части функциональности приложения другими
программами (как делают, напр., программы из MS Office, Maple и проч.).

А кроме вышеперечисленного, существуют ли ещё какие-то альтернативные способы управления
приложениями?

Если тебе нужно использовать много функций из программы , то замахаешься их искать и управлять ними , иначе можно бы наверное их выдрать и вставить в свою прогу . А сообщения по-моему самый оптимальный вариант , даже может случиться такое , что тебе ничё писать не надо будет , а взять готовую прогу из класса "macro work и автоматик" (macro express , macro scheduler и др.) и использовать скрипты .

bogrus
Да не много - я же говорю, ввёл данные в окошко, нажал кнопочку "Вычислить", забрал результат. Но делать это надо максимально быстро (хотя понятно, что быстрее, чем это делает сама прога не получится).

Плюс отслеживат её реакцию — с этим тоже придётся помучаться…

По моему большая часть времени тратится на отрисовку интерфейса реакции проги, и переброс на непосредственные обработчики или внедрённый поток ничего не даст, только дизасмить прогу, тогда ты может и уберешь интерфейс

ActiveSyn Automate.
она даже Drag'n'Drop умеет.
И скриптинг там есть. В общем попробуй, мне когда нужно было драг-н-дропом автоматизировать копирование фолдеров, и генерацию структуры фолдеров - она очень помогла.

[оффтоп]
А не проще ли калькулятор написать под свои нужды... Да и считать будет резвей.
[/оффтоп]

Возьми IDA, отдисзасмь прогу, выдери кусок кода, который все считает, и воткни в свою прогу. Что может быть проще? :)

rst
Спасибо, посмотрю, что и как он умеет.

Johnikum
Не совсем оффтоп, но… напиши-ка Maple 9.5 (MapleSoft) или хотя бы Derive 6.0 (Texas Instruments, кажется).

zed_0xff
Не уверен, что такое возможно (см. выше).

Да, не надо говорить об OpenMaple, я об этом знаю.
Меня интересует именно такой подход, о котором я писал…

а что, разве Maple свои COM-объекты не создает?
В приложениях такого уровня обычно предусмотрены средства взаимодействия (reusing/extending)...

„По моему большая часть времени тратится на отрисовку интерфейса реакции проги“

Тогда запустить прогу на отдельном (невидимом) десктопе, и пусть она это время не тратит :)

RobinFood
Что, серьёзно? Я как-то об этом не подумал, всё не удосуживался толком изучить WindowStations & Desktops.

Попробую, помотрю, что за результаты.

Хотя, в сложных вычислениях большая часть времени уходит непосредственно на сами вычисления, но не всегда.

Спасибо!

flankerx
СОМ не поддерживает Derive, он даже командную строку не поддерживает. Обещают в следующей версии добавить…

„всё не удосуживался толком изучить WindowStations & Desktops.“

Я их тоже не особо изучал, поэтому на 100% в своих словах не уверен. Попытался только что полистать MSDN - с ходу ничего такого (кроме фразы Minimizing a window speeds up system performance by reducing the amount of work an application must do when updating its main window.) найти не удалось. Попытался почитать про сообщение WM_PAINT, я смутно помню, что оно не посылается невидимым окнам - такого тоже не нашел. Нашел только, что An application should call the GetUpdateRect function to determine whether the window has an update region. Получается, что скорость прорисовки окна приложения зависит от того, насколько аккуратно приложение написано? Непонятно.

А зависит ли эта скорость еще от чего-то? Давай порассуждаем логически. Пусть приложение написано просто ужасно, и постоянно (независимо от того, нужно ли это) пытается перерисовывать свое окно. Если окно есть на экране, то неважно, какими функциями для этого пользуется приложение, рано или поздно управление будет передано драйверу видеокарты, который тоже потратит время на вывод изображения. Если же окна на экране не видно, то драйвер видеокарты управления просто не получит, и время будет хоть немного сэкономлено. А при частой перерисовке это "немного" будет умножено на это "часто" :)

С другой стороны, как я уже написал выше, минимизированное окно получает меньше виндовых сообщений, а неминимизированное, пусть даже на другом десктопе - почти столько же. Значит, для максимального ускорения вывода результатов можно вывести окно на другой Desktop, там его минимизировать, и управлять им только с помощью оконных сообщений (но не сообщений от клавиатуры/мышки).

Если у тебя будет желание, то лучше всего потратить немного времени для измерения скорости работы в 4-х ситуациях - обычное окно на активном десктопе, минимизированное окно на активном десктопе, обычное окно на неактивном десктопе и минимизированное окно на неактивном десктопе. Притом для тестов лучше не "тренироваться на кошках", а взять именно ту программу, с которой тебе нужно работать.

P.S. Пароль брутфорсишь, а в алгоритме копаться лень? ;)

RobinFood
Ты затронул очень интересную тему!

Но. Я почитал подробнее о WindowStations. В описании интерактивных служб (About services->Interactive
services) сказано, что только WinSta0 интерактивна, прочие не могут получать управление (мышь,
клавиатура, сообщения (?)) и отображать объекты. Desktop'ы, созданные на WinSta0, также интерактивны.
Т.е., нужно создать новый Desktop в WinSta0. ОК, с этим вроде понятно, попытаюсь разобраться.

Далее.

Получается, что скорость прорисовки окна приложения зависит от того, насколько
аккуратно приложение написано? Непонятно.
Я бы сказал, что от "аккуратности" зависит, куда уйдёт бОльшая часть ресурсов, в т.ч. и процессорное время.

Значит, для максимального ускорения вывода результатов можно вывести окно на другой Desktop, там его минимизировать, и управлять им только с помощью оконных сообщений
ОК. Ещё один (или даже два) шаг на пути увеличения производительности.

Притом для тестов лучше не "тренироваться на кошках", а взять именно ту программу, с которой тебе нужно работать.
Только нужно подготовить подходящий набор входных данных, чтобы дать бОльшую нагрузку на графический вывод, а не на вычисление.

Пароль брутфорсишь, а в алгоритме копаться лень? ;)
Кто сказал? :)
Нет, задача совсем другая, намного интереснее, на мой взгляд.
И в алгоритме не лень копаться, но я заблудился в кодах MFC (на RSDN нашёл статью по обработке сообщений в MFC, сейчас читаю). Поэтому пока остановился на сообщениях.

Так. Кстати, пока открыт вопрос о скорости обмена сообщениями между процессами и внутри процесса.

На всякий случай внедряю библиотеку в адресное пространство целевого процесса, это не сложно, но не знаю, даёт ли это значимое преимущество.

„Но. Я почитал подробнее о WindowStations. В описании интерактивных служб (About services->Interactive
services) сказано, что только WinSta0 интерактивна, прочие не могут получать управление (мышь,
клавиатура, сообщения (?)) и отображать объекты.“

Странно. У меня есть рабочая прога, которая создает WindowStation и Desktop, пока десктоп невидим, выводит на него MessageBox и ждет. При повторном запуске себя открывает, отображает десктоп с MessageBox-ом и сразу же закрывается. А первый экземпляр спокойненько дожидается нажатия кнопки и продолжает работу.

Хотя я только сейчас подумал - может, мой десктоп создается на winsta0, а я наивно верю, что на моей станции? ;)

„Так. Кстати, пока открыт вопрос о скорости обмена сообщениями между процессами и внутри процесса.

На всякий случай внедряю библиотеку в адресное пространство целевого процесса, это не сложно, но не знаю, даёт ли это значимое преимущество.“

При желании опять же можешь написать тест :)
Но можем и снова порассуждать логически. Если ты посылаешь сообщение с помощью PostMessage, то неважно, откуда ты его посылаешь - в любом случае происходит переключение контекста потока. А если ты посылаешь сообщение с помощью SendMessage, то при посылке из другого процесса тоже будет происходить переключение контекста, а при посылке из того же процесса переключение контекста... не знаю.

Где-то вроде бы встречал упоминание о том, что SendMessage тупо вызывает WindowProc, но что-то мне в это не очень верится, особенно если учесть, что в параметрах SendMessage есть только HWND, а значит, прежде чем вызывать WindowProc, его еще получить надо. Ну и заодно не помешало бы уточнить, какому процессу он принадлежит :)

RobinFood
„Если ты посылаешь сообщение с помощью PostMessage, то неважно, откуда ты его посылаешь - в любом случае происходит переключение контекста потока“
Где об этом узнать подробнее?!

„что SendMessage тупо вызывает WindowProc“
SendMessage(hWndTarget,WM_COPYDATA,,) - не совсем ndProc :)

Хотя… Где бы почитать более подробно и углублённо?