| |
|
|
| | есть форма в ней меняется RecordSource по ходу нажатия клавиш, и при загрузке кодом устанавливается по умолчанию.
на одном компе при открытии формы/изменения RecordSource кодом после выполнения
, проверено отладчиком,
все поля становятся пустыми (белыми), кроме того что имеет фокус, при этом горит надпись - "Обработка команды...", но все обработки - нажатия клавиш, действия мыша - все выполняется.
если форму сверну/развернуть то поля принимают нормальный вид со своими значениями.
и нормально себя ведет до нового возникновения RecordSource.
если нажать Ctrl+Break - пишет стандартное сообщение о прерывании работы с выбором Continue, End, debug, Help
при переходе в Дебаг открывается код обработки Поле_KeyDown (), и дальше в се в норме, опять же до возникновения нового RecordSource кодом.
на других компах форма работает нормально.
на глючном компе все остальные формы работают нормально.
что это есть. | |
| |
| |
| |
|
|
| | может в этот момент таблица открыта в режиме редактора??? | |
| |
| |
| |
|
|
| | нет, она открыта в простой форме, даже если перевести в редактор а потом опять в форму возникает таже хрень
забыл добавить - Диспетчер задач начинает радостно показывать 50% загрузку Аксом 
снес в коде формы все обработки нажатия кнопок - не помогло.
при чем поля белые только те которые связанные с другой таблой. | |
| |
| |
| |
|
|
| | так пошли дальше - проблема в полях где стои =Naimen.column(1) а само полеСоСписком Naimen отображается правильно - на форме есть и невидимо.
Получается проблема в Column(1).
Но при открытии других форм с таким же построением на теже поля такого не возникает | |
| |
| |
| |
|
|
| | Создай заново форму.
а само полеСоСписком Naimen отображается правильно - на форме есть и невидимо.
|
А нафига такой изврат? | |
| |
| |
| |
|
|
| | для того чтобы юзеры не лезли в полесосписокм, а лицезрели только его присоединенное значение, и тем более его не правили и не пытались че либо выбирать.
может и по другому можно сделать, но как то я так привык. | |
| |
| |
| |
|
|
| | А сделать public переменную и к ней обращаться слабо? | |
| |
| |
| |
|
|
| | для чего переменную | |
| |
| |
| |
|
|
| | вернусь к теме
вывел поля из которых получаем значения - так они видимы но мигают как будто команду Requery воткнули в цикле бесконечном. | |
| |
| |
| |
|
|
| | Сбрось сюда эти чудеса на виражах. А то со слов слабо понимаю.
Старческий маразм, блин. | |
| |
| |
| |
|
|
| | А ты не делай его невидимым. Попробуй просто прозрачность сделать, выводя на форму видимым. Заблокируй доступ и усе.
Ну если это то, что я думаю. У меня та же хрень есть. Глобальные переменные создал, значения им присвоил, а как в запрос воткнуть ума не хватило. Вот таким способом свободным полям их значения присвоил, прозрачность да, доступ нет и пахает. В запросах ссылки Форма!Поле.... и пахает блин. | |
| |
| |
| |
|
|
| |
Глобальные переменные создал, значения им присвоил, а как в запрос воткнуть ума не хватило
|
CurrentDB.Execute"INSERT INTO Tbl1(Field_1) VALUES (PublicVar)"
, где PublicVar- public переменная. | |
| |
| |
| |
|
|
| | Спасибо. Бум пробовать.
Но у меня запросы на изменение и сложнее гораздо. Переменные в условия вкатывать надо и их значения подставлять вместо существующих. С датами особая заморочка. Форматы блин, синтаксисы, решетки... | |
| |
| |
| |
|
|
| | папаша Мюллер, :), ты присал про глобалку, а как применить ее если я на форму вывожу поляСосписком из таблицы. | |
| |
| |
| |
|
|
| | В модуле объявляешь глобальную переменную. При выборе из поля со списком значения - присваиваешь это значение глобальной переменной. А затем в других формах работаешь с этой переменной, а не с невидимым комбобоксом. | |
| |
| |
|
|
|
|
| |
|
|
| | 1. Не использовать русские имена объектов, категорически!!!
2. Не использовать в коде русских имен (переменные, функции и т.д.)!!!
3. Не использовать в свойствах полей "Данные" конструкции типа: "=....",
потому как очень медленно, и непонятно, когда определит значение.
4. При частых правках в коде делать импорт всех объектов в новый файл.
5. ... | |
| |
| |
| |
|
|
| | Блин. А что тогда делать? Все 5 пунктов то, чем работаю. Это пипец.  | |
| |
| |
| |
|
|
| | Использовать "правильные" альтернативы. | |
| |
| |
| |
|
|
| | а какая альтернатива использованию в данных "=....."
дело в том что я именно так вывожу многое (ленточные формы), для того чтобы юзер видел только привязанное поле и не мог его изменить случайно, а ПолеСоСписком я ваще не использую в формах в видимой форме, т.к. для выбора оно не удобно, только для - данных "=ПолеСоСписком.column(1)"
| |
| |
| |
| |
|
|
| | 2 Гоблин
У тебю еще не пипец, вот у кота точно полный пипец из-за этого:
а ПолеСоСписком я ваще не использую в формах в видимой форме, т.к. для выбора оно не удобно
|
| |
| |
| |
| |
|
|
| | если в списке 10 наименований длинной макс 10-15 символов (грн. руб. долл. евро.)- не спорю, но если список 1000-2000 наименований, длинна 50-100 символов,
различие в названиях иногда начинаются с 20-30-го символа какой тут прок от ПоляСоСписком - тут форму открывать надо, выбирать и вносить значение. | |
| |
| |
| |
 20 Кб. |
