Дмитрий Макаров

Так или иначе роботу нужно выделить особенности его конкретного местоположения и связать их с координатами. Для этого нужна дополнительная информация о поле.
Дополнительная информация закладывается либо с существующего поля ("забор", "столбы", "маяки", рисунок на поле или заборе),
либо создается дополнительно специально (особый рисунок на поле или заборе, активные ультразвуковые маяки, некое интерференционное ультразвуковое поле особое к каждой точке).

Вообще, исторические и бытовые методы геопозиционирования кладезь идей для вашего вопроса. =)

Бывают USB-звуковые карты.
А можно АЦП прикрутить.

В первую очередь надо попробовать у webKitBrowser`а дернуть методы Refresh или Update, хотя скорее всего это не должно принести результата, потому что скорее всего WebKit куда-то в свой буфер рендерит и по этим методам просто обновляет экран из буфера.

А зачем вообще нужна такая функциональность к браузере? Если на страничке используется jQuery, то и добавляй, пожалуйста, в страничке его. Если не используется, то и не нужен он. Или подразумевается еще какой-нибудь скрипт до кучи/или вместо грузить? Снифер там или что еще? =)

По идее загрузка и отображение странички в браузере идет, если упрощенно, так: загрузка->построение DOM->рендеринг. Причем современные броузеры делают это потоково, то есть постепенно отображая загруженное, но в некоторых случаях могут и все перерендерить (например при изменении размера окна). В вашем случае нужно вклиниться где-то в процесс загрузки заголовка или добавление в DOM заголовка, но что-то я не увидел в WebKit.NET хуков/событий для такой возможности.

Можно попробовать сделать фиктивное масштабирование или искусственно вызвать событие изменение размера окна, но это грязный хак.

Ну а что то похожее на правду можно сделать, если реализовать некий прокси, через который направить http-трафик, на лету искать заголовок и вставлять ваш скрипт.

Не очень понял.
Напрямую ссылку с объекта из процесса в процесс не передать. У процессов память разная. Процессы объекты друг друга не видят.

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

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

User Manual по вашему контроллеру. На 607 странице как раз рассказывается как работать со встроенной флэш-памятью.

Конкретно с этим МК не работал, но общие впечатления такие.

Во флеш памяти лежит ваша программа. Если вы хотите во встроенную флеш грузить какую-то особую информацию, то надо выделить во флеше для этого специальное место. В IDE при создании проекта, или в свойствах проекта можно поискать, и/или файл отдельный есть с разграничением памяти. Ну и понятно, что для программы места будет меньше.

Кроме того, это все же флеш. Соответственно, ограничение по ресурсу на запись есть. Если будете туда писать часто, то быстро закончится. Нужно оценить хватит ли циклов записи на время жизни устройства. Иначе нужно либо внешнюю сменную флеш, либо выделять избыточное количество для этих данных и следить за равномерным его использованием (как в SSD).

Вот тут посмотрите: DataGridView.Sort

Там указан пример реализации IComparer`а, который нужно дать методу сорт. Вам нужно изменить у класса RowComparer метод Compare. В вашей реализации сравнения двух DataGridViewRow вам нужно выделить содержимое ячейки с текстом даты, распарсить с помощью DateTime.Parse и выдать результат сравнения дат.

В свое время когда я начинал программировать с QBasic`а и TurboPascal`a, особых вариантов куда дальше развиваться не было: С++. Реальный язык для решения реальных задач.

Для работы с GUI в Win логичным продолжением было Delphi и С++Builder. MFC от M$ был настолько корявый (по моему мнению), что даже смотреть в его сторону не хотелось.

Затем меня надолго унесло в сторону микроконтроллеров и там С/C++ мне помог в работе наиболее полно: быстрые программы, полный контроль над памятью - то, что нужно.

Потом, мне опять понадобился GUI. Как раз .NET и С# к этому моменту поборол свои детские болезни. С# мне показался очень цельным языком и легким в обучении. С С# я наиболее полно разобрался с ООП (в С++ я с ООП как-то плавал: не складывалась цельная картина). Сейчас C# продолжает развиваться. Это современный язык. Есть много задач, для которых он идеальный инструмент. Впрочем С++ не отстает и современные спецификации тоже включают в себя практически все новинки. Но все равно С++ сложнее: есть куча способов запнуться на ровном (как минимум с точки зрения С#) месте, муторная работа с памятью.

Сейчас при работе .NET с С# иногда возникает необходимость работать со старыми библиотеками, написанными на С++. В .NET есть такой язык как С++/CLR, который с одной стороны умеет работать с .NET, а с другой стороны спокойно работает с "чистым" С++ и становится спасительным мостиком в таких случаях. Кроме того, пару раз мне приходилось реализовывать в С++/CLR сложные, с вычислительной точки зрения, задачи. Сейчас правда вижу, что можно тоже самое было сделать не выходя за рамки С#, но в С++ это получилось все равно сделать проще.

В общем, в моем случае мне сильно помогло, что я начинал с С++. Но работаю я все же в основном в C#. Как бы не получилось так, что начав с С#, как с более простого, вашему знакомому будет потом сложновато в редких задачах, где понадобиться навыки работы в С++.

Совет, наверное, стоит сделать такой: изучайте С# для GUI, попробуйте для развлечения поковыряться с микроконтроллерами: там где реально нужно будет самому на С++ писать. Можно, например, для ардуино на с++ писать: и паять не нужно ничего, и стоит недорого. Не скетчи, а именно разобраться как с С++ работать.

