DBGrid

← →
AlekseyB (2008-06-24 08:59) [0]

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

← →
engine © (2008-06-24 09:01) [1]

ИМХО, в знаниях

← →
AlekseyB (2008-06-24 09:05) [2]

> ИМХО, в знаниях

в том то и дело что знаний маловато, поэтому и советуюсь !!

← →
engine © (2008-06-24 09:09) [3]

Во первых в гриде данных нет, и там их сохранить нельзя.
Во вторых, как меняешь, как сохраняешь не понятно.

← →
AlekseyB (2008-06-24 09:12) [4]

> Во первых в гриде данных нет, и там их сохранить нельзя.

Я написал, что отображаются данные , а не хранятся

← →
Sergey13 © (2008-06-24 09:15) [5]

> [4] AlekseyB (24.06.08 09:12)

Программа вообще твоя или ты видишь ее только на экране соседа?

← →
AlekseyB (2008-06-24 09:23) [6]

Моя программа, но тока начал писать, так подскажите как мне сделать, чтобы при занесении данных в грид, они сохранялись в базе. Спасибо заранее

← →
engine © (2008-06-24 09:28) [7]

Что за СУБД, какие компоненты доступа используешь?

← →
AlekseyB (2008-06-24 09:29) [8]

> Что за СУБД, какие компоненты доступа используешь?

MS SQL, компоненты ADO

← →
korneley © (2008-06-24 09:39) [9]

> AlekseyB (24.06.08 08:59)

Много зависит от того, откуда и как берутся данные для отображения. База какая? Механизм извлечения данных? Используемые инструменты? Поподробнее, и тогда, возможно, будет о чём говорить.

← →
AlekseyB (2008-06-24 09:46) [10]

> Много зависит от того, откуда и как берутся данные для отображения.
> База какая? Механизм извлечения данных? Используемые инструменты?
> Поподробнее, и тогда, возможно, будет о чём говорить.

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

← →
engine © (2008-06-24 09:50) [11]

Ну теперь всё понятно. Такие ошибки чаще всего происходят в 17-ой строке

← →
Sergey13 © (2008-06-24 09:50) [12]

> [0] AlekseyB (24.06.08 08:59)
> хотя не всегда

Типа по пятницам не сохраняет? Или другие какие закономерности есть?

> [8] AlekseyB (24.06.08 09:29)
> компоненты ADO

Все сразу или какие то конкретные?

По ходу нет фиксации изменений в датасете и/или в БД.

← →
Юрий Зотов © (2008-06-24 09:55) [13]

> Когда меняю несколько записей то сохраняет нормально, хотя не всегда, а
> если одну запись меняю, то совсем не сохраняет

Можно предположить вот что.

Когда меняется несколько записей, то идет навигация по датасету и автоматом посылается Post. Данные сохраняются (возможно, кроме последней записи).

Когда меняется одна запись, навигации нет и Post автоматом не посылается. Видимо, Post не посылается и кодом - вот данные и не сохраняются.

← →
korneley © (2008-06-24 10:07) [14]

> Юрий Зотов © (24.06.08 09:55) [13]

Присоединяюсь. Хотя, по идее, при нажатии "Enter" в гриде, Post должен быть и без навигации. Но кодом, с проверкой, что датасет в эдит/инсерт моде - надёжнее :)

← →
Ega23 © (2008-06-24 10:28) [15]

> Подскажите плиз. Есть грид, где отображаются данные,

Блин. Начал читать. Так порадовался - новичок наконец-то знает, что в гриде нет никаких данных.

> необходимо в грид вносить данные и чтобы они сохранялись.

Однако нет, всё в порядке. Мир, к сожалению, не изменился.

← →
korneley © (2008-06-24 10:42) [16]

> Ega23 © (24.06.08 10:28) [15]

Так это ж как... акыны, что ли. Что вижу, о том и пою. Если буковки/циферьки набираются в гриде, то и данные там же. А за всё остальное ответственный уже назначен: П.А.С. :))

