Давайте придумаем визуальный компонент.

← →
int64 (2002-07-17 13:55) [40]

Если ты уже настолько продвинулся в соих изысканиях и трудах и имеешь свой редактор, то сделай подобие Flash (в исходниках, а не ActiveX). У MacroMedia всё основано на мультимедиа, живой графике и встроенных скриптах. А у тебя будет то, что ты описал.

И ещё, чтоб все субконтролы (то, что будет лежать на твоей компоненте) имели место для отображения на палитре компонент. Или, на худой конец, в отдельных файлах.

Я бы такие коды взял на доработку, чтобы сделать плагин браузера для отображения информации из XML. Или, может, сам напишешь такой просмотрщик? :)

← →
avr555 (2002-07-17 15:44) [41]

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

← →
Praco (2002-07-17 15:58) [42]

"Praco © (16.07.02 18:02)
Вынужден тебя огорчить, большую часть уже написал."

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

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

Кажется то, что ты хочешь - это уже не компонент, а генератор отчетов или конструктор форм (как в Акцессе).

← →
Ш-К (2002-07-18 04:31) [43]

int64 © (17.07.02 13:55)
>плагин браузера для отображения информации из XML

avr555 © (17.07.02 15:44)
>набор контролов-примитивов и из них можно будет ваять интерфейс

Praco © (17.07.02 15:58)
>С возможностью выборки из базы?...
>...генератор отчетов или конструктор форм

Не собираюсь я воять монстров. То, о чём вы говорите - вторично. Это как раз те случаи, для которых компонент я и создаю.
Есть же единицы инфрмации, кторые для своего отображения не вписываются в таблицы, списки и деревья. Графы, например.
Пока мой компонент может отображать только тупые списки, каждый итем которого кропотливо вырисован по инфе, которую отображает. А инфа не просто стринги и иконки.
Вот пример инфы итема:

Count: integer; Caption: TCaption; Text: TStrings; BgPicture: TPicture; Icon: TIcon; ... Checed: Boolean; DragAndDrup: Boolean;

Для этой структуры я определяю алгоритм прорисивки. Он, кстати, и задаётся в редакторе. А хранится в формате, похожем на метафайл. Ну, ещё приписую обработчики. Например, при клике в определённое место создаётся TEdit; можно менять стринг; при потере фокуса или по ентер едит убивается, а стринг подставляется в итем.
И всё, - тип этого итема сохраняется отдельным объектом (на самом деле рекордом, но это детали). Теперь в своём компоненте я могу добавить сколь угодно таких итемов (бандов, как я назвал) и по вертикали, и по горизонтали, и один за другим со смещением...

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

Но это всё сделано для отображения списков или таблиц. И я на этом остановился.

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

Только сдаётся мне у программеров уже мозги искалечены - не могут представить, что их набор данных может лежать для отображения и редактирования не в ******** стандартных контролах.

>Все равно не понятно, чего нужно.

Нужны структуры отображения не стандартные. И не обязательно то, что вам надо. Просто идеи.

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

Ну и по самим итемам какие-нибудь соображения.

PS. Я же не спрашиваю как всё это написать. По-моему вопросы более чем обыкновенны и прозрачны.

← →
ZZ (2002-07-18 06:46) [44]

Count: integer; Caption: TCaption; Text: TStrings; BgPicture: TPicture; Icon: TIcon; ... Checed: Boolean; DragAndDrup: Boolean;

Какое гиганское разнообразие и TCaption и TStrings , и TPicture с TIcon. А вместо ... наверное TBitmap, TJpeg ??

ЗЫ. А что такое Checed и DragAndDrup я не очень понял ? (это же была выдержка из исходников????)

← →
Ш-К (2002-07-18 07:53) [45]

Каких ещё исходников! Просто набор полей. Первые, что в голову пришли.
Хотел показать, что пользователь сам может определять стуктуру.
Типа: Заголовок, под ним Текст, на обоях Картинка, в углу Пиктограмма и.т.д. Причём, рисоваться может и не в ректе, а как угодно. Ну, и всякие "служебные" поля, описывающие поведение (хот, перетаскивание мышью...)

У TListView, например, могут только стринги рисоваться. Плюс спецэфекты на OnDrawItem глючные. И всё.

ЗЫ. А подкавыривая тем, что разбираешься в азах устройства графических объектов, опускаешься до лаймера.

← →
ZZ (2002-07-18 09:04) [46]

