Команда из таймера, или аналог DoEvents, или

Автор Тема: Команда из таймера, или аналог DoEvents, или  (Прочитано 6591 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн WingАвтор темы

  • ADN Club
  • Сообщений: 17
  • Карма: 0
Здравствуйте.

Надо выполнить примерно такую последовательность:

1) загружается arx, выполняется команда myinit, заполняющая чертеж,
2) здесь надо дать обработаться остальным событиям, поскольку при смене профиля и его сбросе автокад (2010) сам делает команду RIBBON, которая фактически отрабатывает после RIBBONCLOSE, если ее делать в п.1
3) выполнить RIBBONCLOSE, чтобы закрыть уже появившуюся ненужную ленту
4) дать обработаться событиям, чтобы окна приняли свой размер
5) выполнить zoom e, regen, чтобы объекты корректно отрисовались по масштабу окна (иначе сначала определяется масштаб и объекты масштабируются под него, а команды изменяющие размеры области чертежа отрабатываются позже, и масштаб проведенного расчета не соответствует финальным границам области чертежа)

попробовал использовать таймер, но автокад игнорирует команды из функции таймера.
причем, threadId потока таймера и потока, в котором происходил вызов myinit, совпадают, что не дает понять, почему не работают команды из функции таймера
гугление выдало ряд авторитетных мнений, что автокад из таймера вообще юзать не надо.

а как корректно реализовать изложенный сценарий?

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13830
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Тему достал из удаленных. Стало интересно удалось ли найти решение и если да, то какое?
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн WingАвтор темы

  • ADN Club
  • Сообщений: 17
  • Карма: 0
Непосредственно подачу команд из таймера сделал так:
Код - C++ [Выбрать]
  1. acDocManager->sendStringToExecute(acDocManager->curDocument(), L"_ribbonclose\n");

а вообще с этими профилями весело.
сброс профиля не может выполниться полностью во время последовательности команд - перед следующей ему надо дать паузу.
ribbonclose (для моего интерфейса) после сброса профиля тоже требует паузы, иначе ribbon от автокада срабатывает после него, и из-за своего _menu имеем пустую ленту
также надо реализовать обеспечение второго профиля, кроме своего, и его запись как дефолтный, в HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R18.0\ACAD-8001:419\Profiles\по умолчанию, чтобы ярлычок автокада обеспечивал дефолтный интерфейс автокада при восстановлении интерфейса. а это тоже сброс профиля и тоже пауза
после формирования профиля для интерфейса автокада надо создать/восстановить свой профиль, сбросить его, выдержать паузу, и донастроить, опять же с паузой
команда восстановления интерфейса может быть вызвана в любое время, и тоже потребовать всех пауз
при запуске автокада из отчета нужен наш интерфейс, но масштабирование по границам не нужно, нужно масштабирование по объекту, а оно отрабатывает без пауз

поэтому пришел к тому, чтобы создавать очередь действий, в которой могут быть команды и паузы
при получении команды будет формироваться очередь действий, разная в разных случаях, и запускаться таймер
очередь пар (тик, код_команды) будет обрабатываться в таймере: увеличивается счетчик тиков, и если в очереди этот тик есть, выполняется соотв. операция (ряд команд через sendStringToExecute)
если очередь опустела, прибить таймер 

покритикуйте, Александр, может быть, тут что-то неправильно с автокадовской точки зрения?
в частности, запись имени дефолтного профиля в HKCU\...\Profiles сразу после переключения на наш профиль

весь этот гемор вот зачем:
1) у пользователя 2 ярлыка - автокадовский для интерфейса автокада и наш для нашего интерфейса
2) каждый из интерфейсов можно донастраивать и сохранять в рамках профилей
3) если что-то зарегулировал, есть команда восстановления интерфейсов
4) если нет даже команды - переустановить
5) не иметь возможности так все испортить и остаться без средств восстановления, чтобы меня отвлекать

Оффлайн Николай Горлов

  • ADN
  • *
  • Сообщений: 238
  • Карма: 34
Цитировать
весь этот гемор вот зачем:
1) у пользователя 2 ярлыка - автокадовский для интерфейса автокада и наш для нашего интерфейса
2) каждый из интерфейсов можно донастраивать и сохранять в рамках профилей
3) если что-то зарегулировал, есть команда восстановления интерфейсов
4) если нет даже команды - переустановить
5) не иметь возможности так все испортить и остаться без средств восстановления, чтобы меня отвлекать
ну как-бы у всех более-менее больших программ та же ерунда. не пойму в чем проблема.
1. два ярлычка. акадовский запускается акад с его текущим профилем. тут мы ни на что не влияем.
наш ярлык. запускает exe-шник, который проверяет, есть ли ветка профиля с нашим именем, если есть, то ставит ее текущим в реестре, если нет - создает в реестре на основе текущей, дописывает своего мусора и в реестре ставит текущей. также делается пометка (в реестре или на диске - не важно) с именем предыдущего текущего профиля, если это не наш профиль был. ну и всё. дальше exe-шник запускает акад (профиль в реестре уже стоит наш). когда акад выгружается, происходит замена значения текущего профиля на тот, который мы где-то сохранили.
2,3,4,5 получаются автоматически. например, зайдя в програму под новым пользователем exe-шник настраивает свой профиль. (та же ерунда, если профиль пригробили руками через окно настроек в автокаде)

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


Оффлайн WingАвтор темы

  • ADN Club
  • Сообщений: 17
  • Карма: 0
кроме ваших двух скользких моментов, есть еще пара минусов у этого решения:
- нужен дополнительный ехе-шник
- текущий профиль меняется при выходе - это не дает запустить наш и дефолтный интерфейс одновременно (хотя вроде и решаемо)

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

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13830
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Wing, Николай тебе написал самый идеальный вариант, который возможен при работе с AutoCAD. Мы пользовались аналогичным в МАЭСТРО на протяжении десятка лет и ничего луше придумать не смогли.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение