Компоненты для Delphi-2

Вверх ↑

Форумы Новые пакетыКомпоненты для Delphi-2 ← Ctrl1 2 3 4 5...8 9 10 111213 14 15 16Ctrl →

Этот топик читают: Гость

Администрация

Ответов: 15295

Рейтинг: 1519

#166: 2007-07-06 18:00:26 ЛС | профиль | цитата

tsdima, в посте выше написал, почему не прокатит такая замена в общем случае:

Add(Button,976188,196,161)
{
 Left=195
 Top=160
 link(onClick,5076276:doValue,[])
}
Add(Memory,5076276,259,161)
{
 link(onData,12594926:doStrCat,[])
}
Add(StrCat,12594926,322,161)
{
 link(onStrCat,5597281:doMessage,[])
}
Add(Message,5597281,385,161)
{
 link(Message,5076276:Value,[(391,149)(368,149)(368,203)(265,203)])
}

положим св-во Extern у элемента стоит False. В примере выше все будет работать так, как ожидалось. Теперь делаем так:

Add(Button,976188,196,161)
{
 Left=195
 Top=160
 link(onClick,5076276:doValue,[])
}
Add(Button,7016436,196,231)
{
 Left=195
 Top=230
 link(onClick,3962627:doWork3,[(305,237)])
}
Add(Memory,5076276,259,161)
{
 link(onData,3962627:doWork2,[])
}
Add(StrCat,12594926,322,161)
{
 link(onStrCat,5597281:doMessage,[])
}
Add(Message,5597281,385,161)
{
 link(Message,5076276:Value,[(391,149)(368,149)(368,203)(265,203)])
}
Add(HubEx,3962627,301,154)
{
 link(onEvent,12594926:doStrCat,[])
}

если втупую на месте hubex поставить вызов ф-ции, то при компиляции получим сообщение о неизвестной переменной. Это хорошо еще, когда мы точно знаем с какого места переменная перестает быть видна. А если такие вызовы будут вставляться как попало?

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#167: 2007-07-06 18:03:50 ЛС | профиль | цитата

Dilma писал(а):

Этот код будет вставлем перед вызовом метода и ничего вроде бы криминального тут нет. Почему вызов btn15.width до фактического вызова метода не верен?

Ну как же нет

Это же криминал чистой воды

Делается чего-то, вызываются WinApi (к примеру), еще какая-нибудь ерунда, и все это не спрашивая разрешения у конкретного скрипа, конкретного элемента

Да может быть он (скрипт, по воле пользователя 1-го уровня) по своим внутренним соображениям (и что характерно - имеет полное право

) в данный конкретный момент захочет читать ТОЛЬКО Z
По результатам этого чтения изменить свои внутренние соображения (это же хоть и искусственный, но интеллект), и прочитать X или Y
А если не захочет (о чем CG не знает, и не узнает никогда - не разрешимы эти вещи в Design-Time)
Так и не должен никакой код исполняться, связанный с этими событиями

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#168: 2007-07-06 18:13:54 ЛС | профиль | цитата

Galkov, ну да, может быть не совсем оптимально с точки зрения производительности. Решается такая задача минимизированием числа элементов, использующих принты в var точках. Однако все равно не понимаю, что тут криминального. Под этим термином подразумеваю неверно работающую программу...

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#169: 2007-07-06 19:40:08 ЛС | профиль | цитата

Dilma писал(а):

Однако все равно не понимаю, что тут криминального

Вообще-то, такие действия - это создание другой программы.
А не той, которую нарисовал пользователь.

Просто слов не нахожу...
То же самое ведь относится к просто к последнему event-у в коде элемента. Просто никакой разницы.
Утверждать, что событие, которое должно выполнять ПОСЛЕ, можно выполнить ДО - это вообще уже за пределами добра и зла

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#170: 2007-07-06 20:55:45 ЛС | профиль | цитата

Ну задачи сделать графический компилятор программ пока нет. Как и нет у пользователя необходимости знать, какой код получается по его схеме => считать критичным такое поведение вероятно не стоит.

Galkov писал(а):