Не буду опускаться до уровня лаймера...
Просто если я установлю компонент с свойствами Checed, DragAndDr up и другими ... в общем он не долго просуществует на моем винте :)))

PS. покажи скриншот этого чуда (а то представить тяжело)

← →
GenBr (2002-07-18 12:24) [47]

Ш-К

> Нужны структуры отображения не стандартные. И не обязательно
> то, что вам надо. Просто идеи.

А зачем вам нужна сразу же куча различных интерфейсов?
Вы ведь делаете для себя?
Если да, то делайте то что ВАМ нужно
Если нет, то я согласен с ZZ ©: вы выложите то, что вы уже сделали, и тогда разговор будет более предметным

← →
sergey32 (2002-07-18 12:39) [48]

Мне тут достался проект с собственными компонентами.
Хотелось бы взглянуть в глаза этим разработчикам.
Для начала, чтобы их установить (а их 6-8 штук)
надо поставить RX и еще несколько библиотек с
компонентами. Потом поставить эти компоненты (описания последовательности нет), а они друг за друга цепляются,
и когда я наконец-то (после 2-х дней установки)
запустил проект, то обнаружил, что самая крутая компонента
(модификация IP фильтра) иногда глючит.
Вопрос: Нах...я надо было это делать?

← →
avr555 (2002-07-18 18:39) [49]

> Не собираюсь я воять монстров. То, о чём вы говорите - вторично.
> Это как раз те случаи, для которых компонент я и создаю.
>
> Есть же единицы инфрмации, кторые для своего отображения
> не вписываются в таблицы, списки и деревья. Графы, например.
> Пока мой компонент может отображать только тупые списки,
> каждый итем которого кропотливо вырисован по инфе, которую
> отображает. А инфа не просто стринги и иконки.

Судя по описанию, у тебя сейчас получилось нечто похожее на VirtualTree ( http://www.delphi-gems.com/VirtualTreeview/VT.html). Там все построено также.

← →
Igorek (2002-07-19 00:38) [50]

2Ш-К
Мне это все больше начинает нравиться.

Мои предложения:
1) выбрать универсальный механизм хранения информации; мне кажеться что граф тут справиться с любой структурой - от списка и таблицы до произвольного дерева;

2) определить несколько типов структур, которые будут храниться:
а) массив N-ой размерности (N = 1 - список, 2 - таблица, 3 - куб и т.д.)
б) произвольное дерево (ациклический граф)
в) любой граф (в том числе и циклический)
г) другие типы структур (напр. шапка - набор полей - подвал (простой отчет))

3) для каждого типа структуры определить несколько вариантов отображения информации.
Например для таблицы:
а) таблица с сеткой - как StringGrid
б) набор строчек, где каждая строчка - склеенные значения ячеек в одном ряду в таблице
в) набор массивов строчек, каждый из которых состоит из значений ячеек в одном столбце; каждый масив показывать в отдельном ListBox"е
...

Одним словом по пункту 2 и особенно 3 есть простор для фантазии.

← →
Ш-К (2002-07-19 08:46) [51]

ZZ © (18.07.02 09:04)
Попытка номер три:
Пользователь может сам выбирать структуру единицы информации (руками в программе), а также составлять алгоритмы отображения (мышкой в редакторе). А какие поля он внесёт в структуру и с какими названиями, не е*** никого.

GenBr © (18.07.02 12:24)
>А зачем вам нужна сразу же куча различных интерфейсов?

Не нужна. И про интерфейсы, как таковые, я ничего не говорил. Я даю пользователю инструмент создания итемов. Имхо, уже досаточно. А давать возможность проектировать ещё и структуру взаимодействиё итемов, а равно и интерфейс этой структуры задача не стоит. По крайней мере, сергодня. Это очень громоздко и другой уровень. Вот и нужно определить и выбрать что-то обобщённое и список заранее спроектированных структр. Чтобы продолжать работать с оглядкой на этот список.

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

avr555 © (18.07.02 18:39)
>Судя по описанию, у тебя сейчас получилось нечто похожее на >VirtualTree

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

Igorek © (19.07.02 00:38)

Ну вот, хоть какие-то реальные предложения.

С первым пунктом согласен. Вроде бы очевиден, но я что-то об этом не подумал. :) Особенно лучше, если структуру графа спрятать от пользователя подальше. Т.е. не выкладывать на передний план, а то пугать будет.

По остальному подумаю и отвечу. Это похоже на дело.
Мои благодарности.

Давайте придумаем визуальный компонент. Найти похожие ветки