VZVZ

> вообщем,чтобы можно было делать GUI на PHP
Об этом можно много писать. Это как раз-таки достаточно просто.
1. Пишем на PHP свой фреймворк со средствами для GUI и т.д., просто чтобы можно было написать скрипт, который бы скажем открывал окошко, копировал файл и т.д., если его запустить с помощью php.exe
В принципе, для довольно-таки многого в PHP уже есть средства, остается только написать для них удобные обертки, т.е. собственно фреймворк.
2. Пишем упаковщик этого дела в exe: скрипт упаковывается вместе с php.exe, или еще как-то так.
3. Пишем IDE с WYSIWYG и прочими фичами, для того, чтобы удобнее было писать код под этот фреймворк.
Собственно, всё.

> со своими возможностями,плюсами сделать.
Ага, я уже представляю, какие это плюсы получатся, с вашим "вообщем", с вашими запятыми без пробелов, а то и вовсе грубо пропущенными запятыми...
"Ты родной язык не знаешь, как тебе освоить язык программирования?" (c) Я
Вы как хотите, а нам - не надо таких плюсов больше:
demotivation.me.prxs.ru/images/20130408/kjzco6f2cy...
Devel Studio - это полное УГ, поэтому надо делать не "что-то типа Devel Studio", а скорее что-то типа Visual Studio. Но, во-первых, VS тоже нужно копировать не целиком и полностью, а только удачные из нее решения, а некоторые другие решения взять из других продуктов, которые сперва надо освоить на особом уровне. Во-вторых, чтобы взять удачные решения даже из той же VS, все равно нужно сравнить ее хоть с чем-то, иначе вы многого просто не увидите и не поймете.
Ибо большинство уникальных решений остается не сплагиаченным не потому что патент, а потому что нубы просто не осознают всю их уникальность и даже не пытаются подражать. Вот тупые люди даже не понимают, что если в винде кнопки "OK - Cancel" везде располагаются именно в таком порядке, то и у себя надо делать "OK - Cancel", а не "Cancel - OK" или еще как-то через задницу.
Говорю как реверс-инженер - специалист по промышленному шпионажу.

Ну да ладно, это все цветочки.
Вы главное подумайте: а как вы сделаете подобие того, что в VS называется IntelliSense?
Ну там всплывающие подсказки, или скажем чтобы скобочки подсвечивались: подводишь курсор к закрывающей скобке - умный алгоритм ищет открывающую и подсвечивает, или наоборот.
Вот интересно, а как вы собираетесь это делать?
Надеетесь на готовые решения? Или вы считаете, что нужно писать свой алгоритм разбора кода? А вы пробовали написать такой алгоритм хотя бы для какого-нибудь JSON или еще чего-то примитивного?
Или вы не согласитесь со мной, что это основа любой IDE, и без WYSIWYG еще возможно что-то путное сделать (пример: JetBrains), а вот без умного разбора кода - вообще ничего, и даже VS без этого уже была бы не VS?

> Я знаю C#
Пардон, какой C#, когда PHP?
Вы видели хоть одну удачную IDE, которая была бы написана не на том языке, не на том фреймворке, для которого она предназначена?
Вот и я что-то не припомню. Кстати, даже автор Devel Studio вроде бы понял это.

И еще, а почему именно PHP?
Что в нем хорошего?
Я бы еще подумал, что выбрать - PHP, или NodeJS (у JS-то синтаксис поудобнее будет), а может Ruby, а может для Python наконец написать что-то нормальное, а может еще что.
Много экспериментировал бы. А не то что - от балды: в моей новой IDE будет PHP и точка.

КОРОЧЕ, вывод такой:
- если вам нужны плюшки в виде библиотек - возьмите нормальную платформу (такую, как .NET) и пишите для нее свои плюшки в виде библиотек;
- если вам нужны плюшки именно в виде фич IDE - возьмите нормальную IDE (такую, как VS) и пишите для нее свои плагины (создавая плагины, вы заодно изучите чужие IDE изнутри);
Этим может и будет кто-то пользоваться. Хотя,воооооообщем-то,тоже вряд ли.
А вашей принципиально новой IDE, которую вы напишете сами, без команды спецов и без учета всех вышеупомянутых замечаний, 99,(9)% никто не будет пользоваться всерьез.
Нужно же все-таки как-то понимать, что чем крупнее, масштабнее и ответственнее проект, тем больше надо скиллов. И осознавать свои скиллы в соответствии с реальными достижениями - т.е. не завышать и не занижать ЧСВ.