← →
AlekseyB (2008-06-24 10:46) [17]

ну мало ли как выразился, ну ошибся, что теперь ? Не в этом проблема !!! Проблема в том, что данные не сохраняются в базе при внесении их в грид

← →
Ega23 © (2008-06-24 10:51) [18]

> Не в этом проблема !!! Проблема в том, что данные не сохраняются
> в базе при внесении их в грид

Проблема как раз в непонимании того, что в DBGrid нет никаких данных. Данные - в TDataSet. И вносишь ты их не в грид, а в ДатаСет. И для того, чтобы записи "появились" в базе, их нужно из датасета туда отправить. Как - это уже отдельная песня, есть много всяческих способов.

← →
Плохиш © (2008-06-24 10:53) [19]

> AlekseyB (24.06.08 10:46) [17]
> Проблема в том, что данные не сохраняются в базе при внесении
> их в грид

Хм, а у меня сохраняются, вот ведь как удивительно, правда...

← →
Галинка (2008-06-24 11:25) [20]

добавить либо кнопку типа "Update" (в которой и производить апдэйт с сохранением всех исправленных записей, там вроде у скула есть для этого спец модификатор типа rsEdited). Либо повесить это действие на Leave грида. Но UPDATE TABLE обязательно делать надо.

← →
lewka-serdceed (2008-06-24 13:45) [21]

Ты вообще используешь кнопки навигации по БД? Tnavigator попробуй

← →
Ega23 © (2008-06-24 13:50) [22]

> Ты вообще используешь кнопки навигации по БД? Tnavigator
> попробуй

Фу, какая гадость...

← →
korneley © (2008-06-24 14:02) [23]

Вот пользую EMS InterBase & FireBird Manager. Почти во всём нравится (может, потому, что слаще морковки ничего не пробовал :), но как я ненавижу эти УБОГИЕ DBNAVIGATOR - ы !!!

← →
Sergey13 © (2008-06-24 14:03) [24]

> [22] Ega23 © (24.06.08 13:50)

А чего его многие так не любят? Нормальный компонент. А для новичков так вообще очень даже хороший. ИМХО.

← →
korneley © (2008-06-24 14:07) [25]

> Sergey13 © (24.06.08 14:03) [24]

Не спорю, для D1, он может и был прорывом, но сейчас, я даже редактирование "данных в гриде" считаю "мове тон". Как следствие - "скрипач не нужен" (с)

← →
stas © (2008-06-24 14:13) [26]

AlekseyB (24.06.08 08:59)

1. СУБД
2. Компоненты доступа
3. Какие меняли настройки компонентов?

← →
Sergey13 © (2008-06-24 14:13) [27]

> [25] korneley © (24.06.08 14:07)
> я даже редактирование "данных в гриде" считаю "мове тон"

Чем же оно так плохо?

← →
korneley © (2008-06-24 14:23) [28]

> Sergey13 © (24.06.08 14:13) [27]

Тем, что считаю это наследием экселевского (или суперкальковского) подхода к интерфейсу. Там - да, в моём приложении - нет. Меняешь/вставляешь/удаляешь запись - получаешь форму. Пользователь хоть знает, что делает :) Ну ладно... иногда можно. :))) Но, иногда. Всё, естественно, имхо

← →
MsGuns © (2008-06-24 14:54) [29]

При "гридной" корректировке по умолчанию используется то механизм "отсылки" изменений на сервер, который используется применяемыми компонентами, с учетом тех свойств этих компонентов, которые влияют на кэширование изменений и на старт и подтверждение (откатов) транзакций. Вам, очевидно, следует или научиться управлять явно пересылкой изменений серверу или отказаться от "гридной" технологии или поменять датасет, например на TClientDataSet, у кторого целый арсенал методов и свойств для этого.
В любом случае надо потратить время чтобы разобраться и навсегда забыть о подобных проблемах

← →
Ega23 © (2008-06-24 15:11) [30]

