Tad писал(а):
Вот это считается оптимизацией ?Ты неправильно понял -- сделать сначала на Label, окончательный вариант перевести на DT, я же так и сделал
Разработчик
Ответов: 26305
Рейтинг: 2146
|
|||
Tad писал(а): Вот это считается оптимизацией ?Ты неправильно понял -- сделать сначала на Label, окончательный вариант перевести на DT, я же так и сделал |
|||
карма: 22 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
nesco писал(а): Ты неправильно понял -- сделать сначала на Label, окончательный вариант перевести на DT![]() ![]() ![]() ![]() |
|||
карма: 25 |
|
Разработчик
Ответов: 26305
Рейтинг: 2146
|
|||
Tad писал(а): Если я сделаю сначала на Label, то меня уже никто не заставит никуда переводить.Это уже твои проблемы. Но не надо свои проблемы категорически проецировать на других. Пути оптимизации есть, и пусть кто захочет, тот пусть для себя и делает. На данный момент делается попытка сделать программирование текстовых полей DT списком. Тогда список шаблона можно будет сохранять и считывать |
|||
карма: 22 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 2 раз(а), последний 2025-01-09 21:54:01 |
|||
карма: 0 |
|
Ответов: 5227
Рейтинг: 587
|
|||
Во бля, ещё и свеже зарегоного выкинуло, ну бля форум капитально глючит
![]() |
|||
карма: 4 |
|
Разработчик
Ответов: 26305
Рейтинг: 2146
|
|||
[offtop]
andrestudio писал(а): ну бля форум капитально глючит![]() |
|||
карма: 22 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 2 раз(а), последний 2025-01-09 21:54:01 |
|||
карма: 0 |
|
Гость
Ответов: 17029
Рейтинг: 0
|
|||
Редактировалось 2 раз(а), последний 2025-01-09 21:54:01 |
|||
карма: 0 |
|
Ответов: 3889
Рейтинг: 362
|
|||
nesco, я кое-что допилил и подклеил в базовом юните контроллеров печати, как только пройду тесты, выложу.
------------ Дoбавленo в 19.26: Наконец-то поумнели менеджеры печати и могут брать как объект (правда, пока взять-то его негде) сверху, так и текстовое имя компонента в текущем шаблоне, с которым необходимо работать. Для этого необходимо доработать PrintController.pas примерно так:
И сразу заработают интересные схемы типа:
nesco, это только у меня одного в ChildPanelEx не работает Align для вложенных элементов интерфейса? |
|||
карма: 1 |
|
Разработчик
Ответов: 26305
Рейтинг: 2146
|
|||
1nd1g0 писал(а): примерно такА если имени нет, что брать-то будет ![]() |
|||
карма: 22 |
|
Ответов: 3889
Рейтинг: 362
|
|||
nesco писал(а): А если имени нет, что брать-то будетЭто тест, доказавший работоспособность, потом, в финале, можно убрать объект нафиг и поставить один большой и толстый ReadString с несколькими источниками. Кому он сдался этот объект, которого никто в глаза не видел и взять его штатно негде ![]() ------------ Дoбавленo в 19.37: На совместимость никак не повлияет т.к. более нигде эта процедура юнита, кроме контроллеров печати, не задействована. Ради совместимости можно разве что имя Object оставить, всю остальную нестрочную логику с лёгкой совестью снести. ------------ Дoбавленo в 19.42: Кстати, если имени нет в поле, то теперешняя версия компонента вылетает с фатальной ошибкой, так что никаких отклонений от "штатного" поведения даже в такой поделке на скорую руку нет, сохранили, так сказать, совместимость ![]() |
|||
карма: 1 |
|
Разработчик
Ответов: 26305
Рейтинг: 2146
|
|||
Че-то я твою мысль пока не уловил. Доделывай, на готовом решении будет более понятно
|
|||
карма: 22 |
|
Ответов: 355
Рейтинг: 2
|
|||
Ого, как тема разошлась. А я уже давным-давно сделал то, что мне нужно было.
![]() |
|||
карма: 1 |
|
Разработчик
Ответов: 26305
Рейтинг: 2146
|
|||
nickware писал(а): Ого, как тема разошласьНу, дык -- пришли к выводу, что что-то у нас еще не допилено ![]() |
|||
карма: 22 |
|
Ответов: 3889
Рейтинг: 362
|
|||
Обработки ситуации с несуществующим объектом ни в одном компоненте на данный момент никем не реализовано, Нужно в каждой процедуре каждого "контроллера печати" (то есть простая правка их родителя тут не поможет) просто делать выход при FItem = nil. Это должно исправить заодно существующую на данный момент проблему фатальной ошибки при незаполненности или неправильном заполнении каких-либо полей в свойствах контроллеров. В таких случаях InitItem, (потому я его и начал править в первую очередь), не может выдать ничего вразумительного (что понятно - он не знает, что от него просят инициализировать) и выдаёт недействительную структуру FItem, при работе с которой сейчас (в штатных компонентах) вылетает фатальная ошибка. То есть исправлять компоненты контроллеров однозначно нужно. За одно в их родителя (а точнее - в PrintController.InitItem) добавить работу с пришедшими с верхней точки именами искомых объектов печати внутри шаблона. Полностью отказаться от _data_Object и от экземпляра TDocItem, на который эта точка была изначально расчитана, на данный момент не получается как раз из-за отсутствия правильной обработки не инициализированного объекта. Если статически, вручную прописанные объекты печати кое-как работали (хотя опечатка в одной букве приводит к фатальной ошибке во время работы приложения), то при динамической "подаче" их "сверху" в наши кубики крайне желательно предупредить грозящие фатальным вылетом ситуации ненахождения имени в списке печати.
|
|||
карма: 1 |
|