P.S. Ну или я м***к. Извините, если обидел. Просто делюсь своим опытом.

Отрытое? Оговорочка по Фрейду)
Вы что, не видели приложений с открытым исходным кодом? Попробуйте исходники Chromium скачать и собрать, и поймете, что если приложение простое (а не как Chromium), то легче и проще написать самому, чем заниматься раскопкой исходников, которая обычно по сложности являет собой почти что реверс-инжиниринг.

А избегать изучения HTTP - это, помимо прочего, еще и очень глупо.
На фрилансе за создание HTTP-клиента (бота) для чужого сайта просят пятизначные суммы.
Да и вообще сейчас не Web 1.0 давно уже, и самые разные HTTP-запросы в том или ином виде нужны практически в любом крупном проекте, особенно что касается веба.
И учтите, что на свете есть вещи в сто раз сложнее чем HTTP, так что если вы даже HTTP осилить не можете, то каково будет во многих других случаях?

Сперва освойте HTTP в браузере (AJAX), вот гайд для начала:
codeproject.com/Tips/1065669/How-To-Build-Web-Site...
Уже после этого реализовать то же самое со стороны десктопного/мобильного приложения, неважно под какую платформу, будет гораздо легче. Общая логика везде одна, т.к. протокол один и тот же - HTTP.

Ну пусть на странице отправляется POST-запрос (хоть JSом, хоть серверно - хотя бы System.Net), а вы пересылайте пользовтаеля на ту страницу. Проблемы?

Ну, а вы сами не можете определить, где архитектура спроектирована грамотно, а где - безграмотно?
Зачем вообще нужна грамотно спроектированная архитектура? Прежде всего - для повторного использования кода (re-use), особенно посторонними программистами.
Вот и попробуйте по-re-use-ать код разных проектов. Идеально подходят библиотеки - которые как бы для этого и предназначены, чтобы можно было быстро, удобно их заюзать. Но и само приложение тоже легко так проверить, достаточно попробовать внести в него какие-то изменения и вообще разобраться в нем, и сравнить, сколько сил и времени будет затрачено в разных случаях.
В идеале тестировать нужно не на одном человеке, а на нескольких разных, предпочитающих разные языки и разные подходы.

Или вы просто не видите, что удобно, а что неудобно? Ну тогда пару слов о том, что такое - неудобное:
1) Избыточное.
Когда слишком много слоев абстракции.
Когда слишком много обязательных аргументов некой функции (не аргументов вообще, а именно обязательных).
Когда слишком много.
2) Длинное.
btnCloseAllApplicationsAndRebootMyComputer.
Без комментариев.
3) Короткое.
btn.
Без комментариев.
4) Нестандартное.
dAtETIMEPICKEr_______1.
textbox2.
BUTTON3.
Или когда в классе C# имя какого-либо публичного члена пишут с маленькой буквы.
Без комментариев.
4.1) Несоответствие парадигме ООП, хотя на данном языке возможно соответствие.
Когда так:
FormHeightSetter.Set(form1, 500);
Вместо:
form1.Height = 500;

Список можно продолжать. Но, видимо, и эти 4 пункта уже невыносимо сложны, коль скоро они нарушаются этак в 99,(9)% всех приложений.

Можно ли хорошо зарабатывать в качестве C# программиста

Вы не в курсе, что C# - основной инструмент под винду, которая суть основная десктопная ОС?

ASP.NET

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

Как много заказов и к какой области они чаще всего относятся?

Так вы программист или кодер?
Если программист, то ни к какой области не относятся.
Заказчик рассказывает вам, какой ему домик надо построить и в каких широтах, а вы уже решаете, дерево или кирпич, клееный брус или бревна, или вовсе алюминиевый профиль.

> c# на нем еще пишут?)
С чего вдруг столь странный вопрос?

