Delphi dbgrid сохранение параметров колонок

Как отследить сабж. В упор невижу нужное событие!

← →
Domkrat © ( 2004-05-30 13:58 ) [1]

← →
ertong ( 2004-05-30 14:03 ) [2]

>> Domkrat
Нет! onColumnMoved реагирует только на перемещение колонок 🙁

← →
Domkrat © ( 2004-05-30 14:35 ) [3]

Значит нет. Может попробовать сторонние компоненты типа QuantumGrid.

← →
Ertong © ( 2004-05-30 14:46 ) [4]

А есть хорошая бесплатная альтернатива ?

У меня так: DBGrid.ColumnResizing.False + проверка ширины системного ScrollBar + Form.Borderstyle.Single :).
Настраиваешь ширину при дизайне, на Form.Create проверяешь ширину ScrollBar, вносишь корректвы. Отлично работает.

← →
Ertong © ( 2004-05-30 14:59 ) [6]

to Vemer
Я так понял, что вы сделали изменение ширины колонок в соответсвии с размерами окна? А мне нужно что-бы пользователь сам сделал себе корективы и настройки сохранялись автоматически!

← →
Vlad © ( 2004-05-30 15:20 ) [7]

> Ertong © (30.05.04 14:59) [6]

> пользователь сам сделал себе корективы и настройки сохранялись
> автоматически!

Тогда зачем тебе вобще нужно такое событие ? Так получится, что если юзер будет сидеть баловаться, ресайзить колонки,то у тебя будет постоянно отрабатывать процедура сохранения настроек ? Нехорошо как-то.
Сохраняй настройки один раз, перед закрытем формы, к примеру.
Или дай юзеру кнопку: «сохранить настройки», пусть сам, когда ему надо, тогда и сохраняет.

← →
ertong ( 2004-05-30 18:24 ) [8]

> Сохраняй настройки один раз, перед закрытем формы, к примеру.
> Или дай юзеру кнопку: «сохранить настройки», пусть сам,
> когда ему надо, тогда и сохраняет.

Ну. Это дело вкуса. В практически всех программах, где есть перемещаемые тулбары, ИМХО сохранение идет сразу. Логично, что в моем случае это как раз было бы хорошо.

← →
Vlad © ( 2004-05-30 18:38 ) [9]

> ertong (30.05.04 18:24) [8]

> В практически всех программах, где есть перемещаемые тулбары,
> ИМХО сохранение идет сразу.

Есть доказательства ?
У меня есть большие сомнения по этому поводу. Потому как логика таких действий непонятна.
Зачем сохранять десятки или сотни раз при каждом перемещении, съедая кучу ресурсов у системы, если можно сохранить один раз в момент закрытия формы(OnClose). А результат получим один и тот же. Можете объяснить смысл ?

> Зачем сохранять десятки или сотни раз при каждом перемещении

Нет! Вы наверное не поняли! Я хочу сохранять только после окончания перемещения текущего елемента. Т.е. я делаю сохранение один раз за перемещение.

← →
Vlad © ( 2004-05-30 18:52 ) [11]

> ertong (30.05.04 18:42) [10]

Думаю, что все прекрасно понял.
Вот сижу я и настраиваю колонки грида по своему вкусу. Играюсь, так сказать. Перемещаю десять, двадцать раз, пока не получу желаемую мне картинку. И при каждом ресайзе вызывается процедура сохранения настроек, что замедляет работу программы. Зачем ?
Можете объяснить зачем это делать, если настройки достаточно сохранить ОДИН раз при закрытии формы ?

← →
Сергей Суровцев © ( 2004-05-30 23:01 ) [12]

>ertong (30.05.04 18:24) [8]
>Ну. Это дело вкуса. В практически всех программах, где есть
>перемещаемые тулбары, ИМХО сохранение идет сразу. Логично, что
>в моем случае это как раз было бы хорошо.

В любой нормальной это делается при закрытии формы либо по кнопке «сохранить настройки». Для -практически сразу- нет просто вообще никаких разумных аргументов.

Источник

Delphi dbgrid сохранение параметров колонок

Решил сделать форму с DBGrid-ом растягиваемой, следовательно надо и колонки разрешать растягивать.
Вот и натолкнулся ещё на одну проблему:
Если изменить размер колонки (хоть мышкой, хоть DBGrid1.Columns[0].Width := 100;), а потом
сделать
DBGrid1.DataSource.DataSet.Close;
DBGrid1.DataSource.DataSet.Open;
ширина колонки увеличивается примерно на 20 пикселей, причём не только у той, которой меняли ширину, а у всех в гриде.
В DataSet-е грида поля добавлены, если не добавлять, ширина сбрасывается на изначальную.

Возможно ли с этим бороться или грид просто не способен адекватно себя вести?

как пример для испытаний, можно взять всё тот же
http://delphimaster.net/view/3-1199805755/
[24], только надо добавить поля в Query.

← →
Плохиш © ( 2008-02-06 17:06 ) [1]

В OnBeforeClose сохрани размеры, а в OnAfterOpen установи их из сохранённых

← →
Desdechado © ( 2008-02-06 17:10 ) [2]

Сталкивался с такой фигней, если колонки то прятать, то снова показывать.
Бороть не стал, поменял логику.

← →
sniknik © ( 2008-02-06 17:22 ) [3]

> ширина колонки увеличивается примерно на 20 пикселей
не получилось. по тому же примеру (тип полей?)

но(!) вот это
DBGrid1.DataSource.DataSet.Close;
DBGrid1.DataSource.DataSet.Open;
неправильно. надо так
with DBGrid1.DataSource.DataSet do
begin
DisableControls;
try
Close;
Open;
finally
EnableControls;
end;
end;

← →
Prohodil Mimo © ( 2008-02-06 17:45 ) [4]

sniknik © (06.02.08 17:22) [3]
with DBGrid1.DataSource.DataSet do
begin
DisableControls;
try
Close;
Open;
finally
EnableControls;
end;
end;

Cделал наподобие, только в BeforeClose, AfterOpen — работает.
Спасибо.

sniknik © (06.02.08 17:22) [3]
не получилось. по тому же примеру (тип полей?)

а тип полей роли не играет.
Если интересно:
перед нажатием на кнопки надо ширину колонки изменить, потом кнопку жать.

← →
sniknik © ( 2008-02-06 17:52 ) [6]

> перед нажатием на кнопки надо ширину колонки изменить, потом кнопку жать.
так и делал.

← →
Prohodil Mimo © ( 2008-02-06 17:58 ) [7]

sniknik © (06.02.08 17:52) [6]

и ширина осталась как и до нажатия кнопки?

← →
sniknik © ( 2008-02-06 18:01 ) [8]

← →
Desdechado © ( 2008-02-06 18:04 ) [9]

Если бы вы еще договорились о версии Дельфи.
У меня в 7-ке плюкалась.

Desdechado © (06.02.08 18:04) [9]
Если бы вы еще договорились о версии Дельфи.

такое давно заметил ещё в 3, сейчас на 2005.

sniknik © (06.02.08 18:01) [8]
Если хочется посмотреть на глюк, могу скомпилировать пример и выложить в нете вместе с исходниками и FB Embedded.

← →
sniknik © ( 2008-02-06 19:45 ) [11]

давай, можно без FB, есть. (в той ветке писал)

Desdechado © (06.02.08 18:04) [9]
про версию тоже писал (D7), и то что у него 2005 оттуда же знаю.
хотя это и нехорошо, исходные данные должны быть здесь, но договорились о версии мы раньше.

← →
sniknik © ( 2008-02-06 19:46 ) [12]

> можно без FB
вместо нее лучше положи тестовую базу.

← →
MsGuns © ( 2008-02-06 22:28 ) [13]

Можно однако подкрутить TColumns.RebuildColumns

← →
Prohodil Mimo © ( 2008-02-06 23:33 ) [14]

sniknik © (06.02.08 19:46) [12]

выложил тут:
база, ехе, исходники (513Кb) http://ddsoftpro.lv/work/test_grid.zip
на всякий случай FB2_embedded (2.34Mb) http://ddsoftpro.lv/work/fb2_emb.zip

писал на скорую руку, а потому путь к базе на c:\test_grid

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

← →
Германн © ( 2008-02-07 01:00 ) [16]

> sniknik © (07.02.08 00:33) [15]
>
> а, понятно, в гриде то колонок у тебя и нет, а динамические
> пересоздаются. а я както «на автомате» туда в первую очередь
> вношу (русские названия колонкам дать). а в датасет необязательно.
>
>