> В любом случае надо потратить время чтобы разобраться и
> навсегда забыть о подобных проблемах

Проблема-то как раз в другом. Есть, например, справочная таблица. Всего с двумя десятками записей, но с 15 столбцами. Для корректного редактирования мне их ВСЕ 15 надо в грид тащщить. А по-идее, достаточно трёх-пяти, т.к. все остальные - сугубо служебные.

Ну и всяческие многопользовательские доступы - тоже с гридом тяжело решаются.
Наконец, это просто неудобно (назовите мне хоть одну программу того же Microsoft, где в гриде надо что-то редактировать. Ёксель не в счёт.)

← →
Sergey13 © (2008-06-24 15:17) [31]

> [30] Ega23 © (24.06.08 15:11)
> Наконец, это просто неудобно (назовите мне хоть одну программу
> того же Microsoft, где в гриде надо что-то редактировать

Редактирование структуры таблицы в ЕМ.

← →
Галинка (2008-06-24 15:18) [32]

Ega23 © (24.06.08 15:11) [30]

Все зависит от сути базы. И от сути таблицы конкретной.

← →
Sergey13 © (2008-06-24 15:24) [33]

> [30] Ega23 © (24.06.08 15:11)
> Для корректного редактирования мне их ВСЕ 15 надо в грид тащщить.
Это как? Если редактируются 3 - их и тащи. Плюс ПК в датасете.

← →
Ega23 © (2008-06-24 15:33) [34]

> Редактирование структуры таблицы в ЕМ.

Ну хорошо. Но насколько часто ты этим пользуешься? Я, например, раза 3-4 за 8 лет. Вообще EM использую для просмотра всякой фигни, типа DeadLocks и т.п., а также для настройки Backup|Restore и прочих джобов. Всё остальное - через QA.

> Это как? Если редактируются 3 - их и тащи. Плюс ПК в датасете.

Каждый раз новую форму создавать? Или что?
Потом, например проверки. Есть у тебя уникальный индекс на столбец. Понятно, что при вставке повторяющегося значения тебя обматерит. А где обматерит? На каком поле? Какое конкретное исключение ты будешь ловить?
А с формой - всё гораздо проще...

И понять редактирование в гриде я могу только в одном случае: когда сидит девочка на телефоне и принимает заказ на 100 товаров из 10000. Вот в такой ситуации - это удобно. Но геммороя при этом - ужас.

← →
Sergey13 © (2008-06-24 15:38) [35]

> [34] Ega23 © (24.06.08 15:33)
> Ну хорошо. Но насколько часто ты этим пользуешься?

Ты просил пример - я привел. Просто прямо перед ответом этим занимался. 8-)

> Каждый раз новую форму создавать? Или что?
А без грида все по другому? Как вообще ловля исключений пересекается с визуализацией данных? Я тебя наверное не понимаю.

← →
Галинка (2008-06-24 15:41) [36]

> Ega23 © (24.06.08 15:33) [34]
>
>
> И понять редактирование в гриде я могу только в одном случае:
> когда сидит девочка на телефоне и принимает заказ на 100
> товаров из 10000. Вот в такой ситуации - это удобно. Но
> геммороя при этом - ужас.
>

вот тут как раз грид совсем не оптимален. Потому как в базе будет несколько таблиц со связями многие ко многим (на вскидку будет справочников только штуки 3: тара, катугория товара, состояние склада). Как это все в грид загнать?

← →
Ega23 © (2008-06-24 15:44) [37]

> Как это все в грид загнать?

Это уже другой вопрос.

> А без грида все по другому? Как вообще ловля исключений
> пересекается с визуализацией данных? Я тебя наверное не
> понимаю.

Наверное. Это дело лучше в реале обсуждать, так запаримсо.

← →
Галинка (2008-06-24 15:45) [38]

хотя вот у нас например есть тулза для кассового окружения, в которой можно типа накладных создавать, которые потом уже на кассе оплачиваются. Написана кстати на дельфе ))) Там именно грид применен. Но там реально вводишь только наименование товара, вся остальная фигня берется из базы по связям.

