Вверх ↑
Этот топик читают: Гость
Ответов: 590
Рейтинг: 19
#76: 2009-01-09 00:58:51 ЛС | профиль | цитата
nesco писал(а):
а приобритение знаний доступно всем, кому-то быстрее, кому-то дольше, но всем

nesco, +адын
хех... конечно не плохо было бы, если кто нибудь помогал переписывать компонент.. подсказки давал.. а бывает, что я задаю вроде простые вопросы и меня не понимают, да и задачи простые прошу помоч решить, а желание мало у кого возникает, хотя есть исключения... но всё же..
карма: 0

1
Голосовали:nesco
Администрация
Ответов: 15294
Рейтинг: 1518
#77: 2009-01-09 01:11:43 ЛС | профиль | цитата
nesco писал(а):
И программирование -- это скорее не искусство, а наука, а приобритение знаний доступно всем, кому-то быстрее, кому-то дольше, но всем

их бы в рамочку и на стенку

Ну а если по делу, то в словах
andrestudio писал(а):
насчёт больших проектов то меня окончательно убедили их не делать, так как новые версии HiAsm не любят схем своих предшествиников

есть к сожалению печальная доля правды... Стандартный пакет HiAsm это сегодня полигон для испытаний всего и вся, что видимо изменять без перехода на FTCG(или на иные подобные технологии) не получится никогда. Есть правда и иной вариант - заморозить пакет и вносить туда только правки, качающиеся ошибок в коде. Я не раз уже говорил, что истинно компонентный подход к реализации схемы в целевых кодах(что и делает кодогенератор стандартного пакета) это экстенсивный путь развития(наращивание численное и никогда качественное).

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

К чему это говорилось: несоответсвие в работе одного и того же элемента сегодня и завтра это неотъемлемая часть пакета, следуя которой нужно свой проект либо сопровождать той версией, в которой он был сделан, либо следить за изменениями и адаптировать его для новых сборок среды. Все достаточно просто....
карма: 26
0
Разработчик
Ответов: 26061
Рейтинг: 2120
#78: 2009-01-09 01:19:32 ЛС | профиль | цитата
EcsTasY писал(а):
если кто нибудь помогал переписывать компонент..

Ну, положим, про компонент я не припоминаю, что бы ты спрашивал, хотя, может про нестандартный пакет, но честно, не помню...
------------ Дoбавленo:

Dilma писал(а):
Есть правда и иной вариант - заморозить пакет и вносить туда только правки, качающиеся ошибок в коде

А почему бы и нет, хотя, может, пусть останется полигоном
карма: 22

0
Администрация
Ответов: 15294
Рейтинг: 1518
#79: 2009-01-09 01:20:16 ЛС | профиль | цитата
нашел одно из высказываний по этому поводу
Dilma писал(а):
пакету Delphi к сожалению судьбой предначертан экстенсивный путь развития(не смотря на все наши костыли, которые мы время от времени придумываем), и если над каждым своим дополнением 10 раз не подумать, он в итоге будет пораждать только громоздкие неповоротливые програмы и ничего более.
Напомню тот факт, что стандартная палитра сейчас по производительности в 2-3 раза меньше чем скрипт на Basic

с момента написания этого наверно уже можно прибавить еще одну единичку
------------ Дoбавленo:

nesco писал(а):
А почему бы и нет

nesco, мы же все прекрасно понимаем, что это не возможно...
карма: 26
0
Разработчик
Ответов: 26061
Рейтинг: 2120
#80: 2009-01-09 01:24:03 ЛС | профиль | цитата
Dilma, возникает один аспект -- все хотят иметь миимальные затраты на создание своего тврения, а составлять свои компоненты из микроэлементов, я тут таких мало видел.
------------ Дoбавленo:

Dilma писал(а):
мы же все прекрасно понимаем, что это не возможно...

Предвидя это, я и ответил
nesco писал(а):
может, пусть останется полигоном

карма: 22

0
Администрация
Ответов: 15294
Рейтинг: 1518
#81: 2009-01-09 01:29:23 ЛС | профиль | цитата
не смотря на все желание переделать пакет на потоковую кодогенерацию мысль о проделывание такой работы вызывает только тихий ужас и желание выключить компутер. Еще если вспомнить про патовую ситуацию с использованием в качестве целевого языка - Object Pascal, то начинаешь понимать, что идея эта почти фантастика.
------------ Дoбавленo:

