MessageBox(0, PChar('Text: Hello'), PChar(111), MB_OK);[/code]
[/quote]
А у меня при этом получается
MessageBox(frm2.Handle, PChar('Text: Hello'), PChar('111'), MB_OK);[/code]
В кодах при этом у меня
func doMessage(_data)
  println('MessageBox(', isset(WIN_PARENT) ? (WIN_PARENT + '.Handle') : '0', ', PChar(', Text, '), ', 'PChar(',e_str(Caption),'), MB_OK);')
  event(onMessage)
end
И не вижу я никакой проблемы в том, что автор элемента должен написать явное приведение типа.
В Дельфи-1 пишется именно явное приведение типа ReadString(_Data,_data_Caption), и как-то я не помню, чтобы именно это вызывало проблемы...

Более того, мне не кажется правильным приведение по типу св-ва:

....
    else if (prop <> -1)and((pt = 0) or fData._data_saved_.isEmpty or not cgt.elIsDefProp(el, prop) or (cgt.propGetType(cgt.elGetProperty(el, prop)) = data_comboEx)) then
      begin
       _var_ := readProperty(cgt, cgt.elGetProperty(el, prop));
      end
    else
     begin
      if (prop <> -1){and(fData._data_saved_.GetSubType <> data_null)} then
       begin //!!! ЭТО !!!
         ntype := cgt.propGetType(cgt.elGetProperty(el, prop));
         _var_^ := _toCode(@fData._data_saved_,ntype)^;
       end
....

Если бы было просто
         _var_^ := fData._data_saved_^;[/code]
То просто в коде пришлось бы писать
func doMessage(_data)
  println('MessageBox(', isset(WIN_PARENT) ? (WIN_PARENT + '.Handle') : '0', ', PChar(', e_str(Text), '), ', 'PChar(',e_str(Caption),'), MB_OK);')
  event(onMessage)
end
И меньше путаницы бы было у автора элемента.
Но главное - интерфейс совпадал бы с сегодняшним, и заморачивал бы пользователя...

Исхожу из логики: "никакие богатства мира не стоят слезы ребенка" (может быть слишком вольно, правда...)
Здесь: "ребенок" - это программист на [b]HiAsm[/b], "богатства мира" - возможность не писать явное приведение типа для автора элемента.
Если бы не было интерфейсных изменений ("слез ребенка"), то "богатства мира" были бы совершенно уместны. 
Иначе - нет, думается

Еще значительно более того: плохая эффективность кода - это слезы уже просто грудного ребенка, потребителя трудов программиста на [b]HiAsm[/b]
Против наших трудов (даже не автора элемента), по созданию компилятора.
Да ровно в тот момент, когда абсолютно понятно, как все должно работать - это простой кодинг, не программирование даже....

[quote=Dilma]обсуждать что-то еще в стиле "давай забьем на это все, запасемся терпением на пол годика и приступим к реализации многопроходности" - не хочу больше[/quote]
Никто и никогда был против изучения обходных путей, более простых за счет качества, эволюционных путей, и т.п..
О другом совсем речь.
[b]Чтобы эти поиски "не засыпали" основную трассу[/b]
Ровно в тот момент как произошли интерфейсные изменения - ДА, засыпаем
Как только поменялась концепция интерфейса (грубо говоря, она мне сегодня вообще непонятна) - ДА, засыпаем

Еще раз: плохо не то, что мы изучаем эволюционные варианты, а то, что мы не очень определились с конечной целью, и, поэтому, не очень думаем о том, перекрываем ли мы кислород этой цели своими действиями.

Пример ??? Пожалуйста
Вот нет у нас сегодня возможности сделать один код метода для множества элементов
Прекрасно - инлайн лучше всего, и все в порядке

Но если представить себе на секунду, что, хоть и потом, но это будет, тогда получается, что св-во элемента уже не есть константа в кодах. А переменная, с разными значениями для разных экземпляров.
Не считая случаев наличия методов do<Prop>
Ну и не очень пока я понимаю, впишется ли это с сегодняшнюю концепцию Единого Имени Свойства...

Пока подозреваю, что дорогу к конечной цели мы все-таки чуток "подзасыпали". 
[b]И вот именно в этом проблема.[/b]
А при супер-инлайн - да прекрасно все