Здесь тоже - все красное убрать.Банджо








Public Function ColorFT(Color_FT As Boolean)
Select Case Color_FT
Case Color_FT = False
...
Case Color_FT = True
...
End Select
End Function

Банджо__Michelle, а вот
Dim Color_FT As Boolean
почему убрать? Ее ж надо объявить? Или в самой функции достаточно????!!!
Это совершенно разные Color_FT.
То, что объявлено в общей области, нигде, судя по коду, не используется.

Дополнительно;
В процедурах обработки событий Вход/Выход только вызов функции?
Тогда почему не прописать это не в VBA, а просто в конструкторе =ColorFT(True)/=ColorFT(False) ?

Mina Anna Mazzini__Michelle,

и все-таки хотелось бы услышать начальника транспортного цеха...

18335125
18355293
.)))
По второму пункту - абсолютно согласна с 8772.
Просто не стала убирать из текста ТС, ведь уже было сказано.

По первому - отвечу чуть позже, сейчас срочно убегаю...

Удивительное дело!
Собралась ответить, а исходного сообщения-то и нет...
Что такое, неужели новый виток Звездных Войн?
Ощущение странноватое: то ли зыбучие пески, то ли Кафка...
Может, модераторам стоит оставлять пометку типа "Очищено по такой-то причине..."?

Но, к делу.

Mina Anna Mazzini,

1. Сначала уточнения и дополнения по второму пункту -
там Select Case для всего двух вариантов, True и False, поэтому я бы ограничилась конструкцией
If Color_FT Then
......
Else
......
End If
2. Так. Только что для ответа по первому пункту хотела освежить в памяти его формулировку.
Но там тоже все стерто. Господа модераторы, что это?
Ладно, попробую, как помню.
- Сначала было о том, что, согласно best practice, нужно не If z = True Then, а If z Then.
Да. Именно так всегда и делаю.
Но там шла речь о баге Access, нейтрализовывался который добавлением "= True".
То есть, это была вынужденная мера.
- Потом предлагалось использовать CBool(z).
Вообще-то там дело было не в том, что неверно распознается z как Boolean, ведь программа отрабатывала нормально.
Но в конце не закрывался Access.
Но проверить бы не мешало.
Только для этого нужно найти машину с Acc97, так как это его баг. И чтобы ситуация воспроизводилась.
Пока не удалось. Даже поставила на ноутбук Acc97, но ошибка не возникает, может, потому, что Win 7.
Но я об этом помню, при возможности проверю.

Надеюсь, текст дойдет по назначению.)))

Панург__MichelleНо там шла речь о баге Access, нейтрализовывался который добавлением "= True".Баг? Ну незнаю... ИМХО, дело в неправильном написании.

VBA многое "прощает"...Явное указание Me, как и явное указание Value , не является обязательным .
У меня их отсутствие никогда не приводило к погрешностям в работе программы.
Однако, при возможности, проверю и эту версию. Хотя бы для того, чтобы ее исключить.
Но только для Value, так как баг проявляется при Parent, забыла сразу пояснить.

Что касается "баг-не баг", то вот, пожалуйста, что об этом на rusimport, hiprog, cyberforum:
http://am.rusimport.ru/MsAccess/topic.aspx?ID=107 Не закрывается окно Access. Официальная ошибка Microsoft.
http://hiprog.com/index.php?option=com_content&task=view&id=146 Не закрывается окно ACCESS... Это действительно глюк, но исправимый.
http://www.cyberforum.ru/ms-access/thread473289.html это ошибка самого Microsoft Access.
И, конечно, на sql.ru Аccess не закрывается Речь идет о баге.
При этом в статьях по этим ссылкам практически везде используют полный синтаксис типа Me.Parent.chkBox (правда, без Value).

[quot Панург]__MichelleВидимо там действительно баг со свойством по умолчанию. Получают не свойство контрола, а сам контрол, ИМХО. Мне кажется, тогда возникла бы ошибка времени выполнения.
Но этого не было.
И только в самом конце - окно Access висит, закрывается только из диспетчера задач.

Жаль, что пока негде проверить.
Вдруг, Вы правы...
Тогда действительно мой подход "все, что можно игнорировать - игнорировать"
нужно заменить на Ваш "все, что можно указать - указать".
Интересно, конечно.

У меня ошибка в цитировании. Правильно так:ПанургВидимо там действительно баг со свойством по умолчанию. Получают не свойство контрола, а сам контрол, ИМХО.

Очень интересное и полезное для меня обсуждение.
Спасибо всем!

Конечно, хотелось бы знать и применять позднее связывание.
При переводе из одной версии в другую часто приходится вручную переопределять отвалившиеся библиотеки.
При позднем связывании этого не потребуется?
Еще интересует, работает ли оно в MDE?
Я пока совершенно не представляю, что это такое.

Возвращаюсь к обсуждаемому выше багу прошлых лет -
зависанию окна Access при завершении работы,
если в программе использовалась конструкция If Parent.z Then,
где Parent.z - флажок в родительском окне.

Нашлась машина, где эту ситуацию удалось воспроизвести.
Проверила предложения по исправлению от
Mina Anna Mazzini - использовать CBool(Parent.z)
и
Панург - использовать Parent.z.Value.

Результат: оба способа прекрасно действуют - Access не зависает.

Вот что значит, уметь зреть (зрить?) в корень!

P.S. Но жаль, что некоторые сообщения на эту тему здесь удалены.
Было что-то интересное от Mina Anna Mazzini о разнице в трактовке флажка VB и VBA.
P.P.S. Ну, и заодно.
В теме Помогите составить SQL-запрос также было удалено сообщение Mina Anna Mazzini с вопросом,
почему в качестве фиктивной таблицы предлагается использовать msysobjects, а не к.-л. реальную таблицу запроса.
Вроде пустяк, ответ, видимо, что-то вроде "так исторически сложилось"...
А вот и нет. У ТС с msysobjects не сработало, а с таблицей запроса - да.
Почему, так и повисло в воздухе...

Понимаю, что чистится под горячую руку, но все же, не в ущерб бы общему смыслу...

Predeclared,

Ну не знаю, я всегда ставлю значение по умолчанию - чаще всего требуется False.
Но ведь при Null, без Nz(...) всегда будет Invalid use of Null, независимо от версии Access,
это будет стандартная ошибка времени исполнения.
Это к рассматриваемому вопросу не относится.
А баг, о котором речь, был характерен для Acc97, у меня под Win XP, под Win 7 не обнаруживается.

Predeclared,

Хорошо. Интересно.
Сегодня проверю.
На Acc2003 SP3 под Win7 и на Acc97 под XP.
О результатах сообщу.)))