А я как раз давеча впервые в жизни написал программульку, где русские названия колонкам даются в самом запросе через «AS». Это что, некошерно? Или какие-то проблемы могут возникнуть?

← →
sniknik © ( 2008-02-07 08:26 ) [17]

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

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

← →
Johnmen © ( 2008-02-07 09:24 ) [18]

> Германн © (07.02.08 01:00) [16]
> А я как раз давеча впервые в жизни написал программульку,
> где русские названия колонкам даются в самом запросе через
> «AS». Это что, некошерно? Или какие-то проблемы могут возникнуть?

Абсолютно некошерно. Фу. )
И проблемы м.б.

← →
Prohodil Mimo © ( 2008-02-07 12:24 ) [19]

sniknik © (07.02.08 0:33) [15]
в сам грид колонки никогда не добавляю, в самом начале программирования столкнулся с какими-то глюками из-за этого, с тех пор не использую.
Да и частенько использую один грид для отображения разных датасетов.

← →
sniknik © ( 2008-02-07 12:49 ) [20]

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

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

меняй мировоззрение. на самом деле это не «глюки изза этого», а изза тебя, изза того как ты это используешь, и соответствуют ли твои представления о нормальной работе реальности.

← →
Prohodil Mimo © ( 2008-02-07 13:55 ) [21]

sniknik © (07.02.08 12:49) [20]

> вернее не глюками, а просто не пониманием правильной в
> общем то работы

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

> а отключение контролов при изменении данных, не
> используешь тоже потому, что когдато «столкнулся с
> какими-то глюками»?

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

← →
Кристина ( 2008-05-22 21:17 ) [22]

Ребят, а я делала вот так: — высчитывала ширину колонок в процентном соотношении от ширини грида. Колонки разной ширины

procedure TfrmMain.FormResize(Sender: TObject);
begin
DBGrid1.Columns[0].Width:=round(0.05*DBGrid1.width);
DBGrid1.Columns[1].Width:=round(0.15*DBGrid1.width);
DBGrid1.Columns[2].Width:=round(0.2*DBGrid1.width);
DBGrid1.Columns[3].Width:=round(0.25*DBGrid1.width);
DBGrid1.Columns[4].Width:=round(0.1*DBGrid1.width);
DBGrid1.Columns[5].Width:=round(0.1*DBGrid1.width);
DBGrid1.Columns[6].Width:=round(0.1*DBGrid1.width);
end;

← →
MsGuns © ( 2008-05-23 00:15 ) [23]

Это плохой способ, ибо он абсолютно не учитывает специфику данных в полях. Сам компонент при автоматической разметке колонок (сразу после открытия связанного датасета) следует такому нехитрому алгоритму.

1) Определяется ширина текста заголовка колонки (назовем ее wt) — по умолчанию текст заголовка = названию поля датасета (TField.FieldName)
2) Определяется ширина текста данных колонки, вычисляемая из св-ва TField.Size, которое , в свою очередь, автоматически вычисляется датасетом сразу после открытия. (wf)
3) Ширина колонки = Max(wt,wf)

Это при условии отсутствия «ручных» настроек коллекций TFields и TColumns в дизайне или каким -либо другим образом в ран-тайме до открытия НД. При этом надо помнить, что для полей-стрингов, получаемых с алиасом либо вычисляемых, ширина определяется многими серверами с весьма солидным «запасом». Поэтому неизбежен эффект колонок во весь грид или около того.

Мне больше нравится способ настроек колонок грида, вынесенный в некую библиотечную процедуру, вычисляющую ширину колонок таким образом:
Для нестринговых полей ширина колонок остается неизменной, а для стрингов урезается до 200 (или сколько указано вх.параметром) пикселей.
Пользователю всегда проще расширить нужные колонки для требуемой вместимости, чем сужать их, манипулируя в основном гор.скроллом. А если еще и не поленится позаботиться о сохранении-восстановлении текущих параметров (TColumns.SaveToFile/LoadFromFile) после открытия и перед закрытием НД, то получим довольную мордочку милашки-оператора 😉

← →
Германн © ( 2008-05-23 01:26 ) [24]