> Есть ли смысл браться за все направления серверной разработки?
Есть.
Я еще и десктопную туда добавил, и мобильную, и еще ряд более редких направлений. И ни разу не жалею.

> Что учить?
Учат - стихи, наизусть.
А программированию - учатся.
Главное в программисте - это понимание общей логики. Веб не исключение. Скажем, формы (form) - они и в Африке формы. HTTP-запросы - они и в Африке HTTP-запросы. MVC - он и в Африке MVC. И главное - гугл - он и в африке гугл.
И чем больше вы изучите разных средств (в смысле изучите на практике, а не сколько учебников прочитаете), тем обширнее, глубже и тверже будут эти знания.
Да, если говорить об учении наизусть (чтоб прям все функции помнить без гугла), то лучше что-то одно, чем много, ведь голова-то имеет ограниченный объем памяти. Но знать функции наизусть - задача кодера, а не программиста.

Я юзаю библиотеку NPOI, она работает как с xls, так и с xlsx.
К сожалению, особых средств для импорта-экспорта в грид (типа одной строчкой кода) в этой библиотеке нет. Но довольно легко реализуется алгоритм, если учитывать ряд нюансов, например, необходимость createить ячейку перед заданием ей знаения.
Здесь пример и импорта и экспорта из грида:
www.codeproject.com/Tips/813187/Csharp-Read-and-wr...
и также есть вариант с еще одним подходом к работе с Excel - через ADO

StreamReader хз, а BinaryReader - сто пудов может. Обычно такая функция называется seek.
Только она задает не строку, а положение каретки.

Может, лучше готовую БД применить? В них тот же принцип как раз.

> Значит возможен ли UI с помощью html, css и js?
Теоретически - возможен.
Практически - для десктопа нет ничего более высокоуровневого, чем браузерные движки (в которых очень многого не хватает, поэтому многое придется сделать самому), вот обзор нескольких движков:
www.codeproject.com/Tips/825526/Csharp-WebBrowser-...
Еще один серьезный минус - тяжеловесность (несколько десятков мегабайт будет весить движок).
Правда, еще можете HTMLayout/Scite глянуть, я их особо не видел, из преимуществ - легкий вес, нужно будет и мне их глянуть, но видимо вменяемых оберток под .NET для них нет, а это плохо.

На мобильниках есть PhoneGap и React Native (благо в Android 4.x из коробки уже входит нормальный браузерный движок, а не такой, как IE - WebBrowser на винде), но они сыроваты, толком не документированы, малоизвестны.
Скорее это не для "великолепного" интерфейса, а для интерфейса быстросоздаваемого, когда есть наработки на HTML+CSS+JS и надо на них построить GUI в мобильном приложении. И кроме этих HTML+CSS+JS, в приложении особо ничего больше и не планируется.
Скажем, есть некий сайт, и нужно напилить для него мобильный клиент (типа как для VK, Facebook и т.д.) Так как сайт, слава Богу, имеет стройное RESTful API, то проще не писать нативный GUI, а взять ту же веб-морду на HTML+CSS+JS, прилепить ее к PhoneGap и с помощью какой-то матери сбилдить все это.

В Atom и VS Code, возможно, дело было отчасти в том, что именно те алгоритмы, в которых было автодополнение, подсветка синтаксиса для HTML, CSS, JS (и прочие основные возможности любой IDE), - именно те алгоритмы были только на JS (или готовые контролы для этого были на HTML+CSS+JS). А так как - еще раз - это основа любой IDE, то ничего удивительного.
Ну и да, VS Code и Atom - в основном рассчитаны на Web-разработчиков, среди которых есть и линуксоиды и маководы, и немало, поэтому в данном случае имеет хоть какой-то смысл кроссплатформенность - которая в иных случаях не дает ничего, кроме затруднения разработки и падения ее качества.