← →
Sergey13 © (2008-06-24 16:02) [39]

> [37] Ega23 © (24.06.08 15:44)

ИМХО все-таки наверное не зря Борланд таскает свой грид из версии в версию. Да еще и сторонние разработчики соревнуются в написании своих гридов, причем очень даже недешевых порой. Да и в том же мелкомягком аксесе, если мне не изменяет память, грид так-же присутствует.
Применять/не применять - все зависит от задачи.

> Это дело лучше в реале обсуждать, так запаримсо.

Это точно. 8-)

← →
Галинка (2008-06-24 16:07) [40]

Sergey13 © (24.06.08 16:02) [39]

самое инетерсное, что не только борланд, но и мелкие тоже таскают. Но формы как-то конкретнее что ли. Незря же в том же аксесе мона формы свои дизайнить. Да и Oracle Forms.

← →
Sergey13 © (2008-06-24 16:27) [41]

> [40] Галинка (24.06.08 16:07)

Так табличное представление данных более всего соответствует табличным данным, которые собственно и лежат в реляционной БД.
ИМХО.

← →
Ega23 © (2008-06-24 16:29) [42]

> Так табличное представление данных более всего соответствует
> табличным данным, которые собственно и лежат в реляционной
> БД.

Только таблицы ещё имеют особенность связываться друг-с-другом...

← →
Галинка (2008-06-24 16:40) [43]

Sergey13 © (24.06.08 16:27) [41]

так базы потому и реляционные. Да и не всегда в таблице данные разаны явно. Пример все с теми же заказами. Получаем одну форму. А в ней данные клиента (Customer), данные заказа (Order), данные товара (Goods, GoodGroup), данные доставки (Schipping), данные доставщика (SchippingFirm). Таблица заказ будет как-бы главная (относительно), и большая часть полей в ней будет связана по ID с остальными таблицами. Для того и есть нормализация. Или? Как и зачем все это в грид один затащить?

← →
Галинка (2008-06-24 16:45) [44]

да и для оператора еще и состояние склада не плохо было бы. И сведения из внутренней таблички, заказали ли уже, если кончилось и когда оно поступит для отгрузки.

Собственно ИМХО для этого макросы в экселе и в акцесе и ввели. Потому что не все можно в таблице показать.

← →
Ega23 © (2008-06-24 16:47) [45]

> Галинка (24.06.08 16:45) [44]

Давай, дави его!
Мы с ним уже года 4 насчёт редактирования в гриде бодаемся. Если не все 5. :)))

← →
Sergey13 © (2008-06-24 16:48) [46]

> [42] Ega23 © (24.06.08 16:29)

Ну и что? Запрос на объединение этих данных имеет все равно вид плоской таблицы (почти всегда).

> [43] Галинка (24.06.08 16:40)
Никто и не предлагает редактировать ВСЮ БД в одном гриде. А вот какую нибудь конкретную накладную, данные для которой взяты с учетом указанных тобой связей - почему нет?

Я не призываю редактировать ТОЛЬКО в гриде. Я изначально высказал сомнение лишь в том, что такое редактирование следует огульно считать "мове тоном".

← →
Sergey13 © (2008-06-24 16:50) [47]

> [45] Ega23 © (24.06.08 16:47)

Эту песню не задушишь не убьешь, не убьешь, не убьешь! (с) пестня советских композиторов.
8-)

← →
Галинка (2008-06-24 16:52) [48]

Ega23 © (24.06.08 16:47) [45]

да меня тоже помню задавили ))) Просто за деревьями иногда леса не видно ))

ПыСы: сейчас вот внутреннюю доку сижу читаю. Крысота-то какая. У нас тут оказывается все древо классов построенно на основе базы, с которой те классы работают. Придумали какой-то тул, который на основе этой базы и классы генерит.

← →
MsGuns © (2008-06-24 16:54) [49]

