Какие утверждения являются справедливыми в ситуации, когда управление бизнес-логикой приложения осуществляется в визуальном интерфейсе, работающем в потоке, отличном от потока, в котором работает бизнес-логика?
Рассмотрим ситуацию, когда управление бизнес-логикой приложения осуществляется в визуальном интерфейсе, работающем в потоке, отличном от потока, в котором работает бизнес-логика. Какой недостаток можно отметить в организации взаимодействия управляющего и управляемого процесса, основанного на взаимных ссылках?
Для того, чтобы корректно работать с элементами управления, созданными в другом потоке, можно использовать следующие методы:
При разработке бизнес-логики приложения какой тип проекта, скорее всего, следует предпочесть?
Какие утверждения справедливы по отношению к взаимодействию двух частей приложения – интерфейса и бизнес-логики?
Что понимается под понятием "бизнес-логика" в данном контексте?
Что происходит, когда в многопоточном приложении один поток пытается непосредственно обращаться к элементам управления визуального интерфейса, созданным в другом потоке?
Программисту необходимо, чтобы в потоке выполнялся метод, имеющий три аргумента. Конструктору потока передать такой метод невозможно. Какие решения позволяют справиться с возникшей ситуацией?
В многопоточном приложении элементы управления визуального графического интерфейса, созданные в одном потоке:
Работа с какими классами ведется в интерфейсной части приложения?