Дмитрий Ковальский: Для .docx под .NET есть аж 3 способа, первый - это библиотека docx.codeplex.com (к слову, аналогичная библиотека есть для Excel - npoi.codeplex.com/) второй - это взаимодействие с Office через COM (также поддерживает и .doc), третий - Open Office SDK (не пробовал; должно поддерживать и doc, и docx, и xls/xlsx при установленном Open Office, а может и без него).
Самое удобное и быстродействующее решение - это именно библиотеки типа NPOI, которые работают напрямую с документом без посредников.
Ясно, что .NET тоже далеко не идеален, но что вы можете предложить лучшее?
Скажем, для Delphi я в свое время таких библиотек, как NPOI, я вообще не нашел, только платные, а бесплатно - только COM (стандартно в VCL).
База осваивается и под юнькой, а справочное издание - это MSDN, а не какой-то писака, имеющий сомнительое отношение к разработке, best programmer вы наш.
ummahusla: основы (общие для всех платформ) - строки-массивы-списки-операторы, а тем более синтаксис - это как раз просто, это по большому счету вообще для всех языков и направлений общее. Поэтому изучить их можно на чем угодно. Но в любом случае это лишь очень малая часть того, что надо знать. И само по себе оно бесполезно. А вот все остальное - уже отличается кардинально, и требует изучения именно на Unity.
Вывод: во избежание лишних перескакиваний, можо сразу начать с Unity.
kstyle: если им нафиг не надо данную тему - то не вдохновит. Вот мне нафиг не надо было историю и обществознание. И никакой учитель бы не помог. А нравились те учителя, кто меня меньше мучал этими предметами и "двоек" с "тройками" меньше ставил. Благо, такие часто попадались.
Денис: > назвали JavaScript - потому, что тут тоже скобочки фигурные
Не поэтому, а потому что в те времена Java была самым высокоуровневым Си-подобным языком. Шарпа еще не было толком.
> Почему MS решила этот язык в своём IE внедрить, а не пилить свой
Почему же НЕ пилить? И внедрили, и свой напилили - VBS же.
Тогда вообще любили экспериментировать. Что-то получилось удачно, что-то нет.
MS - вообще особый случай: это великие стандартизаторы были ТОГДА.
Это сейчас всё вокруг уже не торт, что-то недавно, а что-то и давно.
> Как решили внедрять XmlHttpRequest?
Вполне логичное решение, ничего удивительного. Я бы тоже решил. Это далеко не первое в мире API для работы с HTTP. Такие API вместе с интернетом появились. Почему бы и в JS не внедрить?
Нынешние горе-разрабы может и побоялись бы, сейчас же паранойя в моде. А тогда было не так.
> Как стали возникать первые фреймворки?
См. мою статью.
Если совсем кратко, то сперва весь код последовательно лепили в один кусок спагетти, потом часто используемые кусочки стали re-use (сохранять в загашнике и повторно использовать, чтоб не писать каждый раз заново), потом додумались еще в функции их заворачивать для удобства.
> Почему стандартом стал jQuery
Потому что самый мощный и удобный, и долго развивался.
> в популярных в то время тестах на производительность он почти всем "сливал"
Популярных среди шизанутых старперов, какие и сейчас еще не все повымерли.
Реальные разработчики - ставили реальные цели.
> Ведь наверняка есть люди, которые через это всё прошли
Прошли через ЧТО? Через разработку Netscape и IE?)) Ну вряд ли эти люди сидят на Тостере и расскажут вам что-то. Ищите уж тогда на stackoverflow, там хоть языкового барьера нету...
Денис:
> зачем минусовать
Спросите вот у этих двух поциентов, чего они меня на майле ру в комментах обсирают и чего они всякую "йухню" (их же словечками) про ООП и фреймворки несут: https://otvet.mail.ru/answer/1798473317/cid-218510480/
П
История интересна либо студентам (тупо для курсачей), либо серьезным программистам - архитекторам (в смысле Architect), специалистам по средствам разработки (тем, кто сам пишет фреймворки, IDE и пр.)...
Архитектор - это как в строительстве: тот, которому заказчик говорит "забацай мне кароче дачу, шоб все по-пацански было", а он уже проектирует здание, делает чертежи, 3D-модели, показывает их заказчику, уточняет детали и т.д.
Большинство же "программистов" - тупо кодеры: ему говорят, сделай такой-то сайт, и чтоб там jQuery и Angular был - и он делает, вообще не задумываясь, над тем, а надо ли оно, куда оно туд и т.д.
Ну а кто обсирает все подряд, это просто всякие ФГМнутые дилетанты.
Кто-то бредит low-level'ом, кто-то линуксом, кто-то консолью и не признает никакого GUI... Кто-то выучит 1-2-5 языков, больше ни на что мозгов не хватает, вот он люто-бешено и срётся в комментах, доказывая преимущество молотка над отверткой в области монтажа саморезов...
В Atom и VS Code, возможно, дело было отчасти в том, что именно те алгоритмы, в которых было автодополнение, подсветка синтаксиса для HTML, CSS, JS (и прочие основные возможности любой IDE), - именно те алгоритмы были только на JS (или готовые контролы для этого были на HTML+CSS+JS). А так как - еще раз - это основа любой IDE, то ничего удивительного.
Ну и да, VS Code и Atom - в основном рассчитаны на Web-разработчиков, среди которых есть и линуксоиды и маководы, и немало, поэтому в данном случае имеет хоть какой-то смысл кроссплатформенность - которая в иных случаях не дает ничего, кроме затруднения разработки и падения ее качества.
> те, кто кроме html+js стека ничего не знает, а декстопа тоже хочется ("мы же тоже люди").
Бывает, когда закоренелые веб-разработчики берутся за десктоп и прут в чужой монастырь со своим уставом, не желая чужой устав изучить.
Яркий пример - Google с его API под .NET. Их Google API - это просто какие-то 50 оттенков избыточной архитектуры библиотек (или даже не знаю, как назвать, когда вместо 1 вызова метода с 2 аргументами приходится лепить 10 вызовов и в каждом по 5 аргументов).
НО Google вообще отличается избыточностью и неудобной архитектурой, не только на десктопе. Так что "дело не в бабине".
А надо ли так делать? Не лучше ли сделать не просто отдельный обработчик, а удобное, стройное RESTful API, полностью развязанное от фронт-енда? Это пригодится, если придется радикально менять фронт-енд, или писать клиенты (мобильные, десктопные и т.д.)
Justique: ну если вы андроидовское приложение запускаете под виндой, то конечно, фиддлер не будет ничего выдавать. Надо на андроиде настроить, что весь трафик через его прокси шел.
astrotrain: и все же я рекомендую подумать, какие однотипные действия вы часто делаете при разработке своих приложений.
Вот для них и стоит сделать свой класс/контрол обертку.
Например, в моем случае чуть ли не в каждом проекте приходится создавать такую группу контролов: TextBox - и справа от него кнопку "Обзор..." (для выбора пути к файлу или папке), а сверху - Label, который бы пояснял, что именно здесь выбирается. Иногда и по нескольку таких штук в одной форме или в разных.
Еще чаще приходится создавать просто TextBox'ы с поясняющими Label'ами. Без нескольких таких штук (а то и нескольких десятков штук) не обходится вообще ни один проект под .NET и с GUI.
Почему бы не сделать свои юзерконтролы для этих случаев? Чтобы не приходилось каждый раз кидать Label+TextBox (или Label+TextBox+Button), задавать этот текст "Обзор...", заморачиваться с позиционированием этих контролов друг относительно друга. Когда можно просто сделать свой композитный контрол, который кидаешь на форму, задаешь Name, задаешь текст для этого Label - и всё.
И это еще далеко не самый яркий пример, где требуется подобная рационализация.
> Но я не настолько опытный кодер
Так вы кодер или программист? Это разные вещи.
Если программист, то опыт у вас должен приобретаться в процессе разработки. И развиваться нужно постоянно, не только вширь (осваивать новое) но и вверх (на новом уровне).
astrotrain: > пока серьезные задачи мне только снятся
Учтите, что создание фреймворка (+ отладка) - это длительная работа.
Я тоже думал, что не нужно: валишь весь код прямо в button_Click и все.
А когда взял впервые крупный проект, спохватился, а оказалось, что ничего и нет, пришлось писать с нуля в рамках этого проекта.
> wpf почему не изменится?
Во-первых, потому что MS создал еще более новую технологию. Не знаю, как правильно назвать - то ли Metro, то ли WinRT; в последнее время вроде называется Windows Universal Apps (WUP). Оно хоть и основано на WPF (ничего принципиально нового уже давно не создается), но сильно от него отличается, и это не WPF.
Технология гораздо более сырая, чем WPF в свое время был; на данный момент под WUP невозможно толком писать, но это не мешает MS бросить на нее все силы и отчаянно проталкивать ее как "Windows Apps" (надеятся, что если на дерьме написать "конфетка", то его кушать будут).
Во-вторых, в MS уже давно не те кадры, чтобы придумывать и реализовывать что-то путное.
По этой причине страдают они фигней. WinPhone уже мало похож на продукт MS, скорее какая-то линуксятина вроде Android. А WUP и иже с ним - вообще жесть, еще больше смахивающая на линуксятину, на Mono какой-нибудь: избыточность по ООП и асинхронности, негибкость, сырость...
А в последнее время MS вообще признал, что будет пользоваться чужими опенсорсными (читай: линуксячьими) решениями, и в самом деле, я видел в его новейших продуктах сторонние библиотеки (даже в тех случаях, когда даже я - и то написал бы своё), т.е. сам он вообще ни на что не годен, и особо не скрывает это.
> многие его хвалят очень.
Есть что-то лучшее? Ничего особо лучшего и нету. MS уже не торт, а остальные и раньше были не торты.
astrotrain: вообще мне сложно придумать ситуацию, в которой бы это было реально нужно.
Обычно как бывает: типа нажал кнопку - запускается поток - так все и делается в нем.
Что же до обращений к GUI, то чтобы не загромождать код всякими Invoke'ами, следует всерьез задуматься о написании своей обертки над Winforms (или же Extensions), которая бы имела потокобезопасные методы и свойства (тогда пара InvokeRequired/Invoke будет внутри этих методов и свойств, а верхние слои кода загромождать не будет).
Да в любом случае невозможна серьезная, быстрая разработка без чего-то более высокоуровневого, нежели Winforms. Этим Winforms сколько лет уже? Вот с того 2003 года оно и не изменилось почти. WPF - тоже сырой, не менялся и теперь уже и не измеится.
Кто-то пользует готовые фреймворки вроде DevExpress или Telerik и платит за них кучу денег (кстати, не знаю, есть ли там такая важная фича, как потокобезопасность). Кто-то свое пишет, я, например.