Grid

← →
1C (2008-05-28 09:41) [0]

Как реализовать Grid как у 1С ? Есть ли примеры ?

← →
keymaster © (2008-05-28 10:41) [1]

1) а что в 1С-ном гриде особенного?
2) см. EhGrid
3) см. cxGrid

← →
DiamondShark © (2008-05-28 14:09) [2]

Удалено модератором

← →
tesseract © (2008-05-28 14:27) [3]

> а что в 1С-ном гриде особенного?

Похож на ЕГАИС чем-то :-)

← →
MsGuns © (2008-05-28 22:29) [4]

В 1С нет гридов. По крайней мере в типовой конфигурации.

← →
Petr V. Abramov © (2008-05-28 22:39) [5]

DevExpess

← →
Petr V. Abramov © (2008-05-28 22:41) [6]

> tesseract © (28.05.08 14:27) [3]

не видел ЕГАИС, но но у 1С грид клевый, тут надо тодать должное.
хоть их и нету :)

← →
MsGuns © (2008-05-28 22:47) [7]

"Грид" в 1С не клевый, а отстойный. Его якобы плюсы (поиск с "удобным" набором прям в самой колонке, сортировки "мышкой" и т.д.) во-первых, легко реализуются в той же Дельфи, во-вторых, оборачиваются минусами, особенно чувствительны программистам, поработавшим не только с этим уродцем (имеется в виду 1С)

← →
Ослик (2008-05-28 22:48) [8]

[4] MsGuns © (28.05.08 22:29)
Ты что-то путаешь.

← →
Ослик (2008-05-28 23:01) [9]

[7] MsGuns © (28.05.08 22:47)

> Его якобы плюсы (поиск с "удобным" набором прям в самой
> колонке, сортировки "мышкой" и т.д.)

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

> во-вторых, оборачиваются минусами

Какими именно минусами?

← →
MsGuns © (2008-05-28 23:04) [10]

Как я понял, под "гридом" тут понимают объект "Таблица" или "Справочник" или "Таблица значений" ? Если нет, то я не совсем в теме и снимаю свои замечания - в 1С я явно не спец. Так, балуюсь по нужде немного.

← →
Ослик (2008-05-28 23:35) [11]

Грид он и в 1с грид. :)
И таблица значений на форме, и журнал документов, и табличная часть документа, все это гриды.
Фишку с многострочностью проще всего увидеть в бухгалтерии в журнале проводок.

Но мне все-таки интересно было бы узнать про минусы сортировки кликом по заголовку и про поиск с набором в колонке.
Разумеется, я понимаю, что все это будет мягко говоря тормозить, если в источнике данных у грида мульен записей.
Но это извращение, на мой взгляд. :)
В грид должно падать не больше 1000 записей, а лучше не больше 100.

← →
PEAKTOP © (2008-05-29 00:10) [12]

> Грид он и в 1с грид

В 1С не грид, там извращенный объект MFC, аналогов в VCL ему нет, но по используемым API-функциями он все же ближе к TListView, чем к TCustomGrid и потомкам.

Реализуется это все на TDBGridEh - как два пальца. "Заготовок" в виде событий в нем как раз достаточно: OnTitleClick, OnKeyDown, OnButtonClick. Единственное, что неподвластно EhLib - это многострочные строки. Да и толку от них на практике никакого.

> MsGuns ©
Не надо так категорично про 1С. То, что система прежде всего файл-серверная - это факт с вытекающими. Можно селить ее на M$SQL, но толку-то, один фиг она данные на клиента тянет. Можно нововеяние в виде 1С8.0 селить на PostgreSQL, но через танцы с бубном и опять она будет данные на клиента тянуть.
А вот сама идея организации системы - очень даже ничего. Я для своей учетной системы очень много почерпнул из идей 1С, и как показала практика идеи у 1С были удачными.

← →
AndreyV © (2008-05-29 01:38) [13]

> [12] PEAKTOP © (29.05.08 00:10)
> Можно нововеяние в виде 1С8.0 селить на PostgreSQL, но через
> танцы с бубном и опять она будет данные на клиента тянуть.

