Здравствуйте, Scilur, Вы писали:
S>Во-первых, большое спасибо всем принявшим участие!
S>Во-вторых, рад сообщить, что проблема таки развязалась успешно.
S>Ну и, в-третьих, если кому интересно, сообщаю: дело, действительно, заключается в работе с очередью. И беда тут в том, что при переходе из одного состояния в другое, эта самая очередь становится временно недоступна (конкретней пока ничего не могу сказать). Поэтому, чтобы все события срабатывали нормально, необходимо, чтобы после срабатывания одного события и перед перехватом другого, вся стейт-машина хоть на мгновение, но попала в состояние IDLE. Для этой цели служит аргумент WaitForIdle в классе ExternalDataEventArgs. Выставляя его в TRUE, Вы определяете, что никакое новое событие не будет рассматриваться до тех пор, пока машине не побывает в состоянии IDLE. В результате все начинает работать корректно.
S>Еще раз всем большое спасибо!
Подозреваю, что трактовка происходящего у вас не вполне верная
, хотя рецепт, очевидно — абсолютно правильный.
S>эта самая очередь становится временно недоступна (конкретней пока ничего не могу сказать)
Тут как раз все вполне понятно. Очередь создается при заходе в конкретное состояние (точнее, группа очередей, по одной для события) и
уничтожается при выходе. Если в следующем состоянии есть обработчик того же события, то очередь для его обработки будет создана заново.
S>Поэтому, чтобы все события срабатывали нормально, необходимо, чтобы после срабатывания одного события и перед перехватом другого, вся стейт-машина хоть на мгновение, но попала в состояние IDLE.
Не думаю. На самом деле все проще гораздо — если вы задаете флаг, то событие попадет в workflow только тогда, когда она войдет в состояние idle, это верно. Но
когда она войдет в idle? Это произойдет после того, как переход в другое состояние в результате обработки сообщения будет завершен и wokflow уснет в ожидании новых событий — предварительно создав все нужные учереди. Вот тут-то ваше отложенное событие workflow и догоняет.
Вам спасибо, я про этот флаг и не знал даже.
