[Mrak]

Приветствую!

В проге данные заносятся из БД в StringGrid, кратко, это заявки для монтажников.
Сейчас вывожу заявку и краткую инфу по ней как строку.
Соответственно, если нужно ее открыть, то я разбираю эту строку, по номеру ищу заявку в БД, аналогично в событии OnDrawCell StringGrid'a рисуется цвет ячейки (в номере содержится идентификатор цвета). При внесении изменений все обновляется - задержка 2-3 сек (сервер удаленный)

Вобщем, хотелось бы усовершенствовать эту схему, кроме как ввести двумерные дин.массивы способа не вижу. но, возникает проблема, как хранить в нем и позицию в Grid'e и номер заявки? Да и потом, как я понимаю, нужно будет перебирать каждый раз этот массив, плюс массив не один... И есть ли смысл? например, будет ли увеличение скорости?

Вобщем вот картинка, интересно узнать как подобные механизмы реализуются

[Freeman]

Возможность перейти на DB-компоненты, с виртуальной таблицей вроде MemTableEh не рассматривал?

[Mrak]

Сообщение от Freeman

Возможность перейти на DB-компоненты, с виртуальной таблицей вроде MemTableEh не рассматривал?

погуглил) если правильно понял, memTable не удовлетворяет требованиям((

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

разве memTable с этим справится?

кто-нибудь решал подобные задачи? мне кажется это довольно распространенная модель?

[Freeman]

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

Первое, что нужно сделать, -- это перестать отталкиваться от StringGrid и начать мыслить в терминах задачи. Составление графиков и расписаний -- проработанная область, наверняка по ней можно что-то найти.

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

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

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

[Mrak]

Спасибо за ответ!

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

использую zColorStringGrid, мне нравится (http://avemey.com/zcolorstringgrid/z...hp#tmergecells)

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

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

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


Вот, например, есть идея уйти от привязки к содержимому ячейки (сейчас вся нужная инфа содержится в строке ячейки), так как лучше использовать номер не как набор цифр и букв-идентификаторов, а просто цифры - инкремент в БД, но тогда будет невозможно "говорить" гриду, чтоб он покрасил ту или иную ячейку в зависимости от вида работ. А сама идея - это использовать двумерные массивы, в которых позиции соответствуют позициям ячейки в StringGrid, а значение равно номеру заявки. Тогда можно будет выводить хоть пустую ячейку, но любого цвета - в OnDrawCell перебирать все строки и столбцы и, если они равны элементу в массиве, заливать другим цветом. Или это бред все?

На счет ООП, заполнение грида разбито на пару функций, заполняющих его. А вот редактирование, создание, чтение заявки думаю сделать с передачей параметров в другую форму, по типу как messageDlg. Но вот только та вторая форма не будет возвращать результат в первую, т.к. влияет непосредственно на данные в БД. При ее закрытии будет просто обновляться первая. Ведь я верно мыслю? Почему-то возникают трудности при разбитии "линейки" на объекты(

[Freeman]

Сообщение от Mrak

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

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

Из представленного тут описания мало что смог понять, сумбур какой-то. Опиши модель в БД и что требует грид.

[Страдалецъ]

Правильнее конечно перейти на полноценный компонент, как уже говорили ранее. Я предпочитаю cxGrid, но это существенная переделка кода. А вот если нет желания переделывать все под другой компонент, то можно расширить функционал стандартного стринггрида. Тут есть варианты. Можно свой класс сварганить над стрингридом, а можно просто с помощью стринглист сделать этакую невидимую таблицу с недостающими свойствами к каждой ячеке. А учитывая, его возможность хранить помимо строковой инфы, еще и адрес объекта можно наворотить такое, что и продвинутые компоненты не смогут.

[Freeman]

Сообщение от Страдалецъ

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

На самом деле, если стоит задача преобразования модели данных, правильней всего будет написать свой класс и хранить его в чем-то вроде TObjectList. Разработка класса-транслятора данных будет не в пример проще разработки визуального компонента.

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

[Mrak]

спасибо всем за ответы