Таблица с динамически меняющейся детализацией

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

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

0

TStringGrid позволяет это делать, в событии OnDrawCell можно рисовать что хочешь, а в свойстве Objects можно хранить любые данные для каждой ячейки.

Сообщение от Hrethgir Насколько много придется делать самому

Всё.

1

Про этот компонент я знаю давно, и пользовался даже на практике, а вот свойство Objects не использовал ещё ни разу, поэтому и тему в общем-то создал вероятно. Остальное по чуть делал. Надо делать, тяжело без прикладных инструментов с схемотехникой работать, даже схема не является её удобным представлением, как и стиль описания поведения и силь описания уравнениями Verilog. По мелочи можно использовать то что есть, но кому нужны мелочи ...

0

Сообщение от Hrethgir а вот свойство Objects не использовал ещё ни разу,

Вот эту тему посмотри.
Controls в ячейках StringGrid. Артефакты

0

Сообщение от Massaraksh7 TStringGrid позволяет это делать

На фиг тут StringGrid не сдался, замучаешься рисовать на нем. Проще надо быть: создал TFrame, который содержит все, что нужно (чекбокс какой-нибудь, чтобы отметку ставить, Shape, например, для отображения цвета, какие-нибудь нужные Label-ы, в общем, все, что нужно в данный момент), а на форму просто положил TFlowPanel, и в рантайме запихал на эту панель сколько нужно фреймов. И по имени фрейма (или по его абсолютной позиции в ControlList-е панели) можно обращаться к конкретному фрейму и работать с ним.

0

Сообщение от volvo На фиг тут StringGrid не сдался, замучаешься рисовать на нем.

Это кому что удобнее.

0

Удобнее - то, что делается проще. Сколько тебе придется написать, чтобы отобразить вот такую картинку в StringGrid-е:



?

А у меня это все - 10 строк кода. С учетом создания, изменения цвета по необходимости, и к тому же еще и вывод размеров "грида" в заголовок формы.

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

1

А почему бы не нормализовать базу данных?
Таблица ячейки, таблица данные ячеек.
Или:
Таблица ячейки, Таблица проперти_1, проперти_2, проперти_3... каждая своего типа и со ссылками на ячейку.

0

Спасибо за советы. У volvo, как всегда, лучший совет. Но всё равно всем спасибо. Ладненько, на этих выходных я проведу очередные тестбенчи всех логических элементов танги9к (на установку и на сброс), а заодно и своего сумматора и стандартного. И тогда станет ясно что именно нужно, но вообще кажется нужно будет или два режима одного приложения - в одном просматривать все характеристики логических элементов, примитивов и модулей, а во втором проводить анализ схемы, а так как приложение изначально думать не умеет - то на первой поре забивать много нудо будет руками - через чекбоксы или как-то ещё. В общем сначала хотя-бы аналог таблицы Менделеева сделать, а уже к ней где-то ниже прикручивать инфу об общей схеме, и уже интересующие узлы расчитывать или связи. Так как всё не протестируешь - не всегда это просто, и что-то определённо надо будет рассчитывать. Например скорость сбросов большей (ну или половины) части элементов просто так уже нельзя потестить - это слишком быстро чтобы сделать это ими одними - уже прийдётся встраивать в схему элементы, которые при сбросе тестируемых будут устанавливаться в 1, а скорость сброса соответственно высчитывать. И соответственно понятно, что это будет наблюдаться и дальше с любой схемой в той или иной мере.

0

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


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

Сам сумматор тут https://www.cyberforum.ru/blog... g8715.html
И у меня есть острое желение, если не оптимизировать его, то получить тул для подобных оптимизаций. Потому что сокращение пути достижения цели техническим средством - одна из главных задач, решаемых мной при его разработке. Точно так-же я и решил в сумматоре сократить логические цепи в сумматоре с нескольких элементов до одного на ответвлении, правда при этом я усложнил механику связей проводов за счёт электронных ключей. И этот тул, если его сделать - он мной будет испольщоваться очень часто, поскольку работы очень много предстоит ещё, сумматор - это только преддверие.

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

