Alexbootch, от версии SQLite зависит, в версиях 3.3.x не поддерживается команда hex. Я проверяю на версии 3.4.2 obj. Перелови ошибку запроса при чтении картинок и ты увидешь, что за ошибка, скорее всего -- не поддерживается команда hex

Блин точно ведь... Все пойду спать, а то уже торможу

А у меня работает 3_5_9. Правда вместо
приходится применять
но меня устраивает, т.к. работает и с русским и с ивритом.

Tad, а в 3_4_2 это прокатывет, или нет 3_5_9 неплохо работает, но она большая и тормознутая, слегка

Да. Только что проверил. Без проблем.

Tad, может тогда заменим версию 3_3_4 на 3_4_2

Меняй.
Сколько пользуются OBJ

Не знаю сколько, но вещь хорошая
------------ Дoбавленo:

Preview последней версии таблицы. Показ в режиме TabGrid с внешними контролами



Последняя весия позволяет изменять ширину сторонних контролов в режиме редакции при изменении ширины колонки таблицы в RealTime

Наверное, я остановлюсь на том, что сделал, подшаманю код и выложу на попробовать. Чтобы сократить число компонентов пришлось пойти на объединение компонентов одного назначения в группы, по типу нашего Конвертора.

Решил сделать подарок всем к празднику и выложил законченную таблицу MTStrTbl. Есть два примера, можете их посмотреть. Лучше, конечно, поюзать тем, у кого полное обновление с SVN, чтобы вопросов было меньше.
Настоящая версия таблицы имеет полнофункциональный графический обработчик с широким набором функций отрисовки, чего в предыдущих версиях таблиц не было
------------ Дoбавленo:

Забыл добавить -- таблица построена по технологии менеджеров. Имеет один основной и два вспомогательных менеджера и пятнадцать клиентов, два из которых -- мультифункциональные по типу штатного Конвертора

1) поставил на форму MTStrTbl после чего 5 минут пытался понять по описанию какой элемент добавит в таблицу новую строку... так и не понял Получается, что эту роль выполняет MST_InitTxtTab в режиме Append - не логично как-то.
2) ок, сделал хотя бы такое добавление, вроде работает, но не понял куда улетает первый элемент
code_11917.txt

из замечаний:
вот так писать
не надо. Пояснения относительно значений аргументов вносить в справку (это касается не только данного элемента, но и всех остальных)

не уверен, что скрытие 1-2 event точек у элемента чем-то может быть оправдано

у MST_Matrix в качестве аргументов doMT_EMatrix указаны X и Y, а точек Data таких нет - почему?

еще не совсем ясна логика с EventManager - у самой таблицы эти события представлены в нативном виде + возможность подключения менеджера и у каждого клиента имеется такое поле, из которого преимущественно используется только onChange. Ну и в довершении ко всему у самого EventManager есть поле EventManager nesco, это специально сделано, чтобы господа Tad, и Вячеслав, имели полное право остерегать новичков от использования этого каламбура? В такой нотации в программе средней сложности проследить последовательсть вызовов всех однотипных событий будет нереально совершенно. Делать надо по другому: из всех клиентов убирать работу с событиями вообще. Их должен генерить основной элемент и никто более. onChange в такой интерпретации заменяется просто на имя метода с префиксом on.

и последнее: все клиенты должны иметь ответные события и аргументы ввиде data точек - иначе становится не понятно, а зачем вообще было метод выносить из основного элемента
было
стало

ну и префикс MT тут уже ни к чему становится

Мдаа... Уж. Но если ты не понял. Тут MST_InitTxtTab вообще мимо проходил. Есть специальные компоненты для работы со строками и столбцами


А MST_InitTxtTab нужен для инициализации внешним списком. Ну нет в этой таблице обычного метода добавления, как нет его и у тебя, в твоем кортежном дереве

Для обычного добавления можно использовать ArrayRows
------------ Дoбавленo:

Из выводов я понял, что

1. EventManager убрать за ненадобностью, чтобы не наводить страх на народ. Выполнимо
2. Добавить верхние точки и свойства по-умолчанию, там, ге это можно сделать. Выполнимо
3. Добавить ответные события у каждого возможного компонента. Выполнимо
4. Убрать все события из клиентов. Спорный вопрос, опять тащить связи от центрального элемента, а если надо в мультике отловить событие?
5. Убрать префикс MT. Выполнимо


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

вставил MST_RowAction - про события и данные я уже говорил...
Далее сразу же наткнулся на то, что для добавления строки ожидаются данные не в классическом формате (строка с разделением по Delimiter), а в МТ. Это безусловно проще и эффективнее, но присутствие двух форматов в рамках одной группы элементов несколько смущает и целесообразность этого(если таковая есть) должна быть обоснована.
------------ Дoбавленo:



nesco, примеры конкретные приводи. Я элементы эти впервые сегодня только увидел и не могу знать на 100% чего там можно сделать, а чего нельзя, поэтому и выражаю только предварительные положения.

Получается, что из модулей можно собрать и обычную таблицу и MT таблицу, возможно, стоит добавить компонент группы обычных методов работы со строками
------------ Дoбавленo:

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

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

По менеджеру отрисовки, есть какие-либо предложения
------------ Дoбавленo:


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

nesco, вообще-то с точки зрения хронологии у нас есть элементы, которые были сделаны до введения в обиход МТ и элементы, которые были созданы после. Поэтому правильнее говорить не "обычную таблицу и MT таблицу", а "старую таблицу и новую таблицу". От сплющивания нескольких параметров в один путем придумывания своих форматив надо отходить (до МТ таких форматов накопилось уже предостаточно - строки с разделителями, точки вида y*$FFFF + x, регионы типа TRect и т.д.) - все это удобно только до тех пор, пока не возникает желания один формат переделать в другой. В МТ таких проблем не будет никогда.

касательно таблицы можно отдельно сделать элементы экспорта и импорта где в числе прочих форматив будет и список строк с разделением по Delimiter. Но внутренние механизмы желательно проектировать с использованием более гибкой МТ
------------ Дoбавленo:


а onRowAction после doRowAction в режиме Add разве не является событием изменения строк в таблице? Судя по коду нет никаких причин к тому, чтобы после вызова метода Add у таблицы строка таки в нее не добавилась...

Есть такой компонент уже, и давно -- MT_String, нафиг там больше ничего не надо.

Со столбцами я специално сделал такой метод с делимитерами, так как с помощью него можно программировать размер колонок из базы, которая, кроме "_", ничего не понимает. Посмотри пример с базой, там это реализовано.


Кроме инициализации столбцов, все остальные методы сделаны MT, остальные в довесок
------------ Дoбавленo:


Главный метод находится в менеджере, он и может выставить это событие, а что делать с тем, кто его выставил
Так все же надо выставлять события на компонентах, или оставить это дело менеджеру
------------ Дoбавленo:

Так все же -- убрать все обычные методы и оставить только MT, даже в массивах, рассчитав доступ к ним на работу с новыми элементами MT, такими, как массивы MT И не получится ли это на порядок сложнее в понимании, чем то, что есть сейчас, ведь это потребует от пользователей немалых знаний, а они уже сейчас, на простых вещах, начинают выражать непонимание