Хотелось бы в компонентах типа

получать результат не только при вызове метода, но и просто при использовании нижней точки, без вызова метода. Это часто очень удобно.

согласен

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

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

p.s. подобные мысли о точках приходят от желания сократить к-во элементов на экране.

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

при каком же это проектировании появляются дополнительные переменные? Я подозреваю, что автор топика имел ввиду такое поведение(на примере StrCat)

никаких "дополнительных переменных, которые не всегда нужны, но занимают память" тут(и во всех прочих элементах) нет и быть не должно

А вообще-то я не так понял (че-то я стал невнимательным, нехорошо), действительно, такой метод получение результата очень бывает полезным, как reCalc в MathParse
Кстати, а почему это не пришло на ум никому раньше

Потому что никто не парился над этим, считал что "потом спрошу, сейчас некогда, а если не спрошу, то другие спросят... все верно" ИМХО
------------ Дoбавленo в 19.04:
А вообще много где пригодятся такие точки, и будет HiAsm - горизонтально-вертикальное программирование

Да оно и так есть, просто, на один элемент меньше

Да, а чтобы не повторять один и тот же код, например, в процедурах *._var_Result и *.doResult, делается private функция типа function *.GetResult(args...):resulttype и вызывается из *._var_Result и *.doResult, а на выход подается результат этой функции.

потому, что это затычка вытекающая из несовершенства технологии. В пакетах на базе FTCG для достижения того же самого результата не нужно клепать по две точки на свойство - решение о буферизации принимается еще на этапе сборки проекта. В стандартном же пакете создание дубликатов для нижних точек несмотря на удобство дальнейшего использования вносит "кривизну" в проектируемые схемы. Еще одним минусом такого "усовершенствования" будет отсутствие стандарта в поведении элементов - скажем если для StrCat можно сделать две точки Result и bufResult, то для какого-нибудь элемента WindowPosition придется создавать уже 4 - Left, Top, bufLeft и bufTop. Если этого не делать, то рано или поздно кто-то спросит, почему у StrCat есть точка bufXXX, а у WindowPosition нет? И мы снова вернемся в этот топик. И наконец последнее НО - при портировании элементов с такими точками в пакеты на базе FTCG возникает не простая делема - поддерживать в элементе точку, которая там совершенно не имеет смысла или нет ради совместимости при портировании схем?


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

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

Откуда можно сделать вывод -- оставляем пока все "как есть". Кому надо, тот прекрасно может использовать переадресатор потока EventFromData

есть еще вариант организации логики работы элементов аналогично пакетам FTCG через проверку Assigned(_var_XXX.event) (аналог в FTCG - linked(XXX)), но такое решение будучи самым оптимальным с точки зрения схемы и совместимости является самым не оптимальным с точки зрения эффективности получаемой программы.

nesco, я как-то про EventFromData позабыл, действительно, можно и так.