>Sergey13 © (24.06.08 16:02) [39]
>ИМХО все-таки наверное не зря Борланд таскает свой грид из версии в версию. Да еще и сторонние разработчики соревнуются в написании своих гридов, причем очень даже недешевых порой.

Чисто маркетинговый ход. Без "сеточной" корректировки масса программистов откажутся от компонентов

>Да и в том же мелкомягком аксесе, если мне не изменяет память, грид так-же присутствует.

А ты пробовал менять в сетках запросные данные, вытащенные из нескольких таблиц ? Рекомендую попробовать и ты увидишь как мелкомягкие решают проблемы "универсальности" ;)

Я уже много раз повторял, что редактирование в сетке без ПОНИМАНИЯ механизма - штука очень опасная и вредная. Но кто услышит глас одинокого ?

← →
Sergey13 © (2008-06-24 17:00) [50]

> [49] MsGuns © (24.06.08 16:54)
> без ПОНИМАНИЯ

Без понимания и кирпич - оружие пролетариата. 8-)

← →
Галинка (2008-06-24 17:01) [51]

Sergey13 © (24.06.08 16:48) [46]

так в том то и дело, что это все содержит ОДНА КОНКРЕТНАЯ НАКЛАДНАЯ. Или можно выкинуть хоть что-то из нее?

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

Короче, забрели мы в темный лес. И опять холивар начался (((

← →
Галинка (2008-06-24 17:04) [52]

вобщем грид удобен больше для просмотра результатов, чем для редактирования.

← →
stas © (2008-06-24 17:10) [53]

Галинка (24.06.08 17:04) [52]

В некоторых случаях для редактирования тоже.
Я допустим где нужно делаю так:
в ADO включаю locktype в bathoptimistic.
Пользователь меняет в гриде данные, а на afterpost ado компонента
срабатывает сохранение данных с помощью хранимки.

← →
korneley © (2008-06-24 17:12) [54]

> Галинка (24.06.08 17:04) [52]

Дык, и я о том же. Грид удобен для визуализации, в первую очередь - "компактностью" - одна строка = одна сущность (блин, как Беренджер заговорил :) Но для редакции? Только если связей нет, иначе - форма. Да и оконечному юзеру есть шанс на внятные кнопочки посмотреть и о смысле набитого подумать :) И за нажатие "Ok" он уже не, "типа, отвечает", а "отвечает конкретно".

← →
Галинка (2008-06-24 17:22) [55]

stas © (24.06.08 17:10) [53]

ты наверное удивишься, но я в курсе. У меня даже в проекте как-то было редактирование в гриде. А в последнем было даже редактирование массива (спасибо Игорю, научил, как оно в дотнете пашет). Но для сохранения все же лучше отдельный орган управления поставить (причем с эффектом типа, пока данные не поменялись Enable:=false; если есть что сохранить, тогда активно. И для совсем клинического случая переж закрытием формы спросить для надежности, сохранять или как?). Тогда будет точно понятно, что уже отредактировано и сохранено.

← →
stas © (2008-06-24 17:31) [56]

Галинка (24.06.08 17:22) [55]

Ну это уже мелочи, главное сам факт редактирование в гриде

← →
Sergey13 © (2008-06-25 09:11) [57]

> [51] Галинка (24.06.08 17:01)

> так в том то и дело, что это все содержит ОДНА КОНКРЕТНАЯ НАКЛАДНАЯ.
Накладная - это сложный документ, который обычно состоит из шапочной и табличной частей. Что мешает редактировать табличную в гриде? При чем не всегда при этом затрагиваются поля связи. Например ввод каких нибудь продажных цен рядом с ценой поставки.

> Но промышленные базы такое позволяют редко.

Промышленная - это говорит скорее об объеме, нежели о сложности структуры. В одной и той же БД есть различные [под]задачи, разные по сложности структуры и по бизнес-методам.

> Если база нормирована, в ее таблицах не так много полей.

А "не так много" - это сколько? И как это влияет?

> Тогда грид будет скорее всего аггрегатным.
Это предположение, возможно основанное на личном опыте. Но опыт у всех разный.

> [54] korneley © (24.06.08 17:12)
> Да и оконечному юзеру есть шанс на внятные кнопочки посмотреть
> и о смысле набитого подумать :)

Грид и "внятные кнопочки" - это отнють не противопоставление.

← →
Галинка (2008-06-25 09:48) [58]

Sergey13 © (25.06.08 09:11) [57]

согласна... В споре таки родилась истина. )))

