я завершення ніколи не відбувається в клієнтської формі. Дійсно, навіть Microsoft Systems Journal, який описує цей підхід, містить дуже багато попереджень про те, що при використанні цього підходу є деякі речі, які не працюють.
Деякі розробники, хто пробували розгортати додатки, які застосовують цей тип багатопоточності, виявили, що їх програми викликають збої після оновлення до VB5 service pack 2. p> Чи є це дефектом Visual Basic?
Чи означає це, що Microsoft не має забезпечила сумісність?
Відповідь на обидва питання: Ні
Проблема не в Microsoft або Visual Basic. p> Проблема полягає в тому, що вищезазначений код є сміттям.
Проблема проста - Visual Basic підтримує об'єкти і в моделі одиночного потоку і в apartment model. Дозвольте мені перефразувати це: об'єкти Visual Basic є COM об'єктами і вони, згідно COM угодою, будуть правильно працювати як в моделі одиночного потоку так і в apartment model. Це означає, що кожен об'єкт очікує, що будь-які виклики методів будуть відбуватися в тому ж самому потоці, який створив об'єкт.
Приклад, показаний вище, порушує це правило.
Це порушує Угода COM.
Що це означає? p> Це означає, що поведінка об'єкта подчиненно змінам, так як Visual Basic постійно модифікується. p> Це означає, що будь-яка спроба об'єкта звернутися до інших об'єктів або форм може потерпіти невдачу і що причини відмов можуть змінюватися, оскільки ці об'єкти модифікуються. p> Це означає, що навіть код, який зараз працює, може раптово визвить збій, оскільки інші об'єкти додаються, видаляються чи змінюються. p> Це означає, що неможливо характеризувати поведінку програми або передбачити, чи буде воно працювати чи може чи працювати в будь даному середовищі. p> Це означає, що неможливо передбачити, чи буде код працювати на будь-якій даній системі, і що його поведінка може залежати від операційної, числа використовуваних процесорів та інших проблем конфігурації системи. p> Ви бачите, що як тільки Ви порушуєте угоду COM, Ви більше не захищені тими можливостями COM, які дозволяють об'єктам успішно взаємодіяти один з одним і з клієнтами.
Цей підхід є програмною алхімією. Це безвідповідально і жоден програміст не повинен коли-небудь використовувати це. Точка. p> Повернутись до функції API CreateThread
Тепер, коли я показав Вам, чому підхід до використання CreateThread API, показаний у деяких статтях, є сміттям, я покажу Вам, як можна використовувати цю API функцію безпечно. Прийом простий - Ви повинні просто твердо притриматися угоди COM про потоках. Це займе трохи більше часу і зусиль, але практика показала, що виходять дуже надійні результати.
Приклад MTDEMO3 демонструє цей підхід у формі frmMTDemo3, що має код, який запускає клас фону в apartment model наступним чином:
Private Sub cmdCreateApt_Click ()
Set c = New clsBackground
StartBackgroundThreadApt c
End Sub
