Semyon89

Надо использовать элементы из группы Form Controls.
Тогда все работает. Например, добавил выпадающий список и программно меняем его свойства:

Sub Macro1()
'
' Macro1 Macro
'

'
    ActiveSheet.Shapes.Range(Array("Drop Down 1")).Select
    With Selection
        .ListFillRange = "$A$1:$A$3"
        .LinkedCell = ""
        .DropDownLines = 8
        .Display3DShading = False
    End With
End Sub

Есть фундаментальный труд Transactional Information Systems. Theory, Algorithms, and the Practice of Concurrency Control and Recovery авторства Gerhard Weikum и Gottfried Vossen.

Ведь не проблема читать-писать файлы. Проблема - как это делать корректно в условиях конкурентного доступа, как обеспечивать восстановление после аварий, как обеспечивать ACID. В этой книге как раз вся сопутствующая теория.

Просто реализуйте свой KeyValuePair, в нём есть всё, что нужно для словаря. А база это на ваше усмотрение, какая БД вам удобна ту и используйте, но она определённо нужна. Не будете же вы хранить слова в .txt файле

Алгоритм структуры? В сети немало чудаков, но вы - первый, кто так сопряг эти слова.

Стоит ли использовать хеш-таблицы, если да то какую структуру данных использовать (из STL в C++ или в C# из пространства имен System.Collections.Generic )?

Можно, любую. В словаре Мюллера полтора кило веса, но для хэш-таблицы это - пустяк.

Могу ли я ко всему этому подключить SQL Microsoft базу данных?

Можно, но зачем тут многопользовательская база? Достаточно и SQLite.

пробовал реализовать нечто подобное в виде двоичного дерева ... терялась скорость поиска

Какая скорость, вы вообще о чём? Вам сюда.

1) Документируй
2) Абстрагируйся всегда максимально
3) Пиши классы по принципу "черного ящика"
4) Один класс решает одну конкретную задачу, не стоит городить комбайны.

1) по поводу возраста не комплексуй. ерунда это всё. просто у большинства после 30 уровень гормонов падает и лень-матушка плюс задница_принявшая_форму_уютного_кресла и боязнь что-то менять. а вовсе не какие-то поражения мозга, чушь это. Просто так сложилось что профессия молодая у нас, дофига молодёжи, молодые боссы - и на начинающего старше себя смотрят с удивлением. В конце 80-х - начале 90-х, когда прорвало занавес и к нам начали массово приходить персоналки было немало программистов-самоучек вида "научный сотрудник за 30 дорвался до айбиэмки". и работали, и в первых фирмочках, выросших из лабораторий НТТМ таких сотрудников овердофига было. просто они сейчас или боссы, или на пенсии, или растворились в массе пришедших на волне бума юношей.

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

3) нужна "подушка безопасности" в виде некоторой суммы. это важно.

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

5)в IT не только программисты есть. есть тестирование, есть менеджеры - совершенно самостоятельная ветка развития. есть продажники наконец. может вам туда? там тоже интересно, как я погляжу.

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

Нет одинаково эффективного пути для всех и каждого.

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

Тут главное - настолько сильно хотеть достичь результата, чтобы любые препятствия только добавляли азарта. Чтобы ночами спать не мог и думал о задаче. Это ключевой момент обучения. Все остальное - декорации, способы, инструменты...

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

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

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

На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

С этим не рождаются, это выкристаллизовывается за сотни и тысячи часов жесткого баттхерта от неспособности найти, где ты забыл поставить запятую... Когда код из 10 строк прочитан сотни раз вдоль, поперек и наискосок...

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

Обрати внимание, самое главное качество во всем этом многабукафф - упорство на грани фантастики. Любой, кто не дойдет до конца, не треснет себя по лбу в соты раз с воплем, так вот же она где, эта запятая, пропущена - сломается в самый неподходящий момент на боевом проекте...

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

Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

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

https://coggle.it/diagram/52e97f8c5a143de239005d1b...

https://github.com/zualex/devmap
images.vfl.ru/ii/1466366676/e324255d/13079149.png
www.webdesigndegreecenter.org/learn-to-code

https://www.codewars.com/

Во-первых, условимся, что в рамках вопроса не делаем различий между OpenGL и DirectX. Будем называть их "графическим API".
Во-вторых, будем считать это графическое API низкоуровневым (т.е. таким, как OpenGL и DirectX). Графические движки, где есть понятие сцены и камеры не рассматриваем в принципе.

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

Для графического API НИКАКОЙ КАМЕРЫ НЕ СУЩЕСТВУЕТ.

Для графического API существуют только примитивы (треугольники, линии, точки), которые вы хотите нарисовать, состоящие из вершин с трехмерными координатами и набор математических преобразований, которые вы хотите выполнить над этими вершинами ПЕРЕД тем, как они начнут реально рисоваться на экране (т.е. перед их растеризацией). ВСЁ. Все, что для вас выглядит как движение/поворот объекта в игровом мире ("мировые преобразования"), и движение/поворот камеры ("видовые преобразования") - лишь результат того, что вектора, задающие вершины объекта (например, кубика) предварительно умножаются на нужную, рассчитанную вами матрицу.

Лет 10-15 назад такая матрица отдавалась непосредственно графическому API через специальные вызовы (когда видяхи уже умели делать T&L https://en.wikipedia.org/wiki/GeForce_256 , но еще не умели шейдеры), сегодня умножение вектора на матрицу - всего лишь одно из множества различных преобразований, которые можно выполнить в векторном шейдере.

Теперь читайте про то, как эти матрицы используются и рассчитываются. Когда поймете матчасть, гляньте библиотеку GLM (раз уж у вас указано C++ и OpenGL) - она поможет не делать вам рутинную работу.