nesco писал(а):
может, пусть останется полигоном

nesco, а не возникает ощущения, что чем больше копаешься в этой песочнице, тем тяжелее потом будет покидать ее? Представим себе пользователя, который пару лет работал в стандартном пакете и более менее разобрался хотя бы с тем, как добавить точку к элементу... И тут ему как обухом по голове объявляют, что пакет больше не поддерживается и что пора брать доки по FTCG и начинать разбираться с новым языком(хотя конечно не могу не заметить того, что в FTCG точку добавить в 10 раз проще, чем в Delphi)...
карма: 26
0
Ответов: 590
Рейтинг: 19
#82: 2009-01-09 01:31:02 ЛС | профиль | цитата
nesco писал(а):
Ну, положим, про компонент я не припоминаю, что бы ты спрашивал, хотя, может про нестандартный пакет, но честно, не помню...

Да ты прав, я не спрашивал про то, как переписать компонент. Просто я делаю выводы исходя из того, что даже мало кто помогает задачу решить, а уж изменить компонент тем более...
карма: 0

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#83: 2009-01-09 01:41:59 ЛС | профиль | цитата
Dilma писал(а):
И тут ему как обухом по голове объявляют, что пакет больше не поддерживается и что пора брать доки по FTCG и начинать разбираться с новым языком

Такие попытки уже были год назад, и я еще помню, кто про них говорил
карма: 22

0
Администрация
Ответов: 15294
Рейтинг: 1518
#84: 2009-01-09 01:52:22 ЛС | профиль | цитата
nesco, как раз после первых обсуждений, которые были год назад(времена Delphi2 если быть точнее) я задумался над альтернативами стандартного пакета. Так появился QT как первая тестовая версия широкого применения FTCG для серьезного программирования(пакет WEB это все же детский сад в некотором смысле...), после чего были получены такие выводы:
- FTCG применим для любых типов целевого языка с любыми системами сообщений, событий, делегатов и всего такого прочего.
- однако GCC + кросплатформенные библиотеки дают такие тормоза во время сборки, с которыми никто после Delphi мирится не станет.

Вот и получили патовую ситуацию... Хоть бери и под .NET переписывай все
карма: 26
0
Разработчик
Ответов: 26061
Рейтинг: 2120
#85: 2009-01-09 03:28:38 ЛС | профиль | цитата
Так, народ, а как вам такой автотрассерт связей (схема, чистый фонарь, на неё не смотреть)


карма: 22

0
файлы: 1tracert_001.png [5.9KB] [525]
Ответов: 2057
Рейтинг: 28
#86: 2009-01-09 03:40:50 ЛС | профиль | цитата
nesco писал(а):
Так, народ, а как вам такой автотрассерт связей (схема, чистый фонарь, на неё не смотреть)

Если ещё избавятся от диагональных линий, то самый раз, подходит.
карма: 1

0
Ответов: 590
Рейтинг: 19
#87: 2009-01-09 03:44:12 ЛС | профиль | цитата
да... с последним обновлением конечно жестко изменилась связь... и компоненты при копировании всё время выравнивать надо...
карма: 0

0
Разработчик
Ответов: 26061
Рейтинг: 2120
#88: 2009-01-09 03:46:59 ЛС | профиль | цитата
Эдик писал(а):
Если ещё избавятся от диагональных линий

Прикол именно в диагональных, как на печатных платах

EcsTasY писал(а):
и компоненты при копировании всё время выравнивать надо...

Что есть, то есть
карма: 22

0
Ответов: 590
Рейтинг: 19
#89: 2009-01-09 04:08:10 ЛС | профиль | цитата
nesco писал(а):
Что есть, то есть

Не спорю... но в 172 версии такого не было Чё уж там Dilma намудрил...
карма: 0

0
Ответов: 872
Рейтинг: 101
#90: 2009-01-09 04:10:06 ЛС | профиль | цитата
жаль нельзя изменить фон рабочий области. я бы сдела clBtnFace и сами бы компоненты сделал бы плоскими


карма: 1

0
файлы: 101.jpg [19.9KB] [531]
Сообщение
...
Прикрепленные файлы
(файлы не залиты)