Для начала задача такая - отследить не продублировал ли я где провод по поведению в схеме. Это первый пример слежения. Хотя это вряд-ли что продублировал провод...но вполне может быть. То-есть создаётся массив проводов, иначе мне это как-то трудно представляется...все логические элементы - правила проводов, у каждого провода свой один элемент - и он же его правило, а электронные ключи и контакты - свойства, свойства намного сложнее правил. Фишка - программирование отслеживания образно схоже с правилами накладываемыми на провода...
Такая форма интерпритации мне не представляется тупиковой и в дальнейшем, думаю, её можно будет преобразовать. То-есть для тула нужен ещё свой язык программирования, который с одной стороны представляет собой схему на схемой - описываются связи отслеживаемых проводов или задаётся повдение провода для поиска этого поведения в схеме, и с другой стороны - контакты, поведение контактов входящих, это надо обязательно. О выходящих контактах в этом сообщении ничего нет, да и вообще пока внутри одного модуля - они не нужны.
Вопрос необходимости симулятора спорен - симуляция это поведение и может быть описано выражением, если это поведение внутри одного модуля. Симуляция для тула думаю - не нужна. А вот язык для этого выражения - нужен.

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

0

Имеется ввиду компонент IDE Lazarus

0

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

1

Реализовать я смогу и так - на FPGA или в симуляторе...хорошо, спасибо. Ну какой компонент можете посоветовать? Условия ТЗ неизменны - базовые логические элементы - правила, электронные ключи и провода - свойства. Нужна реализация интерфейса. Язык - разумеется тут простенький, если будет надо. Ну если что, прошу прощения, справлюсь сам.

0

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

Так и тут, только без файла вопросов. Каждый объект "логический элемент", "электронный ключ", "провод" и т.д. знает, что у него там внутри и что должно отображаться. Объект, который отображает, берёт из объекта (логический элемент, ключ, провод и т.д.) информацию, список, какие элементы нужно отобразить, Label, Memo, Image и т.д., и на каких координатах внутри своего окна (последнее не обязательно, наверное). Ну и сами данные тоже берёт из объекта и потом создаёт фрейм с нужными компонентами и отображает его.

Добавлено через 5 минут
Ну или объект содержит всю нужную информацию свёрстанную в HTML, а отображается это загрузкой в TWebbrowser.

1

AzAtom, спасибо за посильную помощь и любой вклад.

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

это очень интересно было-бы, взять готовое или наработку, и использовать в своих целях.
А вот тут

Сообщение от AzAtom Каждый объект "логический элемент", "электронный ключ", "провод" и т.д. знает, что у него там внутри

уже не совсем так. Главные объекты - это действительно провода, и они могут быть связаны друг с другом , но через правила - базовые логические элементы , например провод "выход" связан с проводами "вход1" и "вход2" через правило логического элемента И, сам логический элемент при этом совсем не нужен, дастачно знать правило (или его таблицу "истинности"), что если на проводе "вход1" и "вход2" подан сигнал единицы, то на проводе "выход" тоже будет единица. Это на самом деле решает очень много - логику и механику работы предполагаемой программы, и правила - это самое простое что можно придумать, всё гораздо сложнее с электронными ключами, их на провод может быть кинуто много выходов с других проводов. И под них лучше иметь особый тип данных. Про контакты я вообще зря рано речь завёл - пока рассматриваем провода без контактов. Я не знаю к чему отнести контакты : то-ли к правилам, то-ли к чему-то ещё...

0

Сообщение от Hrethgir провод "выход" связан с проводами "вход1" и "вход2" через правило логического элемента И, сам логический элемент при этом совсем не нужен, дастачно знать правило (или его таблицу "истинности"), что если на проводе "вход1" и "вход2" подан сигнал единицы,

Я такое впервые читаю. Провод - это провод, просто соединение между "выход" и "вход" элементов. Как понял, так и написал выше.

1

Сообщение от AzAtom Я такое впервые читаю. Провод - это провод, просто соединение между "выход" и "вход" элементов.

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

Сообщение от Hrethgir Главные объекты - это действительно провода, и они могут быть связаны друг с другом , но через правила - базовые логические элементы , например провод "выход" связан с проводами "вход1" и "вход2" через правило логического элемента И, сам логический элемент при этом совсем не нужен, дастачно знать правило (или его таблицу "истинности"), что если на проводе "вход1" и "вход2" подан сигнал единицы, то на проводе "выход" тоже будет единица.

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

0

Значит, компонент мне никто не посоветует, видимо. Ладно, отложу тогда работу над инструментом, на время.

0

Сообщение от Hrethgir компонент мне никто не посоветует, видимо

Есть EvsSimpleGraph, есть канва, на которой вообще что угодно можно рисовать. Что еще можно посоветовать?

1

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

0