Dilma писал(а):
До слов "Оппа" понятно дальше нет. Поэтому не могу ничего тут ответитьЗначит так...
Долго пришлось разбираться, конечно.
Ошибся я - НЕТ интерфейсных заморочек для пользователя 2-го уровня
Имелся в виду примерно такой пример:
Add(Button,11036070,210,49)
{
Left=100
Top=20
Caption="Hello"
Data=String(1)
link(onClick,7887576:doEvent,[])
}
Add(Message,3261178,392,126)
{
Text="1"
}
Add(StrCat,13333760,336,56)
{
Str1="1 - Оппа: "
}
Add(Hub,7887576,266,56)
{
link(onEvent1,13333760:doStrCat,[])
link(onEvent2,14835127:doEvent,[(317,69)(317,125)])
}
Add(IndexToChanel,14835127,336,119)
{
Data=Real(1.11)
Point(Data)
Point(Index)
link(onEvent2,3261178:doMessage,[])
link(Data,13333760:Result,[])
}
Как:
Вижу в своих кодах в 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
Dilma писал(а):
тоже не уловил смысла проблемы:
// где-то в коде программы вставлен функциональный вызов метода с данными из потока положим:
doMethod(s23 + s34);
...
// далее где-то в коде тот же метод со св-ом по умолчанию:
doMethod('test');
...
// и наконец тот же метод с данными с точки:
doMethod(res4);
// в скрипте FTCG стоит:
println('doMethod(', X, ');')
// метод реализован так:
procedure doMethod(X:string);
begin
...
Message(X);
...
end;Дык ты же все неправильно делаешь
Не имеет право 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;
....
"Определиться" - означает добавить эти константные приведения в direct.inc
Но я же теми же обеими руками ПРОТИВ делать 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;
Поиск
Друзья
Администрация