CriDos:
Поскольку привилегия "Основного" пакета лишь в быстром создании проекта,
то может сделать просто "переключалку" между пакетами, и между типами результата
(exe,dll,console,...) по умолчанию?
Зачем ограничивать свободу юзеру без причины?
Если уж это программирование "скоростное":
наклацал быстренько несколько проектиков, проверил их поведение,
определился, и перешёл к основному...
Да мало ли где потребуется, "лишняя фича компа не грузит..."

CriDos, на мой взгляд тебе лучше поставить приоритеты - для кого ты делаешь альтернативную сборку HiAsm
Если в первую очередь для себя (и ты поставил для себя цель перейти на CNET), то ответ очевиден
А если для народа, то он(народ) в большинстве случаев консервативен и против всего нового ибо лучшее враг хорошему

я бы сказал иначе - он как enterprise сектор, выбирает только надёжное, а надёжной CNET пока не назвать даже из далека.
с ним у меня среда завалилась в эксепшене, когда я всего навсего пытался разобраться с тем, почему для регулярок там аж 4 компонента?
соответственно все наработки убились, да и пропало желание чтото ковырять дальше.

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

[offtop]О, попробую-ка я свой интерпретатор BrainF#ck-а в этом пакете замутить - типа для популяризации...
[/offtop]

Велосипед меня понёс
Понёс куда-то под откос
Он там остался без колёс
А дальше я его понёс

ну это так, лирическое отступление. Тема типа а не сколотить ли для начала гробик для пакета "Windows"

p.s а не рановато ли (собственно голосование по этому поводу )

Nic, у меня другой тип мышления, поэтому я находил баги в компонентах Window, по несколько штук в день, которые оставались незамеченными годами, одному багу было даже больше 9 лет! И это отнюдь не доставляло мне ни капли удовольствия.

Со временем я перестал делать попытки, написания схем свыше 1500 компонентов, потому как чем сложнее схема тем больше времени приходилось тратить на решение по вопросу стабильности. В первой схеме перевалив за 1700 компонентов, я уже почти перестал добавлять новый функционал, а только искал и искал нескончаемое количество багов и изобретал новые колёса для обхода то одного, то другого бага. Особое веселье началось при более менее серьёзном использовании сетевых компонентов.

Т.е., перевалив схему за 1500 компонентов, разработка замедляется в геометрической прогрессии. И чем больше компонентов тем медленней и медленней будет идти разработка.

Это и стало основным стимулом к изучению какого-либо языка программирования.

Но если у пакета Window, статус уже давно устаканился до уровня Stable, то CNET не смотря на внушительное количество компонентов, очень сильно проигрывает в качестве. Что конечно меня удивило, каким-то способом это отражается на среде, и вслед за криво написанным компонентом падает и сама среда. Соответственно и исчезают сами исходники схем, если не сохранился перед запуском.

Как я уже говорил о моём типе мышления, пакет CNET не продержался даже на сборке элементарной схемы из 7 компонентов. О чёмто более серьёзном можно не говорить, смысл в куче компонентов если они не стабильны?
Идти по проторенной дорожке делая пользователей beta-тестерами как было в window, зачем? Ещё вопрос, о плитке в графических компонентах не закрыт, кому будет интересно вытаскивать каждый раз точки 100% использования?

Задавайте вопросы по пакету в теме о пакете.

Редкая прога написанная на .NET прижилась у меня на машине.
На вскидку из огромного количества программ, комбайнов, редакторов и кучи различных утилит, на .НЕТ может с пяток наберется.
Многие кодеры считают НЕТ не очень хорошей штукой. Я, по своим соображениям, тоже присоединяюсь к ним.
Проголосовал за Win.

нет, потенциал у языка есть, но в текущем виде, он лишь добавляет геморроя на ровном месте(забудем о его стабильности).
у него нет никаких преимуществ даже перед текущей делфёй.
это если не брать во внимание то, что пользователю нужно искать 200 метровый фреймворк, а потом реально 15-30 минут ждать пока он при установке сделает около миллиона записей в реестр и захавает 700 метров места.