> Johnmen © (07.02.08 09:24) [18]
>
>
> > Германн © (07.02.08 01:00) [16]
> > А я как раз давеча впервые в жизни написал программульку,
>
> > где русские названия колонкам даются в самом запросе через
> > «AS». Это что, некошерно? Или какие-то проблемы могут
> возникнуть?
>
> Абсолютно некошерно. Фу. )
> И проблемы м.б.
>

Раз уж кто-то поднял сей вопрос, то.
Жень! Чем это не кошерно? И какие проблемы «м.б.»?

← →
sniknik © ( 2008-05-23 02:05 ) [25]

> Чем это не кошерно? И какие проблемы «м.б.»?
прочитай [17].

> Германн © (23.05.08 01:26) [24]

Тут, если говорить образно, некошерность того же плана, что и именование классов. Ну там ТМойСуперКласс. Да, по-русски нельзя. Но это сегодня, и идеологически ничему не противоречит, вроде бы.
Я всего лишь провожу четкую грань между клиентской программой, где можно извращаться, как хочешь, и сервером, «придерживающимся» языка оригинала.
Вышесказанное — ИМХО. Никому не навязываю. Но если вдруг что — я предупреждал.
А проблемы будут, напр., при работе с IB/FB. Т.е. проблема одна — работать не будет вовсе :))

> Кристина (22.05.08 21:17) [22]

Некрофилия здесь не приветствуется. Если есть вопросы — новая ветка.

Мне больше нравится способ настроек колонок грида, вынесенный в некую библиотечную процедуру, вычисляющую ширину колонок таким образом:

Не надо ничего вычислять. Надо просто запоминать ширину выставленную пользователем. А заодно и индекс.

>Не надо ничего вычислять. Надо просто запоминать ширину выставленную >пользователем. А заодно и индекс.

Речь шла о ПЕРВИЧНОЙ настроке, когда приложение только установлено (переустановлено)

Первичная настройка и дизайне неплохо делается.

Речь шла о ПЕРВИЧНОЙ настроке, когда приложение только установлено (переустановлено)

А чем второй и последующие запуски отличаются от запуска сразу после установки если ничего не запоминаем?

Это если у меня заранее известен датасет. А если нет ? Например, при разработке какого-нибудь эксплорера БД. Заранее ничего неизвестно

>Reindeer Moss Eater © (23.05.08 11:43) [31]
>А чем второй и последующие запуски отличаются от запуска сразу после установки если ничего не запоминаем?

Если «ничего не запоминаем», то ничем, кроме одного — вместо десятиэкранной (по горизонтали) сетки, в которой за раз оботражается одно-два поля с океанами пустого места, получаем компактный вид с кре-гле обрезанной информацией — зато видим хотя бы список всех или почти всех колонок за раз.

Про «запоминание» в том посте тоже есть

Это если у меня заранее известен датасет. А если нет ?

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

Есть такой побочный эффект, поэтому в эксплоререх я и не сохраняю ничего. Обезьянничаю с того же мелкософта (QA).
А вот в клиентских приложениях, где массы сеток, предназначенных, как правило, для отображения одних и тех же датасетов, применяю вовсю. В дизайне лишь присваиваю филдам кэпшины (DisplayLabel) и выставляю форматы для дат и чисел, с размерами колонок вообще не вожусь. Ты знаешь, экономится масса времени 😉

у меня экономится не меньше, а даже больше.
русские названия колонок либо через дизайнтайм филды датасета, либо через колонки грида (если датасета на абстрактной форме нет)
а сохранение индеска и ширины колонок — опция самого грида (так же как и сама опция «сохранять». Это тоже опция грида )
Когда-то было как у тебя через библиотечные модули с именами xxx_common.pas, но потом надоело и перенес этот функционал в сам грид и многое другое тоже.

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

это решено было ещё в [3]

а сторонним я не пользуюсь, за исключением FIBPlus и FastReport (да и то не везде). Всё остальное своё.

> sniknik © (23.05.08 02:05) [25]

> Johnmen © (23.05.08 09:28) [26]

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

> sniknik © (07.02.08 00:33) [15]

Вот что самое смешное. В своих программах на BDE+Paradox я как раз всегда делал статические TxxxField компоненты через соответствующий редактор. А вот в первой же программе на ADO+FB почему-то «пошёл другим путём».

Источник