|
| | Ну тогда можно реализовать что-то вроде этого | |
| |
| |
| |
|
|
| | правильно это Справочник, а речьидет о Списке на основании справочников
http://slil.ru/28293438
там две формы Detalirovka - это кусок из проги, она использует в качестве источника временную таблу пустую, для выбор даблклик и выббор из справочника.
а Detalirovka_2 - просто сделал видимыми списки - и вопрос что визуальней смотрится. | |
| |
| |
| |
|
|
| | сруктура таблиц неважная ( читай жуевая)
Не используй в таблицах условия подстановки и тип поля - комбобокс .Просто коды из таблиц справочников. Тогда и отпадет необходимость делать невидимыми комбобоксы.
И постепенно будет тебю щастье. | |
| |
| |
| |
|
|
| | Я не совсем понимаю Вас тов. Мюллер
про структуру таблиц - в чем видится жуевизна, это не праздный интерес, может есть более работоспособное решение, а я его не знаю, Акс сам учил (Борей и проч.)
Не используй в таблицах условия подстановки
|
это о чем?
не использовать в таблицах полеСоСписком, а чо если мастер постановки его создает сам.
или создавать поле, потом ручками в структуре писать связь. так на хрен тада Акс, если еще Клиппер спокойно работал так с DBF - все связи в голове, в полях только цифры.
Просто коды из таблиц справочников.
|
так оно и так реально хранит только код строки Справочника. | |
| |
| |
| |
45 Кб. |
|
| |
Не используй в таблицах условия подстановки
это о чем?
|
см вложение.
Для формы нужно сделать источником запрос, использующий конструкции Join для вывода в поля не кодов, а соответствующих названий из справочников. Тогда необходимость в комбобоксах отпадет напрочь. | |
| |
| |
| |
|
|
| | Да и еще. После реализации запросов с inner join-ами отпадет куча вопросов из оперы почему акс так загружает процессор.
Это ж в форму выводится туева хуча ненужной информации. Ведь, если в форме Detalirovka в поле18 нужно записать название из справочника Vid с кодом ,например1 - основные материалы , не нужно тащить весь справочник в комбобокс Naimen. Там этот комбобокс просто не нужен. | |
| |
| |
| |
|
|
| | про Join я в курсе, но если источник формы запрос из боллее 1-й таблы тогда добавить в форму ничего нельзя, нужно добавлять программно в таблу и обновлять источник формы
или как.
просто когда начинал ни с VB ни и SQL не дружил и сталался обойтись без запросов.
а это получилось, привык. | |
| |
| |
| |
|
|
| |
но если источник формы запрос из боллее 1-й таблы тогда добавить в форму ничего нельзя, нужно добавлять программно в таблу и обновлять источник формы
|
Почему нельзя? если запрос обновляемый, то можно. И не обязательно запрос из нескольких таблиц будет необновляемый. | |
| |
| |
|
|
| |
|
|
| | Ау мну в ленточной форме на таком запросе добавляет записи
SELECT Naimen.Naimen, Vid.Vid, Ed_izm.EI, Naimen.Tcena, Naimen.Analog, Naimen.Ves_1pm, Naimen.D, Naimen.L, Naimen.S
FROM Ed_izm INNER JOIN (Vid INNER JOIN Naimen ON Vid.Kod_V = Naimen.Vid) ON Ed_izm.Kod_ei = Naimen.EI; | |
| |
| |
| |
|
|
| | А вааще то правильней разделять запросы.
Запросы на выборку записей не должны разрешать доббавлять. Добавление, равно как и изменение делается в отдельных запросах и отдельных формах.
Енто правильно еще и с точки зрения безопасности и разделения прав пользователей. | |
| |
| |
| |
|
|
| | Странно, с таким запросом тоже добавляет записи, хотя, по идее, не должен
SELECT Naimen.Naimen, Vid.Vid, Ed_izm.EI, Naimen.Tcena, Naimen.Analog, Naimen.Ves_1pm, Naimen.D, Naimen.L, Naimen.S
FROM Ed_izm RIGHT JOIN (Vid INNER JOIN Naimen ON Vid.Kod_V = Naimen.Vid) ON Ed_izm.Kod_ei = Naimen.EI; | |
| |
| |
|
|
| |
|
|
| | Ну нихрена вы тут партобрание знатоков устроили. Жаль всю дискуссию прорпустил.
У меня работа с базой сводится к нажатию 2-3 кнопок. Поля заполняются автоматом из справочников. 4 таблы для заполнения и 15 табл как справка. Все шаблоны готвят заранее. Но это от специфики работы зависит. Поле со списком бывает из 12000 наименований. Но, при вводе первого символа происходит открытие списка и отсев всего по этому списку. С вводом 2 символа все отсеивается в уже открытом списке. Таким образом юзер не видит все 12000 чего-то там, а только не более 20-25 наименований и то по первому символу. Введя 4 символа ему останется все остальное выбрать стрелокой вниз.
А на счет inner join так еще круче. Формы с таким запросом из 2-3 табл заполнять одно удовольствие. 1-у назначаешь 3 чего-то и он 3 раза появляется. Оказалось это бывает очень полезно. Для визуализации.
2.Поле со списком в таблу никогда не ставлю. Все преобразованное в форме. В табле одни поля. Мастером подстановок вовсе не пользуюсь.
3.Поле со списком если свободное, то используется для поиска и автоматического ввода данных в таблу, если таковых там нет. (Но это естественно не везде) Как правило все ограничено списком.
Наверняка осудите как неправильный подход, но работает и народу нравится. Наверняка что-то лучше есть, но совершенству нет придела. Так что, кот, зря поля со списком игноришь. | |
| |
| |
| |
|
|
| | если б все ттак просто - мы хотим так как в 1С, но по другому и в принцыпе немного не так, а вот так и с зеленой полосой по диагонали, даже если б этим все ограничивалось - и то ладно, так не им через каждые полгода надо видеть тот жеотчет в другой форме, виде и маслом на холсте.
короче ну их.
всем спасибо,  | |
| |
| |