Конечно к слову на нём написан Vegas или dbForge Studio, но под HiAsm у него потенциал ровно такой же как и у делфи, а на деле пока и того меньше.
Да и логично, что переход Window>CNET маловероятен, по одной причине
[flood]Если бы это была таже Java, переход бы давал определённые преимущества, а так, никаких.

На C# можно делать сайты ? - нет
На C# можно писать на Flash ? - нет
На C# можно делать JS+HTML программы (GWT) которые могут общаться с любым сервером (написанным даже на HiAsm(Window)) ? - нет
На C# можно делать красивый интерфейс(JavaFX2) ? - нет
На С# можно писать на Objective-C ? - нет
На С# есть нормальный браузер ? - нет
C# приложение можно запустить под LinuxMac ? - нет (сомнения? Берём SONY Vegas и вперёд - запускайте на здоровье )[/flood]

hitman249, достал ты со своей жабой, честное слово. Раз так нравится - создай свой пакет, с Java и GWT, и перестань срать в остальных темах.
[flood] Сайты на Java - это полный п*ц конечно (как и сайты на Flash). Остальные пункты немерянно доставляют - какое отношение JS имеет к Java? А какое отношение Objective-C имеет к Java?
[вброс] Java - тормозное падучее говно.
[/вброс]
[/flood]

Кстати, начиная где-то с Windows XP SP3 (а уж в Vista и 7-ке - с самого начала) .NET Runtime ставится автоматом при установке винды, в отличие от этой Вашей жабы, которую каждый раз надо скачивать самому (а если вдруг понадобился компилятор - то снова качай; в .NET-е такого нет - компилятор тебе сразу в комплекте идёт).

Я считаю, что пакет C# надо развивать, и вести активную пропаганду перехода на него с Windows. Для этого - действительно - надо "русифицировать" пакет. А так как документация генерируется автоматически, то это не трудно. Можно - как вариант - сделать отдельный репозиторий с англоязычными ini, дабы - ежели появятся желающие - они могли бы его использовать вместо "штатного" русскоязычного.

И только после того, когда из .NET исключаться возможности неправильного подключения точек, выдающее кукчу ошибок в отладке, или, что еще того хуже, падение среды, за что меня в Windows уже давно бы съели. А ответ автора меня, помнится, убил -- пользователь должен знать, как правильно подключать и какие типы данных использовать, это вам не пакет Windows, в котором можно подключить что угодно и куда угодно (как-то так, дословно не помню). Этот пакет мне сильно напомнил FTCG_Tools в пакете Wundows, надо серьезно постучать в бубен, чтобы там что-то нормально заработало, стереотипы подключений точек пакета Windows рушаться тут же, а еще и радостные возгласы отладки в красном режиме добавляют колорит в общий процесс шаманства...

nesco, ну положим в пакете Windows тоже что угодно с чем угодно нельзя соединять. И если бы в пакете Windows возникало исключение (а не RuntimeError, и не тупое игнорирование) - это было бы чудесно,
так как исключения - это сигнал разработчику о том, что он что-то сделал не так.

Да ну Я, к примеру, спокойно могу подключить поток Streаm на точку Integer и ничего мне за это не будет, кроме получения значения 0.

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

Короче, дуракоустойчивость пакета Windows пока на порядки превосходит пакет .NET

   nesco, я об этом тоже хотел написать. Методы кодогенерации FTCG/RTCG делают пользователя зависимым от языка, на котором построен пакет. Пакет Windows построен на собственной технологии кодогенерации, где каждый компонент -- класс в коде, что может исключить большинство проблемм, характерных для FTCG/RTCG -- несовместимость типов точек, переменная X недоступна в блоке Y. Но в этом и есть своя "ложка дёгтя" -- а, именно то, что это всё сказывается на скорости работы программы, написаной в данном пакете. Уже много было тем на форуме, где говорилось об этом. Для этого был придуман компонент FTCG_Tools, который бы должен ускорить работу. Но не всё так "гладко". Опять же, методы кодогенерации FTCG/RTCG делают пользователя зависимым от языка, на котором построен пакет.
   Так что выбирайте - или "красное в отладке", которое будет характерным для пользователя, не читающего справку и не знающего языка, либо низкая скорость работы приложения.