Разве 1С8.0 с SQL сервером не 3-х звенка?
Одна и та-же конфигурация может работь или с файловым доступом или по 3-х звенной архитектуре.
В 3-х звенной часть процедур могут отрабатываться на сервере приложений. Вот из хелпа:

Если используется клиент–серверный вариант запуска системы 1С:Предприятие, то можно организовывать выполнение различных процедур и функций на сервере приложения или на клиентском месте.
Для выполнения на сервере:
#Если Сервер Тогда
…
#КонецЕсли
Для выполнения на клиентском месте:
#Если Клиент Тогда
…
#КонецЕсли

А обращение к базе на 1с диалекте SQL видимо как-то преобразуется на сервере приложений.
Вот выдрал первый попавшийся кусок из счёт фактуры:

Запрос.Текст = "ВЫБРАТЬ | Организация, ... | УслугаПоВознаграждению.НаименованиеПолное КАК ТоварНаименование, | Товары.( | СУММА(СуммаВознаграждения) КАК Сумма | ) |ИЗ | Документ.ОтчетКомитентуОПродажах КАК ОтчетКомитентуОПродажах | |ГДЕ | ОтчетКомитентуОПродажах.Ссылка = &ДокументОснование";
Или я что-то не правильно понимаю? Поправь тогда.

← →
PEAKTOP © (2008-05-29 04:00) [14]

> Или я что-то не правильно понимаю? Поправь тогда.

Да, запросы - это классно. Но их нельзя использовать всегда.

Когда проектируешь ИС предприятия, в некоторых объектах (документах, например) вводятся аттрибуты, являющиеся ссылками на другие объекты - справочники, журналы.

В конфигурации для небольшого предприятия данного механизма хватает "за глаза". Но в ERP-системах, где количество элементов справочника может достигать миллионов записей (конструкторский состав изделия в машиностроении), при выборе элемента справочника 1С "вытянет" этот справочник "на себя". Более того, она переберет все элементы справочника, чтобы "спозиционироваться".

Это, в свою очередь, заставляет ваять нестандартные формы выбора элемента. Но и здесь ЗАПРОС не спасает, т.к. интерпритатор запросов оптимизирует запрос так, как ему хочется, при этом не позволяя писать на чистом TSQL. Следствие - в БД появляются хранимые процедуры, которые "валятся" и первом же сохранении конфигурации, т.к. 1С именует таблицы и имена полей по какому-то странному принципу генерации имен "чтобы не совпало и бессмыслицы SC4814 пробольше".

Да и при отображении, например, детальной части этого документа 1С не выбирает строки документа с JOIN элементов справочника запросом, а перебирает справочник "в поисках". Считай сам дальше, что с ней на нескольких лимонах элементов справочника будет.

1С - прекрасный образец организации и продуманности клиента СУБД для учетных и ERP-систем, конструктор конфигураций хоть и кривой на всю голову, но зато идеологически продуман. Проблема 1С в том, что философия у нее файл-сервера. У многих моих знакомых 1С-цев была надежда, что в версии 8.Up они избавятся от этого бича, или хотя бы введут низкоуровневые функции для работы с SQL, но видимо - не судьба.

← →
AndreyV © (2008-05-29 05:10) [15]

> [14] PEAKTOP © (29.05.08 04:00)

Всё-таки философия осталась файл-серверная.
А про 3-х звенку что скажешь.

← →
Админ (2008-05-29 08:54) [16]

Ослик (28.05.08 23:35) [11]
Но мне все-таки интересно было бы узнать про минусы сортировки кликом по заголовку и про поиск с набором в колонке.

Нет никаких минусов, одни плюсы.

В DevExpess и то и другое есть.

← →
MsGuns © (2008-05-29 09:08) [17]

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

← →
Palladin © (2008-05-29 09:28) [18]

> В DevExpess и то и другое есть.

В DevExpress есть еще и очень очень многое другое. ИМХО, ни один грид с dx"совским и рядом не стоял...

← →
tesseract © (2008-05-29 10:06) [19]

> . У многих моих знакомых 1С-цев была надежда, что в версии
> 8.Up они избавятся от этого бича, или хотя бы введут низкоуровневые
> функции для работы с SQL, но видимо - не судьба.