Утверждать, что событие, которое должно выполнять ПОСЛЕ, можно выполнить ДО - это вообще уже за пределами добра и зла

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

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#171: 2007-07-06 21:24:50 ЛС | профиль | цитата

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

Автор, сделавший именно такое добавление - ничего не понимает в концепции HiAsm

Даже готов согласиться - трудно понимать что-то в такой концепции, которая тут же рихтуется под мое "получается"
Если точнее - ее просто нет.
Чего можно обсуждать после этого - не понимаю.
Сразу так надо было и сказать - кучу времени сэкономили бы.

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#172: 2007-07-06 21:49:02 ЛС | профиль | цитата

Galkov писал(а):

Даже готов согласиться - трудно понимать что-то в такой концепции, которая тут же рихтуется под мое "получается"
Если точнее - ее просто нет.
Чего можно обсуждать после этого - не понимаю.
Сразу так надо было и сказать - кучу времени сэкономили бы.

вроде не раз уже было сказано, чего хотелось бы получить на данный момент... А в итоге почему-то все обсуждения сводятся к тому, что хотелось бы получить в идеале. Может тогда стоит приплюпусовать еще к этому желание nesco получить простой скрипт для каждого элемента из пары строк кода, желание Вячеслава получить готовую базу микро элементов и строить свои компоненты не залезая в код вообще, плюс двупроходность и все остальное такое прочее... Это и есть стандартная планировка того, "как надо". Только одно но: я так никогда не работал и не собираюсь. Дело у нас добровольное и каждый занимается тем, что ему нравится.

Кроме того, все интерффейсы доступны, они могут быть расширены в случае необходимости, примеры реализации различных CG и концепций пакетов так же есть - как говорится вперед и с песней.

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#173: 2007-07-06 22:16:50 ЛС | профиль | цитата

Dilma писал(а):

если автор элемента предполагает, что считывание данных со св-ва его компонента может привести к такому злу - пусть делать точку doXXX и никаких проблем не будет

Это не есть утверждение, что сегодня результат недостижим
Это утверждение - я не собираюсь его достигать.
Хотя бы по той причине, что варианты типа:

Galkov писал(а):

8) Собственно, иного варианта для такого случая, как формировать отдельные ф-ии, и подставлять в фактические параметры адреса этих ф-й (но никак не их вызовы) - я и не вижу...

Не обсуждаются де факто.

Что собственно сказано-то было: НЕ ВСЕ сделанное в Дельфи-1 есть бред. Что есть кодовые условия, когда именно такое пограммирование оптимально.
И что при наличии таких условий и нам следует делать аналогично.
В ответ на это: "если автор элемента предполагает, что ........... пусть делать точку doXXX"

Хотя о чем тут говорить, в принципе даже: функциональной замены программному приему с CallBack функциями не существует.
Они еще известны как события в KOL, или виртуальные ф-ии из таблиц vmt в VCL

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#174: 2007-07-06 22:41:20 ЛС | профиль | цитата

Galkov писал(а):

Это утверждение - я не собираюсь его достигать.

именно. Несколько не тем пока занят.

Galkov писал(а):

ну еще осталось подумать, как это представить в скрипте и можно от слов переходить к делу

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#175: 2007-07-07 19:10:28 ЛС | профиль | цитата

Dilma писал(а):

именно. Несколько не тем пока занят

Все дело в одном небольшом непроизнесенном слове.

Я не собираюсь этого достигать {сегодня|в принципе}

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

А меня значительно больше беспокоит, не останется ли св-во MultiElement.CodeType в окончательной версии.
Это решение по факту меняет идеологию, хотя и сделано было по принципу "что получается сегодня"

Да лучше оставить "дыру" в сегодняшнем функционировании, чем решаешь чего-то в ущерб концепции.

Св-во MultiElement.CodeType - это решение по пп.3-4, и никак не отменяет необходимости принимать решение function для линков мультика (методов элемента).
Св-во именно элемента если и должно, то уж определять принятие решения по пп.5-7
Хотя по логике - это может быть характеристика именно метода.

