Зробити нормальною ширину колонки у DBGRID
під час використання запитів типу select field1, sum(field2) . поля, де використовуються агрегатні функції неприємно виглядають у дбгриді (тобто розтягуються на величезну ширину.) як цього уникнути простіше?
Заздалегідь встановити які поля відображати і ширину кожного з них не підходить, тому що використовується багато різних селектів з різним набором полів.
Чи немає якогось нитка простого способу зробити так, щоб ДБгрід встановлював ширину колонок такою, яка потрібна для відображення даних незалежно від того, яку вибірку йому доведеться відображати?
проблема, як я зрозумів, полягає в тому, що у датасета в таких полях DisplayWidth=256
ну так зміни його після запиту (афтеропен).
. з Dataset do begin Close; CommandText:=SqlText; Parameters.ParamByName("bd").DataType:=ftDateTime; Parameters.ParamByName("ed").DataType:=ftDateTime; Parameters.ParamByName("bd").Value:=trunc(DTPbegin.DateTime); Parameters.ParamByName("ed").Value:=trunc(DTPEnd.DateTime); Open; для i:=0 до FieldCount-1 до if Fields[i].DisplayWidth=256 then fields[i].DisplayWidth:=15; end; .
І звичайно воно працює. Але.
Може я неправильна людина чи хз. Але досить часто, як і в даному випадку, я не можу позбутися відчуття ректальності мого коду.
поміняй провайдера даних тоді. цей у тебе неадекватний, на цифри такі розміри дає. розумію коли jet на рядки, що обчислюються (там реально можна не знати що за розмір буде у наступного обчислення, тому дається максимум), але числа це занадто.
Provider=OraOLEDB.Oracle.1 (рідний оракловий від 9і) і на що його поміняти? на Provider=MSDAORA.1 хіба що. Чи не впевнений, що це щось дасть? Хоча чесно не пробував.
У мене єякийсь невиразний спогад, що якщо у грида спочатку задати колонки і встановити ширину їх відмінну від дефолтної - то ширина стовпців вже залишається постійною. Може в цей бік подивитися?
CAST (expr AS VARCHAR2(потрібна ширина)) у запиті ?
> CAST (expr AS VARCHAR2(потрібна ширина)) у запиті ? він говорить у нього число - "sum(field2)", а не рядок.
розумію, можна і число привести до рядка, але хіба чисел буває така розмірність?
Не можу повірити, щоб числові поля мали за промовчанням ширину 256.
в тому то й справа. в аксесс є варіанти, навів ([4]) коли буває збільшений розмір рядків, ну там все зрозуміло, а якщо подібне у чисел. десь проблема/кривизна.
> в аксесс є варіанти, навів ([4])
і в oracle так само є
Та я не претендую на відсутність кривизни. Але справа в тому, що код там найпростіший, і я його привів. З того що не привів, так це те, що dataset:TADODataSet Але це і так ніби зрозуміло.
Є таке. Але в гриді не хочеться явно задавати колонки, бо в одному гриді відображаються різні вибірки, з різним числом полів та різними типами полів. Тобто. доведеться кожному за запиту задавати свої набори колонок для грида.
Завтра спробую так. Точніше подібним чином.
> Та я не претендую на відсутність кривизни. Тоді чому не виправиш? навіщо "залікування"?
> Але справа в тому, що код там найпростіший, і я його привів. не дає широких рядків. вірніше, я знаю, в аксесуар не дає (у mssql і обчислення рядків не дають, правильніше там довжини вважаються), Ігор говорить і оракл теж. Хоча я б на пробу поміняв провайдера, подивитися. мало, може в ньому справа, а Ігор користується іншим.
> Дуже злий (29.05.11 23:15) [13] & gt; Є таке. Але в гриді не хочеться явно задавати колонки, & gt; бо в одному гриді відображаються різні вибірки, з різним > числом полів та різними типами полів. Тобто. доведеться для > кожного запиту задавати свої набори колонок для грида..Я не знаю що за програму, але сильно підозрюю, що завтра користувач захоче налаштовувати ширини колонок "під себе як зручно" і щоб вони зберігалися між сеансами роботи програми. Є сенс заздалегідь це вже зробити і радіти :)
Ігор взагалі не користується провайдером. Через непотрібність.