1c++ или ADO и вперёд.

← →
Vlad Oshin © (2008-05-29 10:32) [20]

> DevExpress

Ща смотрю - вообще балдею
сколько писалось практически зазря (и криво местами, а местами сильно криво :))
разве что для практики 6)

← →
Vlad Oshin © (2008-05-29 10:32) [21]

Удалено модератором

← →
1C (2008-05-29 11:01) [23]

Конечно. www.devexpress.com

← →
Ослик (2008-05-29 11:33) [25]

[14] PEAKTOP © (29.05.08 04:00)
У меня одно уточнение.
Твой пост является ответом на [13], где идет речь о восьмерке.
Соответственно, ты писал его про восьмерку, а не про семерку, так?
Если так, то нижеследующая ругань написана по адресу.

> и здесь ЗАПРОС не спасает, т.к. интерпритатор запросов оптимизирует
> запрос так, как ему хочется, при этом не позволяя писать
> на чистом TSQL.

Запрос переводится в sql вполне предсказуемо. Именно для того, чтобы более менее однозначно запрос переводить в sql, язык запросов и сделали похожым на sql. Если же есть какие-то неястности по конкретному запросу - запускай sql профилер и смотри. Это же отностися и к ЕРП системам которые построены не на 1с а на любых других движках. Универсальное правило. Можно повесить на стенку.

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

Чтобы не быть голословным, можешь привести хоть один пример, когда SP "завалилась"?
А по поводу наименований - все понятно и логично еще со времен семерки. По буквам узнаем что это (справочник, документ, регистр, табличная часть и т.д.), а по цифрам надо смотреть словарь - конкретику - какой именно документ или справочник и т.д.

> Да и при отображении, например, детальной части этого документа
> 1С не выбирает строки документа с JOIN элементов справочника
> запросом, а перебирает справочник "в поисках". Считай сам
> дальше, что с ней на нескольких лимонах элементов справочника
> будет.

Ме вот интересно, ты хотябы раз sql профилер запускал, чтобы посмотреть, какие именно запросы уходят к базе, или чужие срашилки повторяешь?
То, что ты написал, чистое вранье.

> Но и здесь ЗАПРОС не спасает, т.к. интерпритатор запросов
> оптимизирует запрос так, как ему хочется, при этом не позволяя
> писать на чистом TSQL.

На больших базах в любых системах рано или поздно встает вопрос оптимизации запросов. Кое что можнол пытаться исправить на языке запросов 1с, перестраивая запрос по другому.
Если-же все-таки ест ь необходимость написать запрос вручную на sql, то такая возможность есть начиная с семерки: в 1С можно создавать ОЛЕ объекты, соответственно создаешь ADODB.Connection и вперед.

← →
Ослик (2008-05-29 11:47) [26]

> Да и при отображении, например, детальной части этого документа
> 1С не выбирает строки документа с JOIN элементов справочника
> запросом, а перебирает справочник "в поисках". Считай сам
> дальше, что с ней на нескольких лимонах элементов справочника
> будет.

Небольшое уточнение:
1. То, что он не делает джойн с табличной частью документа, чтобы наименование вытащить - ты прав, тут я погорячился, прошу прощения.
Но вот то, что он перебирает справочник в поисках - лажа. На сервер уходит запрос, который забирает конкретную запись по индексу.
К слову, nested loops джойн делает точно также - для каждой записи главной таблицы ищется по индексу запись в подчиненной.

Моя любимая сетка - DbAltGrid от Quasidata.
1C курит кеду.
И не нужно ставить какой-то сумасшедший пакет. Один-единственный компонент, простой в употреблении.

http://www.torry.net/authorsmore.php?id=2327

... а олени лутше

← →
atruhin1 (2008-05-29 12:11) [29]

> Моя любимая сетка - DbAltGrid от Quasidata.1C курит кеду.

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

← →
kaif (2008-05-29 16:13) [30]

2 atruhin1 (29.05.08 12:11) [29]

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

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

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

И что еще приятно, это российская разработка.

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