Немного истории:
Клавиатурный "фокус" при использовании xp/Vista стилей (с манифестом)
Задача: восстановить "отображение фокуса"(точечки вокруг элементов), если user нажал Tab(применил клавиатуру).
Отлавливается событие _LostFocus(), но если элементов сотни, то неохота прописывать это событие сотни раз, а хочется универсального кода.
Была решена год назад:
Каждому элементу сопоставляем класс ClassFocus:
Событие класса _LostFocus() вызывает ф-цию Parent.FocusRectangles,
которая проверяет не табом ли вызвана потеря фокуса, и включает "отображение фокуса".
Естественно реально работает только
1) в живом exe 2) с манифестом.

Этот код прекрасно работает для
Command1
Command2
Command3

Но дает сбой, если есть
Command4(0)
Command4(1)
Command4(2)
Массив элементов и наличие индексов.

Мотивы в принципе понятны, но с ходу не соображу как исправить (и можно ли)...

Естественно я могу обойти, выделив частные случаи массивов
не используя класс и прописав для них явно
И наверно так и сделаю дабы не морочить себе голову,
если только кто умный не подскажет:
Как изменить код, чтоб он работал и для массивов элементов тоже?
Дабы повысить шансы на получение ответа, вычленил сказанное в отдельный тест-проект и прилагаю.

Я также могу не использовать массивы кнопок и т.п., но т.к. к-во элементов на форме давно превысило критические 255, то вынужден затягивать пояс все туже и туже, Label\'s-ы уже все исчерпаны, дошла очередь до button\'s и прочего, что уже завязано на коды. Скоро видимо взвою по данному вопросу, но пока держусь.

Shocker.Pro попробую переформулировать
Честно, не уверен что переформулировал правильно.
Идея в том, что для каждого контрола я подменяю событие контрола событием класса, сколько бы их не было, т.е. мне не надо писать обработку события для всех контролов на момент внедрения идеи и помнить о каждом новом элементе при добавлении.

Хотя мой код и не идеален, ибо для каждого типа код прописан отдельно, и есть явные издержки, тем не менее он работал до момента появления массивов контролов. Т.е. класс не создается для контрола с индексом.

>Я щас попробовал добавлять кнопки на форму динамически и добавил их 300 штук
от этого я воздерживаюсь всеми силами, с динамикой потом очень тяжело разбираться.

>но она тебе не понравится мне кажется - облечь кнопку в простенький юзерконтрол
конечно, не понравится. Предлагаешь накручивать код еще большим к-вом "механизьмов", поверь у меня их хватает.
В данном случае хорошо хоть нашел вышеуказанную проблему, ибо в ориг. приложении в отличии от тестового у меня был crash kernel32.dll, что слабо намекает на "фокусы".

Самое простое, что я уже сделал чтоб не тормозить (workaround):
>Естественно я могу обойти, выделив частные случаи массивов
>If Ctr.Name = "Command4" Then GoTo Skip1
>не используя класс и прописав для них явно
><потерю фокуса>

или таки мой вопрос
Как исправить имеющийся класс/его инициализацию на предмет массивов?

или вернуться к изначальному вопросу:
Как универсально сгенерировать событие потери фокуса любым элементом формы, для кот. это событие может происходить? (массив/не массив, и не важно что это кнопка/текстбокс/листview)

Shocker.Proдобавлять кнопки на форму динамически,...массив классов,...грубая идея.
Вот, только не обижайся. За желание помочь - спасибо.
Предлагаешь-таки городить новый огород, который я в силу
своих убеждений, предпочтений, упрямства, тупости наконец городить не хочу.
Вспоминается мое бодание с ActiveX EXE, кот. закончилось тем что я "забил на это".

Вопрос по сути решается на данном этапе (и даже с нек. запасом прочности) добавлением нескольких
1) "skip частные случаи массивов"
2) нескольких _LostFocus для этих частных случаев

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

Я понимаю что Вы обратили внимание на

>к-во элементов на форме давно превысило критические 255, то вынужден затягивать пояс все туже и туже, Label's-ы уже все исчерпаны, дошла очередь до button's и прочего

но я ведь "затягиваю пояс", а не "истерически вопию" (коих примеров на сием форуме далеко ходить не надо).

Ну да, согласен. Если так дальше продолжать жить, то можно исчерпать все ресурсы.
Но, опять же, не факт что подход "откуда еще изыскать кнопок/чекбоксов/текстбоксов" суть правильный.
В принципе для отображения настроек достаточно одного Listview и одного Treview. Типа Консоли MMC.
Все канонично и экономно.
А менять настройки можно и через отдельные "подформы", и ежли в какой-либо "новой версии" эту идею реализовать (подумываем-с, что пока лениво это понятно), то к-во элементов резко поубавится и необходимость решения кучи подобных проблем и огородов отомрет , и чем больше их будет, тем сложнее их будет разгребать на момент перехода на более канонический уровень. Хочу сказать, что надо думать о будущем и не усложнять настоящее...