А еще смотрите другие языки: JavaScript, Python, функциональное что-нибудь. Главное чтоб мозги не костенели в какой-нибудь одной парадигме, а могли смотреть на задачу максимально широко.

Про веб знаю чуть меньше, чем больше, но в целом...:

Большая сложная система требует вдумчивого подхода при разработке, иначе:
во-первых, она никогда не будет реализована;
во-вторых, в ней сложно будет искать и исправлять ошибки;
в-третьих, ее сложно будет дорабатывать, добавлять новый функционал.

Все это в итоге удорожает/замедляет процесс разработки.

Поэтому, подход "Некогда думать - надо код кодить" не работает или работает плохо. Когда проект большой роль "думать" выпадает отдельному человеку, которого называют "архитектор".

Архитектор анализирует общесистемные требования, разделяет систему на подсистемы и модули, определяет интерфейсы взаимодействия систем и модулей и определяет требования для подсистем и модулей.

Еще по идее он должен знать про паттерны проектирования, uml, idef.
А еще он должен иметь опыт программирования, иначе будет продуцировать "ересь" и его никто слушать не будет.

Вместо двух камер можно использовать одну и пару зеркал. И все алгоритмы для двухкамерной системы.

При рисовании повернутых фигур можно применять афинные преобразования. Компьютер умеет это делать быстро.

Например, при рисовании прямоугольника рисуем его неповернутым (стороны паралельны краям экрана), задаем матрицу преобразования (которая определяет смещение, поворот, масштабирование по X и по Y) и вот мы уже имеем нужный нам прямоугольник в нужном месте под нужным углом.

При необходимости сжатия/растяжения можно тривиально сжать/растянуть исходный прямоугольник (неповернутый). Его матрица преобразования останется прежней и сместит/перевернет его в то место, где он был изначально, но уже сжатым/растяженным.

Либо можно соответствующим образом модифицировать матрицу преобразования. Матрица преобразования определяет в том числе и растяжение/сжати по осям.

В .NET в GDI+ есть готовые возможности для работы с афинными преобразованиями:
Матричное представление преобразований
Использование преобразований в управляемом GDI+

P.S.:
Если ваша задача - это лабораторная из цикла: сделал и забыл, то все это городить не имеет смысла.
Но в больших проектах, где много графических элементов повернутых друг относительно друга иерархически связанных, лучше освоить математику афинных преобразований и перестроить в соответствии с ними архитектуру. Проще жить будет.

Пока юридические вопросы не решены.

• Отсутствует юридический механизм передачи всех прав вновь созданному человеку в пункте назначения, от уничтоженного в пункте отправления. Трактовать это как наследование, дар или смотреть на эту ситуацию сквозь пальцы и будь что будет
  
• Непонятно как интерпретировать регулярные убийства людей в пункте отправления.
  
• Непонятно, что делать есть в пункте отправления функция уничтожения не сработала как следует. ("Извините, у нас тут небольшая техническая нестыковочка. Видите ли, вы уже прибыли в пункт назначения, а тут мы вас недоуничтожили. Но вы не переживайте: сейчас техники проверять оборудования и мы вас уничтожим. Следующая телепортация за наш счет.").
  

В с++ больше свободы....в нем вы можете написать наделать кучу ошибок на пустом месте.....если хорошо знать с# и следовать этому пути/стилю в с++, то в сходных задачах особой разницы нет, даже может хорошо что начали с с#....ну, возможно, подисциплинированнее нужно быть.
Но есть задачи специфичные для с++: низкоуровневое программирование, работа с памятью, указатели. Тут другой мир совсем....

Есть специальная микросхема, которая опрашивает ряд "сухих контактов" и выдают в SPI. Можно соединить каскадно. SN65HVS882.

О...9 лет. 6 класс. Я в этом возрасте в спектруме какие-то штуки набирал/запускал, а в школе нам про бейсик рассказывали на укнц и кубейсик на 286, а в седьмом классе уже турбопаскаль начали.
Но это давно все было. Сейчас надо про ооп что-то. Все говорят что питон самый лучший язык для начала обучения программированию. А я скажу, что с# тоже довольно неплох в этой роли. Я начинал изучать ооп через с++, но шло очень туго. Через какое-то время стал смотреть с# и все стало как то киристально ясно. Может правда это мой персональный путь с учетом школьной базы с бейсиками и паскалями, но все же то же самое школьное можно делать с помощью с#.
В школе проходили базовые понятия программирования: массивы, циклы, ветвления, подпрограммы, рекурсии, структуры, деревья. Базовые алгоритмы: сортировка, поиск. Без этого конечно никак. Сейчас добавляем ооп, ui и лучше сразу тестирование в каком то виде. Отладкой так и так придется позаниматься. В какой то момент когда набьются шишки можно познакомить с git'ом (через год).
Все это лучше изучать через небольшие проекты.
Вот как то так я бы себя молодого учил будь у меня такая возможность =)

Встречный вопрос: а где вы собираетесь работать после получения таких специальностей? видимо, в екатеринбурге, так где там? Возможно где-нибудь в Зеленограде или, извиняюсь, Сколково что и есть, но в екб.... возможно проектирование тут, под заказ в китай, но занимается ли кто нибудь в екб этим?