[offtop]
И какие есть мысли по этому поводу У меня, на данный момент -- никаких[/offtop]

nesco, Ну, массив координат, размеров и имён у нас есть, равно как и координата клика. Естественно, учёт масштабирования картинки в экспериментальной версии можно сперва не реализовывать. Если бы это индийское действо было в sha, то пришлось бы перебирать все элементы. Кстати - пригодилась бы точка автоматического перебора (сейчас не переберёшь, не зная содержимого заранее), то есть что-то типа doEnum, выдающее элементы, а в идеале - MT поток со всеми их параметрами следом. Далее пришлось бы выяснять PointInRect попала ли мышка в этот прямоугольник. Раз уж есть перечисление, то удаление и добавление сам бог велел.

Примитивный вариант реализации идеи с одним элементом:

code_25510.txt

Хотел бы я посмотреть на решение "Реестр учётно-статистических карточек" в DocumentTemplate

А если сделаю, что мне за это будет

Дай посмотреть пример графической реализации данного проекта. А лучше вообще рабочий, тогда и подумать можно

nesco, <Delete> будь другом, скачаешь - удали прицеп. Не моё это.

А что это за компонент такой -- ArrayTextDoc
Остальные известны
------------ Дoбавленo в 11.45:
Да, уж -- это не программа, это ужас какой-то. Она мне форму полминуты в редакции выводит. Это ж сколько там контролов

nesco, оригинал

Tad, че-то я там модуль защиты не нашел. В падлу искать, пароль входа знаешь
------------ Дoбавленo в 12.18:
Забъем, нашел, как обойти.
У меня вопрос возник -- а нафига там прозрачность на Label нужна вообще

Редактировалось 3 раз(а), последний 2025-01-15 08:47:16

Да нате, жуйте. Кусок схемы на DocumentTemplate Все дело в желании.

doctempl_001.sha

Еще вопросы есть

Разве что скрывать элементы, ибо события попадают на элементы второй вкладки, если знать, куда ткнуть

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

При переключении страниц динамический массив полей очищаем и создаёмзаполняем новый, переходим к другому разделу хранилища данных.

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

А вот это не подходит
PC_Text, PC_Position, PC_Size
------------ Дoбавленo в 13.34:
То, что ты предлааешь реализовать довольно сложно, если вообще возможно, без существенной переделки среды

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

У самого шаблона иногда не хватает:
1. Загрузкисохранения шаблона изв файл (опционально)
2. Поискаперечисления объектов в шаблоне с выдачей как минимум их имён (в идеале - всех основных параметров в виде того же MT)
3. Динамического добавления и удаления объектов (опционально, если возможно)

А у его сателлитов не хватает параметров, например, не изменить формат шрифта в текстовых метках. Но это всё наживное, а вот перечисление довольно серьёзно пригодилось бы, без него не узнаешь, к какому имени объекта применить элементы управления.

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

На данный же момент чуть что не так с именем объекта (ну, ошибся ты в списке перечисления, скажем) - программа вылетает со всеми любимой Runtime error 216.
------------ Дoбавленo в 13.51:


Да ну, может ты не так меня понял. В чём проблема по очереди перечислить внутренности FChild.List

Динамически создавать поля в DocumentTemplate вряд ли получится, а вот управлять списком можно попытаться сделать. Попринципу вот такого построения строки управления -- <Name>|<Text>|<Left>|<Top>|<Width>|<Height>
------------ Дoбавленo в 13.52:

На данном этапе невозможно
------------ Дoбавленo в 13.53:

А это очень надо и зачем
------------ Дoбавленo в 13.55:

Из-за невозможности динамического создания, вряд ли получится.

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


В принципе, при установке защиты от дурака, можно обойтись без перебора, но это гораздо муторнее, чем при переборе сразу в потоке получить все основные параметры полей. Например, PointInRect на выходе уже позволит сделать интерактивный интерфейс без особых заморочек. На том же выходе динамические панели с различными элементами ввода - быстрое создание шаблона расстановки последних.

Ну и - тоже иногда не удобно. У таблиц CSS хотя бы есть.