ПыСы: промышленная база - это нормированная база, а не рееств видеозаписей в домашней видеотеке. Как пример была приведена база каталожной фирмы (Customer, Orders, Order, Goods, GoodsGroup, Schiping, SchippingFirm, CreditNotes и т.д.) Там будет максимум до десяти (а скорее до восьми) полей на таблицу, причем бОльшая часть будет полями связи.

← →
Sergey13 © (2008-06-25 09:53) [59]

> [58] Галинка (25.06.08 09:48)
> ПыСы: промышленная база - это нормированная база

Все-таки наверное нормализованная, а не нормированная?

← →
Галинка (2008-06-25 09:54) [60]

точно... склероз...

← →
MsGuns © (2008-06-25 10:00) [61]

Встану на сторону тезки. Иногда сетка при редактировании не просто желательна - ОБЯЗАТЕЛЬНА. Например при массовых "вбитиях" данных - у нас вот сейчас вводят лицевые зарплаты за период с 91-го по 99 (Ленты ЕС-вские в свое время не позаботились скопировать на другие носители, козлы !). Миллионы документо-строк ! Как там без "сетки" и "Эксельной" технологии ?
Но я это реализовал клиентскими датасетами - и все на ура пляшет. А если б делал "как обычно" - получил бы тучу траблов

← →
Галинка (2008-06-25 10:13) [62]

MsGuns © (25.06.08 10:00) [61]

да ужжж... уменя тоже когда-то такое было, когда надо было рукописную "базу" оцифровать.

