Оказалось, что проблема некорректной работы потоков состояла в том, что потоки, когда я их запускал друг друга перебивали и тем самым не давали работать друг другу. Порывшись немного в сети я нашел ещё 2 способа:
- ООП (то есть мы в лучших традициях объектно ориентированного подхода создаем класс, у него конструктор, деструктор, перезагружаем от предка синхронизатора и т.д.. Потом просто в нужном месте каждый раз вызываем объект этого класса. Поработав с ним завершаем работу - уничтожаем его и вызываем другой объект. Все просто.).
- Второй способ оказался намного проще. Мы просто создаем компонент, который представляет уже зарезервированный поток что то типа TMyThread. В нем уже есть все необходимы директивы, и синхронизатор и конструктор и прочий суповой набор.
Все, я сначала подумал что дело в шляпе, но, тут как всегда НО. Дело в том, что нам надо ещё создать поток который будет управлять потоком……стоп…………….точно!…понял….так….а его мы создадим как обычный, локальный, без какого либо класса. Вот и мысль пришла.
Назвав пап ку V.2.2 я переписал принцип работы. Поставил заглушки, настроил боле-менее правильную работу алгоритма и теперь можно с чистой совестью идти спать.
Но перед этим надо прописать хотя бы тут алгоритм:
1.Перерисовка окна и обнуление массивов координат и идентификаторов ячеек поля при изменении размера (заменим Image на PaintBox).
2.Напишем процедуру, которая будет реагировать видом рисунка на входной параметр.
3.Булевская функция будет постоянно меняться после каждой прорисовки, получится что это будет "как бы" один игрок, но только он будет постоянно брать в руки другой маркер (это просто абстракция).
4. После каждой прорисовки будет проверятся есть ли победитель (это мы возьмем из прошлой версии).
5.Счетчик, который будет считать общее кол-во нарисованных фигур. Как только значение будет равно 8 (естественно от 0-ля), то мы приостанавливаем потоки и выводим сообщение о ничьей.
Вот и все. Суббота кончилась. Завтра целый день без компа. Работа…