> Ходят слухи что WPF, помирает
Запомните раз и навсегда - никакой инструмент просто так не помирает.
Паровозы не исчезнут, пока не появятся тепловозы и электровозы.
Где альтернатива для WPF?
MS напилил новую платформу Windows Universal Apps (ранее - Metro), и усиленно проталкивает ее в массы, называя эти приложения "Windows Apps", ясно намекая, что якобы это и есть полноценные приложения для винды.
Но дерьмо не станет конфеткой от того, что его завернут в фантик. WUP - по-прежнему сырое УГ, да и в будущем конфеткой не станет - кадры в MS давно уже не те, чтобы писать хорошие, гибкие, удобные фреймворки без избыточности во всех ее 50 оттенках.
WPF и WinPhone уже были сыроваты - а еще более новый WUP еще хуже.
Ну и да, замечу, что WUP далеко не принципиально новый, и во многом основан на том же WPF (поэтому не так и сложно перейти с одного на другое). WUP - это такой же "не WPF", как и Spartan - "не IE", и примерно как Bolgenos - не "Ubuntu".

> Может ли это быть защитой от автоматического чтения страниц? И как такое можно обойти?
Может. Обойти можно, если с помощью сниффера (например, Fiddler) посмотреть запросы от браузера и 100% имитировать их на C# (учесть все заголовки, куки и т.д.)
Также в самом Fiddler можно и поэкспериментировать с заголовками и куками (вкладка Composer)

По Threadам особо не думал над этим. Почему бы тот MessageBox не показывать в том же самом методе calculate?
Если требуется обращение к GUI - то Invoke в помощь.

А вообще, в современном C# для асинхронности есть задачи (Task) и async-await, и вот await по определению как раз ждет, когда задача выполнится.

Вот типа такого писал (внимание на слово "async" - оно обязательно):

private async void button1_Click(object sender, EventArgs e)
{
    var s = await Task<string>.Factory.StartNew(() => {
        /* Этот код выполняется асинхронно - в отдельном потоке */
        return "Test";
    });
    
    /* А этот код снова в том же потоке */
    MessageBox.Show(s);
}

VS была 2013. Но .NET - не 4.5, а 4.0, подключил NuGetовский пакет Microsoft Async.

Обычный HTTP-запрос, если не ошибаюсь.
Так что если вы его можете передать, но не с помощью C#, а как-то еще - то отследите его сниффером (например Fiddlerом) и симитируйте на C# с помощью HttpWebRequest или библиотеки RestSharp (она несколько проще и удобнее)

Проблема в ваших XPath-выражениях.

// - абсолютный путь, действует в контексте ВСЕГО документа, возвращает первую ветвь в документе, а не в той ветви, где вы это хотите. В этом случае SelectSingleNode всегда срабатывает как doc.DocumentNode.SelectSingleNode

.// - относительный путь, действует именно относительно ДАННОЙ ветви

> Как научить DGV формировать нужный мне запрос?
Сам грид ничего формировать не умеет.
В .NET вообще нет ничего подобного, НАСТОЛЬКО высокоуровневого.

Вам надо самим получать выбранную строку грида, затем значения из ее ячеек и, наконец, составлять SQL-запрос.
Причем, выбранная строка - это может быть как dataGridView1.CurrentRow, так и dataGridView1.SelectedRows (смотря где именно кликнет юзер), поэтому нужно реализовать оба варианта, с проверками на null.

Вариант с dataGridView1.CurrentRow:

MessageBox.Show(dataGridView1.CurrentRow.Cells[0].Value.ToString()); // Cells[0] - первый столбец

Вариант с dataGridView1.SelectedRows:

MessageBox.Show(dataGridView1.SelectedRows[0].Cells[0].Value.ToString()); // Cells[0] - первый столбец

> Возможно есть аналогичные инструменты, в которых имеется эта возможность.
Ну, например, сниффер в руки + голые HTTP+HTTPS запросы. Это тяжелый и ни разу не аналогичный, но зато самый гибкий путь.
Из полегче - браузерные движки. Для C# их аж несколько есть:
www.codeproject.com/Tips/825526/Csharp-WebBrowser-...
А еще можно миксовать: часть запросов отправлять через движок, а что через него отправить нельзя (скажем input file) или не хочется - то отправлять тоже через него, но не имитируя действия с DOM, а с помощью XMLHttpRequest! При этом все необходимые заголовки ведь сохраняются, в отличие от голых HTTP-запросов, где все заголовки вручную имитировать надо. Вот только сегодня такая идея в голову пришла.

P.S. Специалист по ботам, реверс-инженер, разработчик ПО и архитектор ПО.