А если шрифт печатный, то нельзя ли сделать скан, а потом рапознать в txt хотя бы и импортировать? Хотя по трудозатратам тоже не фонтан ((

← →
Sergey13 © (2008-06-25 10:15) [63]

> [60] Галинка (25.06.08 09:54)

Ну так нормализация - это не цель и не показатель чего-либо. Это метод достижения непротиворечивости данных. Есть и прямо противоположный метод увеличения производительности - ДЕнормализация. Копромис этих методов обычно достигается исходя из разумной достаточности того и другого.

> Как пример была приведена база каталожной фирмы

А я вот сейчас глянул в нашу биллинговую базу (более 100000 абонов, более 1000000 соединений в день) и обнаружил там таблицы (не самые второстепенные) с количеством полей под 50. Это не промышленная база?

> MsGuns (25.06.2008 10:00:01) [61]

Ну массовый ввод это понятно, а сетка для чего.

> Sergey13 (25.06.2008 10:15:03) [63]

Количество полей не самоцель.

← →
Галинка (2008-06-25 11:23) [67]

Sergey13 © (25.06.08 10:15) [63]

интересно, их все надо постоянно видеть? Я серьезно спрашиваю. То что я пока видела, имеет такое количество полей в справочниках. Но они редактируются сравнительно редко. Просто интересно.

> [67] Галинка (25.06.08 11:23)
> интересно, их все надо постоянно видеть?

Постоянно никто их все и не смотрит. Этот пример я привел по поводу "промышленных БД". Типа разные они бывают.

>Anatoly Podgoretsky © (25.06.08 11:01) [64]
>Ну массовый ввод это понятно, а сетка для чего.

Как ты предложишь вводить лицевые зпл без сетки ?

> MsGuns (25.06.2008 16:04:09) [69]

Предлагаю вводить в форме.

> Предлагаю вводить в форме.

Отдельная модальная форма на редактирование сущности плоха только в одном единственном случае - скоростной ввод данных. Когда пользуешься только клавой, про мышку вообще забываешь, и т.п. Горячие клавиши - в конкретном данном случае вещь неудобная.

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

Другое дело, что я массу геморроев обрёл на Update-ах и т.п. Но это уже к делу не относится... :)

> Ega23 (25.06.2008 17:11:11) [71]

Отдельная модальная форма никак не мешает скоростному вводу данных, а при небольшой заточке может здорово ускорить, если сделать как в ДОС при заполнение поля автопереход на следующее поле и так по кругу. А если нужно видеть, что было ранее введено, то ниже на форме грид в режиме чтения, например для данных лицевых счетов.
Все выше описаное у нас есть в одной закупной программе. Ничто по скорости, кроме аналогичного ввода в ДОС не сравнится, и в тоже время наглядность.

← →
Галинка (2008-06-25 19:45) [73]

Ega23 © (25.06.08 17:11) [71]

а при чем горячие клавиши? TabIndex уже отменили? И это лишь самый простой способ.

Анатолий, а автопереход по нажатию на Enter? Очень интеерсный приемчик, надо где-то запомнить.

Если подумать, то грид - это всего лишь стоящие рядом TEdit"ы. Навигацию по форме можно сделать так же удобно, как и по гриду. А еще можно сделать типа автозаполнение полей. Может тоже поможет.

>Anatoly Podgoretsky © (25.06.08 17:25) [72]
>Отдельная модальная форма никак не мешает скоростному вводу данных

Мешает. Например удобно сначала ввести ВСЕ колонки месяц, год, вид оплат, а потом сверху вниз собственно суммы

> Галинка (25.06.2008 19:45:13) [73]

Имелся в вилу автопереход не по Enter, а по заполнению поля, например поля из четырех символов, после ввода четвертого символа автопереход на следующее поле, это из dBase/FoxPro (там это управляемое поведение). Автозаполнение по шаблону тоже имеется, а шаблоном является текущая запись, операторы это используют. В итоге в форме ввод быстрее и с меньшим процентом ошибок. По заполнению одной формы переход на заполнение следующей и так пока не будет отменено.
Формы часто имею следующий формат - вверху форма, внизу грид. На гриде можно перейти на изменение или удалить строку, а ввод/изменение в верхней части.
Сообственно этот формат у авторов последовательно мигрировал из ДОС (ФоксПро) в Windows (ФоксПро) и сейчас в Visual Basic (насколько я понял). Программа полностью покрывает потребности нашей фирмы по учету. В ней не было только отдела кадров, но эту часть я сам написал, благо в структуру все было заложено.

> MsGuns (25.06.2008 19:47:14) [74]

Особый случай, не типичный, и таких случаев можно привести много, доведя это до абсурда, но в этом случае конечно грид удобнее, но это часто мешают правила целостности, что это реализовать приходится делать отложенную запись, аналог Экселя.
В нашем случае эти колонки у нас заполняются автоматически, включая суммы, оператор делает только необходимые поправки.
Это точно такой же особый случай.
Но если вернуться к типовому способу, запись за записью, с проверкой и прочим, то я не вижу никаких ограничений сделать это в форме, для оператора гораздо удобнее и быстрее. Например автопереход, автозаполнение полей по шаблону и многое другое, было бы желание.

← →
Галинка (2008-06-25 20:14) [77]

Anatoly Podgoretsky © (25.06.08 20:07) [75]

ага. У нас на фирме примерно так же (программа для учета рабочего времени). Я теперь вспомнила. Т.е. вводишь дату. Она и так MaskEdit, так как только последнюю цифру ввел, курсор сам перескочил. А в гриде только видно, что уже ввел. Если где-то ошибка, то удалили и ввел заново.

MsGuns © (25.06.08 19:47) [74]

в реальной жизни таблицу читают строками. А вводить удобнее столбцами, именно потому что тот же эксель перескакивает по нажатию энтера не на след столбец, а на след строку. Просто операторы привыкли к "нечеловеческому" алгоритму.

← →
Галинка (2008-06-25 20:16) [78]

офф:

смотрю на наши обсуждения и в голове крутится "Психбольница в руках пациентов".

> а при чем горячие клавиши? TabIndex уже отменили? И это
> лишь самый простой способ.

А я не про перемещение в рамках модальной формы. TabOrder - это второе, что я делаю после выстраивания всех контролов.

Речь шла о том, что после редактирования конкретной записи нужно нажать ОК, посмотреть результат, выбрать в гриде следующую запись, даблкликнуть на ней и начать ввод данных.
Т.е. приходится время-от-времени переключаться на мышку. Что не всегда удобно.

> Галинка (25.06.2008 20:14:17) [77]

В Экселе переход управляемый.

> Ega23 (25.06.2008 20:21:19) [79]

Что то у тебя не то.
Нажатие на энтер открывает форму, никаких даблкликов не требуется, перемещение делается стрелками, закрытие или энтером или эскейпом.
Не вижу места для мышки.

Да и говорили мы в основном про добавление, а не про редактирование. При редактирование что в гриде, что в форме практически одинаковое количество нажатий. А при вводе можно резко уменьшить.

← →
Галинка (2008-06-26 09:53) [82]

Ega23 © (25.06.08 20:21) [79]

А AccessButtons не помогут в этом случае? Или в дельфи такого нет?

Или прописать общее событие OnKeyUp и на стрелки вниз/вверх повесить переход по строкам грида, а навигацию по остальным контролом выше приведенными способами. А на энтер соответственно нажатие "ОК" по умолчанию. Тогда мышку можно сэкономить.

> Или прописать общее событие OnKeyUp и на стрелки вниз/вверх
> повесить переход по строкам грида, а навигацию по остальным
> контролом выше приведенными способами. А на энтер соответственно
> нажатие "ОК" по умолчанию. Тогда мышку можно сэкономить.
>

Да всё можно сделать. Было бы желание, как грицца.
Ещё раз повторюсь - это был один единственный раз, когда я признал, что ввод в грид удобнее, чем в форму. Хотя с этим была масса чисто технических проблем: проверка корректности введённых данных, дурное добавление новой строки в рекордсет, когда доходил до последней строки и "вниз" жал и т.п.

← →
Галинка (2008-06-26 10:12) [84]

Перечитал ветку. Топикстартер тихо плачет в сторонке :))

