Наш ответ №1

Значит так...
Долго пришлось разбираться, конечно.
Ошибся я - НЕТ интерфейсных заморочек для пользователя 2-го уровня
Имелся в виду примерно такой пример:
И поскольку напрямую его сотворить (уже сотворил) - это еще та повесть, приходилось теоретизировать. И ошибиться

Как:
Вижу в своих кодах в ReadValue приведение данных входного потока к типу св-ва точки
Вижу что при чтении с верхней точки это проигнорировано.
Понимаю, что это просто недоработка, а не глубокая задумка. Потому что пользователь 1-го уровня понятия не имеет из какого места пришли данные и должен точно знать какой у него тип.
Хорошо, делаю сам - привожу к типу св-ва, коль скоро таковое существует.
И думаю, что всенепременно случится приведение к типу Real (в вышестоящем примере), коль скоро св-во там установленно в Real
Вот именно в этом была моя ошибка - фиг там, тип данных оказался data_data
Из этой ошибки я и делал неправильный вывод о заморочках в интерфейсе пользователя 2-го уровня

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

Но, тем не менее, ситуации, когда пользователь (1-го уровня) код уже сформировал, через event-ы это еще прошло, и SubType=0 при этом - несколько подозрительны.
Источники потенциальных ошибок, вроде бы...
Надо бы, чтобы в этом случае _toCode не считал это константой, а SubType бы устанавливал категорически...
Тем более, вижу по кодам, что теперь моден другой признак константы: data_type in [data_code, data_array]
Вроде бы

Вот правда одно замечание: пользователь 1-го уровня получил возможность "автоматического" приведения типа. Но он сразу же получил возможность "неаккуратности" в синхронизации типов верхней точки и одноименного св-ва...
А может и отсутствие таковой возможности для особо хитрых типов...






[size=-2]------ Добавлено в 11:20
Наш ответ №2

Дык ты же все неправильно делаешь
Не имеет право CG вызывать самостоятельно event для метода.
Да, он (CG) знает каким образом для данного конкретного элемента будет определяться св-во X
Если оно вообще там потребуется.
А вот потребуется ли, и сколько раз (не факт и что один), и что перед этим будет сделано и в каком порядке (если такого безобразия несколько) - это ему знать не дано по определению

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

А пойдут ли эти коды в основное тело программы (алгоритмической ветки), или как тело некого метода объекта - это уже, в свою очередь, суверенное право CG.
Вроде - такой подход самый логичный.






[size=-2]------ Добавлено в 12:32
Наш ответ №3
Называется: "Мелкие технические детали"

вспомнились мелкие Дельфячие пакости с константными строками. Если сможешь "взнуздать" вышеприведенный примерчик - тоже вспомнишь Ну ладно, я радостно начинаю фиксить direct.inc

procedure tostr_delphi(var s:string);
var i:boolean;
begin
  i := length(s)=1;
  replace(s, '''', '''''');
  if i then s := s+'''+''';
end;

и обнаруживаю, что это все равно в код не попадает
Как проверил? Да просто попытался изменить св-во Message.Text="1'1"
Болт с гайкою...

Пока зафиксил так (заработало, по крайней мере):

function TScData.toCode;
....
    data_str: begin
      lngs[value.lang].tostr_proc(value.sdata);
      Result := lngs[value.lang].str_del + value.sdata + lngs[value.lang].str_del;
....

Но уверенности, что там где надо, и все - никакой. Шибко уж наворотил ты со своими конкатенациями

Надо бы как-то определиться с признаком "константы" для приведения именно константных типов в _toCode из direct.inc Как-то условие SubType=0 - подозрение вызывает... Выше отмечал...
"Определиться" - означает добавить эти константные приведения в direct.inc

Мне совершенно понятно стремление не передавать тип PStream из одной dll-ки в другую. И обеими руками - ЗА
Но я же теми же обеими руками ПРОТИВ делать GetMem в одной dll-ки, а в другой - FreeMem
Если эти dll-ки не сделаны под одним и тем же - так же как и с PStream, никаких гарантий.
Ну нельзя разносить конструктор и деструктор по разным кодам.
У себя-то я пока так сделал (make_exe.dpr ты ведь и не выложил ), без утечек и без "изничтожений" в make_exe

var ResText:string;
function buildProcessProc(var params:TBuildProcessRec):integer; cdecl;
...
   ResText := lst.Text;
   params.result := PChar(ResText);
   lst.free;
end;

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

  _var_^ := _toCode(_var_, ntype)^;[/code]
Такого же у нас - несть числа :(

[*][b]Dilma[/b], ну никогда я не замечал, чтобы тебе нравилась именно такая система отступов :shock:
procedure TSDK_0.btn3_onClick;
  begin
  s5 := '1 - Оппа: 1';
  MessageBox(frm2.Handle, PChar('1'+''), PChar(s5), MB_OK);
  end;
Поэтому у себя я таки изменил немного очередность действий:
   lng_begin:
    begin
      parser.Print('begin');
      parser.codeb.level := parser.codeb.level + 1;
      parser.PrintLine;
    end;
   lng_end:
    begin
      parser.codeb.level := parser.codeb.level - 1;
      parser.Print('end;');
      parser.PrintLine;
    end;