Все это здорово смахивает на создание линков "как получится" быстрее. Да, согласен, тогда именно так получилось быстрее.
И до сих пор у нас св-ва свойства залинкованы.
Даже если бы линки на мультики были сделаны на полгода/год позже, но без линкования св-в - правильный результат мы имели бы давно.
А сделали "как быстрее" - и сегодня нужных качеств мультика не имеем
А может, и сегодняшних проблем меньше было бы...

Вот, думается, что и сейчас так же случится

Почему

Да потому что получается, что главнее у нас, чтобы хоть как-то заработало.
А концепция - а вот что получится, то и концепция

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#176: 2007-07-07 22:27:24 ЛС | профиль | цитата

Galkov писал(а):

MultiElement.CodeType

что это?

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#177: 2007-07-09 00:21:41 ЛС | профиль | цитата

MultiElement.ini писал(а):

[Property]
CodeType=Inline - вставка кода непосредственно в текст программы, Function - вставка кода в отдельную функцию|4|0|Function,Inline

[size=-2]------ Добавлено в 00:21

Dilma писал(а):

GCC
С отстрипанными кусками выдает 6Кб на приложение, отображающе стандартное MessageBox. Достаточно неплохо.

Чего-то у меня более печальные наблюдения

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#178: 2007-07-09 01:19:08 ЛС | профиль | цитата

Опции командной строки? С пристегиванием supc++, без которой не работают операторы new и delete разница с проектами из-под Dlephi составляет 4кб в пользу последнего. Однако скорей всего размер можно уменьшить еще...

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#179: 2007-07-09 09:39:39 ЛС | профиль | цитата

Понятно, что для корректных сравнений нужно синхронизировать версии...

У меня пока найденный на халяву mingw 2.0.0
В ём:

GCC-3.2-core-20020817-1
binutils-2.13-20020903-1
mingw-runtime-2.2
w32api-2.0
gdb-5.1.1-1
make-3.79.1-20010722 (binary renamed as mingw32-make)

Так вот, если просто такой файлик компилировать

#include <windows.h>

int STDCALL
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
{
        MessageBox (NULL, "Test message", "Test", MB_OK);
        return 0;
}

Через

gcc -o hello.exe hello.c -Wl,-s,--subsystem,windows

То получаю размер 10752
Если попытать просто переименовать его в hello.cpp, начинаются затыки у линкера.
Действительно, помогает подключение библиотек ручками: либо supc++, либо stdc++
Для supc++ файлик становится сразу 50688

Без "затыков" срабатывает

g++ -o hello.exe hello.c -Wl,-s

Сам находит нужную либу, да и про целевой формат смекнул как-то

А вот попытка скомпилить такое (та же ком.строка)

#include <iostream.h>

int main (int argv, char** argc)
{
  cout<<"hello, world";
}

Так это вообще за пределами добра и зла

И что характерно, это я не Америку открыл, судя по ихнему FAQ-у
http://www.mingw.org/mingwfaq.shtml#faq-cpp-size
Словеса там умные и непонятные...

А если конкретно, то в примере make_mod.sha у меня получилась make_mod.dll размером 56832
Командной строкой

%mingw%ing++.exe -shared *.cpp -o make_mod.dll -Wl,-s

Хотя в том же пакете Modules эта же DLL-ка сделанная дельфёй (с KOL-овским PStrList-ом) - 18944

Вот такие у меня и наблюдения

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#180: 2007-07-09 10:27:31 ЛС | профиль | цитата

версия 3.4.2.
Командная строка:

"%fname%" share.o -mwindows -s -shared -lsupc++ -o "%oname%"

make_mod.sha собранный по этим параметрам: (23 040 байт)

[size=-2]------ Добавлено в 10:27
Galkov, есть подозрение, что вероятно имеет смысл сделать MultiElement частично встроенным. Т.е. CodeType=Inline вполне можно перенести для всех пакетов в среду.

карма: 27

https://hiasm.com

Форумы Новые пакетыКомпоненты для Delphi-2 ← Ctrl1 2 3 4 5...8 9 10 111213 14 15 16Ctrl →


Сообщение ...
Прикрепленные файлы (файлы не залиты)