>Anatoly Podgoretsky © (25.06.08 20:12) [76]
>Особый случай, не типичный, и таких случаев можно привести много, доведя это до абсурда, но в >этом случае конечно грид удобнее, но это часто мешают правила целостности, что это >реализовать приходится делать отложенную запись, аналог Экселя.

Безусловно. При проектировании интерфейса я исходил именно из Эксельной манеры, т.к. она позволяет максимально УСКОРИТЬ ввод для БОЛЬШИНСТВА пользователей, многие из которых имеют весьма слабые навыки работы в винде. Там еще масса наворотов с автозаполнением и автодополнением, переходы стрелками и ентером и т.д. И все - с единственной цеью - упрощения и ускорения.

Это приложение, конечно, скорее исключение, чем правило, но сколько же в нашей жизни таких исключений ;)

>korneley © (26.06.08 11:09) [85]
>Перечитал ветку. Топикстартер тихо плачет в сторонке :))

Думается, информация в ветке будет ему отнюдь не бесполезна.

> MsGuns (26.06.2008 11:47:26) [86]

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

← →
blazerad (2008-06-29 22:18) [88]

Удалено модератором
Примечание: Задай свой вопрос в отдельной ветке

← →
blazerad (2008-06-30 11:10) [89]

Удалено модератором
Примечание: Offtopic

← →
blazerad (2008-06-30 22:14) [90]

Удалено модератором
Примечание: Наверху есть форма - добавить свой вопрос

DBGrid Найти похожие ветки