ger_kar писал(а):Ну скорее всего в VBA работать не будет. Т.к. кирпич будет работать исключительно с VB и VB'шным рантаймом msvbvm60. VBA этот рантайм вообще не использует, со всеми вытекающими последствиями.
У VBA свой рантайм. Такой же.
grunger писал(а):мб kickstarter? я бы поучаствовал, если бы мог пользоваться *.bas в работе, т.е. если будет работать в Excel и проч. VBA.
Судя по всему, никому, кроме человек пяти это не нужно. Из них пожертвовать деньги готовы человек два. Я же открыл
кошельки для пожертвований. В первую неделю прислали около 500 рублей. И всё, больше никто ничего не слал.
В VBA многопоточность достижима с тем же успехом, что и в VB (поскольку оба продукта скомпилированы из одних и тех же исходников, только с разными ключами). Но первоначально многопоточность планируется только в VB.
Другая проблема состоит в том, что проект может не оправдать надежд многих людей. И это самый интересный момент, потому что он чисто субъективный. Потому что кирпич будет работать идеально. Просто многопоточность сама по себе сложна. Суровые сишники, пишущие многопоточные приложения, бывают, чуть-чуть тупанут где-то, и потом получают катастрофически непонятные раз-на-раз проявляющиеся глюки. С идеологией же разработки многопоточного кода на VB вообще никто не знаком. Что можно, а что нельзя — никто не знает. Я, вот, знаю, но даже у меня нет навыка написания именно на VB таких приложений, поэтому первое время даже я буду спотыкаться на своих же правилах.
Инструменты не дают всесильность. Люди получат в своё распоряжение кирпич, а дальше два варианта.
Они пишут код, и он у них намертво виснет. Люди кричат «кирпич дерьмо, ибо всё виснет». Но на деле люди просто словили
deadlock, а кирпич идеален и не виноват.
Или они пишут код, а он у них падает с типичным предложением «Отправить отчёт». И они кричат: «кирпич — говно, ибо всё падает». Но на деле у них потоки словили «race of condition» и переполнили свои стеки от внезапно возникшей рекурсии.
Пока всё было в одном потоке, для использования ООП людям не приходилось знать о COM-апартаментах и их типах (STA, MTA, NTA). Они не знали правила обращения с объектами в многопоточной среде. В частности, не знали, что каждый объект принадлежит своему COM-апартаменту (в случае VB — речь идёт об STA-апартаментах, поэтому фраза «апартамент» может быть заменена на «поток» без искажения смысла). И что нельзя ссылку на объект из одного апартамента передавать в другой просто так. Передадут они — бымс, всё упало. А надо делать межаппартаментный маршаллинг ссылок на объекты. Другими словами, хотим из потока А передать ссылку на какой-то объект в поток Б: нужно в потоке А ссылку преобразовать в особую сущность, передать эту сущность потоку Б, а поток Б должен из этой сущности получить обратно объектную ссылку. Это всё не чёрная магия, а общеизвестные правила COM, но кто-нибудь из чисто-VB-программистов их когда-нибудь читал?
Дальше, некоторые не догадываются, что заимей они в потоке Б ссылку на объект из потока А, и сделай вызов метода у того объекта, поток Б перенаправит вызов в поток А и заснёт до тех пор, пока вызов не завершится. То есть многопоточная программа превращается в обычную однопоточную на время вызова. Это просто благоприятнейшее поле для дедлоков. Поток Б вызывает какой-то метод объекта, принадлежащего потоку А. Поток Б засыпает и ждёт завершения работы метода в рамках потока А. А метод в рамках потока А ждёт какого-то результата, который по мнению потока А в это время должен сделать поток Б. Но поток Б-то спит.
В общем, тут надо будет думать. Сколько раз я в различных топиках отвечал: «кривая архитектура», «безумно кривая архитектура»? Люди, как я смотрю, и в однопоточной среде умудряются придумывать адовую дребедень. А здесь думать придётся ещё больше.
И кстати, накосячили люди и сообщают, что всё у них упало или зависло. Допустим, по их вине. Но я то тоже при таких сообщениях буду дёргаться. А в друг это тот случай, когда всё упало и зависло по моей вине? Это значит, на каждое сообщение о проблемах мне надобно отреагировать. В принципе, нормальная практика: разработчик реагирует на проблему, связанную с продуктом. Только здесь тот случай, когда 99 % проблем будут вызваны криворукостью пользователей, но это не отменяет 1 % проблем, вызванных моей кривобокостью
Может быть я сгущаю краски.
Может быть большинство будет запускать новый поток, делать в нём какие-то расчёте или вызывать InternetDownloadToFile, и на этом всё. Тогда всё будет у всех прекрасно, тут уж вроде негде выстрелить себе в ногу.
Как-то так.