GDI - Слова разного цвета в одном тексте

[youneuoy]

11 часов назад, Antonshka сказал:

Весь вопрос в предварительной проверке активности элемента в родительском методе, перед его вызовом.

переименуй везде draw в update и втыкай проверки внутрь. Или забей и пиши код дальше, у тебя ведь основной затык в общей архитектуре, а не в данном куске. Допиши либу и потом повтори снова, но уже по-человечески🙂 Не знаешь как спроектировать большую штуку - не проектируй, набей руку на написании обычных кусков кода сначала.

Изменено 27 июля, 2022 пользователем youneuoy

[Antonshka]

11 часов назад, youneuoy сказал:

переименуй везде draw в update и втыкай проверки внутрь. Или забей и пиши код дальше, у тебя ведь основной затык в общей архитектуре, а не в данном куске. Допиши либу и потом повтори снова, но уже по-человечески🙂 Не знаешь как спроектировать большую штуку - не проектируй, набей руку на написании обычных кусков кода сначала.

"update" звучит немного размыто. Как "change", "modificate".

Я решил отложить написание кода. Буду читать банду четырех. Посмотрю как они это делают.

[Antonshka]

В 27.07.2022 в 09:43, Xipho сказал:

И снова у меня толком нет времени, чтобы тебе обстоятельно ответить, а давая контекст кусками, я создаю у тебя в голове впечатление противоречий. Это плохо. Давай так. Попробуй внимательно почитать про принципы SOLID. Если тебе что-то в них не будет понятно, пиши, постараюсь объяснить. На конкретных примерах кода в разных участках программы это делать сложно. Попутно - прочитать/перечитать книгу по паттернам от "банды четырех", внимательно вникая, как авторы рассуждают по ходу книги. Поинт на заметку - почему в винде каждый контрол является окном, туда же - в упомянутой книге почему в редакторе везде  и всюду во главе всего идет класс Glyph.

Почитал "Банду четырех". Меня хватило на несколько часов.

Таких заумно написанных книг я еще не читал. Абстракция на абстракции. При всем понимании необходимости в ее прочтении, я пасс

Почитаю книгу Head First. Паттерны проектирования [2022]. Судя по первым страницам она попроще.

Если и она не зайдет, то и не знаю как поступать.

[Xipho]

3 часа назад, Antonshka сказал:

Таких заумно написанных книг я еще не читал. Абстракция на абстракции. При всем понимании необходимости в ее прочтении, я пасс

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

 

3 часа назад, Antonshka сказал:

Почитаю книгу Head First. Паттерны проектирования [2022]. Судя по первым страницам она попроще.

Она намного проще, и хорошее понимание даст. Но после нее я всё же настоятельно рекомендую читать "банду четырех". 

[youneuoy]

8 часов назад, Antonshka сказал:

"update" звучит немного размыто. Как "change", "modificate".

в том и суть. В этом самом update вызывай draw и прочее🙂Подобное не так трудно уже будет обмазать паттернами и получить модный плюсовый код, который хипхо одобрит.

8 часов назад, Antonshka сказал:

Я решил отложить написание кода.

это ты зря. Практика наше всё.

Изменено 28 июля, 2022 пользователем youneuoy

[Xipho]

43 минуты назад, youneuoy сказал:

Подобное не так трудно уже будет обмазать паттернами и получить модный плюсовый код, который хипхо одобрит

хипхо не одобрит код, обмазанный паттернами ради паттернов...

[Antonshka]

13 часов назад, youneuoy сказал:

в том и суть. В этом самом update вызывай draw и прочее🙂Подобное не так трудно уже будет обмазать паттернами и получить модный плюсовый код, который хипхо одобрит.

это ты зря. Практика наше всё.

Для практики нужна же теория. Ее у меня не достает.

Книга Head First. это нечто. Такая дружелюбная и легкая. Не могу теперь переключиться на проект, пока ее не дочитаю. Ждал утра чтобы скорее продолжить читать. Обычно приходилось себя принуждать, более или менее, а тут, как бы идешь пообщаться с интересным позитивным человеком.

[youneuoy]

14 часов назад, Xipho сказал:

хипхо не одобрит код, обмазанный паттернами ради паттернов...

В любом случае, подобный однотипный код при небольшом рефакторинге можно будет плюсовыми объектами объединить, запихать в контейнер, обновлять уже совсем по-хитрому и т.п. А там и без собственного желания в паттерн какой-то гарантированно вляпаешься🙂 И этого никак не получится сделать, если не писать вообще ничего или если зависнуть на месяц, втыкая в несколько строк кода.

2 часа назад, Antonshka сказал:

Для практики нужна же теория.

Теория без практики мертва, практика без теории слепа. Занимайся и тем и другим и побольше.

Изменено 29 июля, 2022 пользователем youneuoy

[Xipho]

2 часа назад, Antonshka сказал:

Книга Head First. это нечто. Такая дружелюбная и легкая.

Эта серия вся дружелюбная. Годноты там немало ) 

 

1 час назад, youneuoy сказал:

А там и без собственного желания в паттерн какой-то гарантированно вляпаешься

Всё так, ага ))) Но лучше, когда ты понимаешь, куда вляпываешься, чтобы это не было случайным

 

1 час назад, youneuoy сказал:

Теория без практики мертва, практика без теории слепа. Занимайся и тем и другим и побольше.

Очень правильно. Я бы порекомендовал по каждому паттерну в ходе изучения прикидывать свои кейсы и набрасывать их в коде.

[Antonshka]

В 29.07.2022 в 13:57, Xipho сказал:

Эта серия вся дружелюбная. Годноты там немало )

Я дочитал Head First...

Ну как дочитал, первую половину книги я читал тщательно. Ничего не пропуская. А вторую, я читал уже на перемотке.

 

Я не могу понять одно, - толь я туповат, толь авторы книги объясняют непонятно. Я начинаю читать очередную главу о паттерне, о его устройстве, назначении. Но ничего не понимаю. Снова читаю, снова не понимаю. Так я доходу до примера кода, который на Java (но ничего, он похож на С++). Переписываю его весь в Visual Studio, корректирую под С++. И тут мне сразу все становиться понятно. Стоит только взглянуть на общую картину кода. И так со всеми паттернами!

Ладно еще на Github есть код примеров для этой книги, что помогло немного ускориться.

 

Банду четырех я посмотрел еще раз, после прочтения Head First. Теперь она воспринимается по другому. Теперь понятно о чем они пытаются рассказать. Но читать я ее не буду, все по той же причине.

 

Пока читал, прикидывал как можно применить паттерны к библиотеке. И сейчас прикидываю. Но ничего на ум не приходит. Хотя я хорошо понял их суть.

Сейчас библиотека в основном использует композицию, а не наследование. То есть "стратегию".

Из книги я понял что нужно программировать на интерфейсах а не на реализации, и что нужно отделять временное от постоянного. Посмотрю, где это можно применить. А так, даже в данный момент, архитектура библиотека мне кажется нормальной. Единственное, я не планировал делать ее кроссплатформенной. Чтобы не усложнять код.

Изменено 31 июля, 2022 пользователем Antonshka

[Xipho]

10 часов назад, Antonshka сказал:

Пока читал, прикидывал как можно применить паттерны к библиотеке. И сейчас прикидываю. Но ничего на ум не приходит. Хотя я хорошо понял их суть.

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

 

10 часов назад, Antonshka сказал:

Сейчас библиотека в основном использует композицию, а не наследование

Это немного странно, потому как четко прослеживается иерархия классов окна и контрола (опять же, по примеру винапи).

 

10 часов назад, Antonshka сказал:

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

А у тебя есть понимание, почему стоит программировать именно так? 

[Antonshka]

1 час назад, Xipho сказал:

Это немного странно, потому как четко прослеживается иерархия классов окна и контрола (опять же, по примеру винапи).

Когда я говорил "в основном", я имел ввиду что всю работу выполняют объекты "стратегии". Они в библиотеке представляю определенные свойства, окна или WinAPI контрола. А сама иерархия вот такая

Спойлер

 

Сами контролы практически ничего не умеют делать. Все на что они способны, это делегировать (теперь новое слово в моем словарном запасе) задачу объектам стратегии из своей оконной процедуры, когда это нужно.

А так, сам пользователь обращается к объекту "стратегии" окна/контрола, и через него влияет на окно/контрол.

Спойлер

WND_MAIN = new WGW::Window(TRUE, 0, 0, L"MainWindowName", 20, 20, 1000, 900);
WND_MAIN->onClose = OnCloseFunction;
WND_MAIN->color = RGB(188, 190, 220);
WND_MAIN->onPaint = OnPaintFunctionName;
WND_MAIN->onEraseBkg = OnErase;
WND_MAIN->onClick = FirstRandomFunctionName;
WND_MAIN->icon16 = _IDI_PACK;
WND_MAIN->titleBar.enabled = TRUE;


BTN2 = new WGW::ButtonStandart(TRUE, 0, 0, L"Btn2", 220, 400, 200, 200, WND_MAIN);
BTN2->toolTip.enabled = TRUE;
BTN2->toolTip.titleText.append(L"ToolTipTitle ", RGB(10, 10, 200));

 

 

1 час назад, Xipho сказал:

А у тебя есть понимание, почему стоит программировать именно так? 

Да, в этом плане все хорошо, все понятно из книги. Как я понимаю, основная цель паттернов это перспективы на будущее. Патерны это приемы избавляющего разработчика от переделывания проекта при его расширении.

В этом плане "стратегия" мне очень нравится. Ни от кого не зависит, делает что хочет. Окну/контролам не важно что она там у себя делает. Важно только иметь в своем классе ее объект и некоторые разрешения через "friend" по необходимости.

[Xipho]

9 часов назад, Antonshka сказал:

Патерны это приемы избавляющего разработчика от переделывания проекта при его расширении.

Да, всё так.

 

9 часов назад, Antonshka сказал:

иерархия вот такая

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

[Antonshka]

1 час назад, Xipho сказал:

В целом выглядит неплохо, но смущает использование стратегии.

Стратегия используется только в качестве свойств контролов. Без них я даже не представляю как организовать свойства. Делать классы свойств и наследовать их контролами? Или писать методы для общих свойств в базовом классе, а некоторые, специфичные, в конкретном классе? Стратегия выглядит более подходящей. В книга также было написано, использовать композицию вместо наследования.

 

1 час назад, Xipho сказал:

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

Если использовать стратегию в качестве свойств, то в случае если в классе Window будет объект-стратегия Menu, и если контролы будут наследовать класс Window, то тогда они наследуют и объект Menu. Да и другие некоторые, не свойственные для них объекты.

Даже если использовать не стратегию для свойств, а наследование их классов, то получится тоже самое. Класс Window наследует класс Menu, а класс Button, например, наследует и Window и Menu.

Это если я правильно понял тебя про наследование. Я тоже думаю лучше увидеть код.

Я его привожу в порядок. Вчера половина дня ушла только на переход с MethodName на methodName. На выставление скобок для всех одиночных if. На перенос первой скобки вправо в конец.

[Xipho]

10 часов назад, Antonshka сказал:

Делать классы свойств и наследовать их контролами? Или писать методы для общих свойств в базовом классе, а некоторые, специфичные, в конкретном классе?

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

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

 

10 часов назад, Antonshka сказал:

В книга также было написано, использовать композицию вместо наследования

Да, это в большинстве случаев дает гибкость больше, чем в случае с наследованием, но, еще раз повторюсь, всё нужно использовать в разумных пределах. В общем, лучше смотреть код, как я и говорил выше.

 

10 часов назад, Antonshka сказал:

Вчера половина дня ушла только на переход с MethodName на methodName. На выставление скобок для всех одиночных if. На перенос первой скобки вправо в конец

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

[Antonshka]

2 часа назад, Xipho сказал:

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

Я столько много копал на этот момент. Плюс сам для себя пытался понять, как мне удобнее.

В интернете большинство придерживается methodName. На счет скобок не нашел.

Автор Imgui использует MethodName, и скобки все слева.

 

Я перевел в одном классе все методы на methodName, перевел все поля-объекты также на camelCase (не поля обычных int, float... они и так были camelCase). И я нашел что для глаз так легче.

BTN2->ToolTip.TitleText.Append(L"ToolTipTitleSecond1  \n", RGB(144, 140, 10)); //было

BTN2->toolTip.titleText.append(L"ToolTipTitleSecond1  \n", RGB(144, 140, 10)); //стало

Не знаю как это работает, но camelCase читается удобнее.

Со скобками как в Java менее удобно, (наверно потому что не привык). Но зато с ними методы отделяются друг от друга более очевидно.

Спойлер

// было
VOID ToolTip::onOwnerWmLButtonDown(LPARAM& lParam) 
{
  if (threadLocal)
  {
    terminateThreadLocalForThisToolTipObject();
  }
}

VOID ToolTip::onOwnerWmMButtonDown(LPARAM& lParam) 
{
  if (threadLocal) 
  {
    terminateThreadLocalForThisToolTipObject();
  }
}

VOID ToolTip::onOwnerWmRButtonDown(LPARAM& lParam) 
{
  if (threadLocal) 
  {
    terminateThreadLocalForThisToolTipObject();
  }
}

// стало

VOID ToolTip::onOwnerWmLButtonDown(LPARAM& lParam) {
  if (threadLocal) {
    terminateThreadLocalForThisToolTipObject();
  }
}

VOID ToolTip::onOwnerWmMButtonDown(LPARAM& lParam) {
  if (threadLocal) {
    terminateThreadLocalForThisToolTipObject();
  }
}

VOID ToolTip::onOwnerWmRButtonDown(LPARAM& lParam) {
  if (threadLocal) {
    terminateThreadLocalForThisToolTipObject();
  }
}

 

 

2 часа назад, Xipho сказал:

Например, если у тебя есть класс базового окна, и класс окна с рамкой - выглядит, как будто у них будет очень много общих свойст, и если в данном случае ты будешь использовать композицию, то какой тогда смысл в разных классах окна?

Класс окна всего один. Он создает простое окно. Он поддерживает все что только можно сделать с окном. Создал такой экземпляр, и навесил на него все что нужно, все что он позволяет на себя навесить. Стили, полосы прокрутки, альфа канал, переопределил WM_PAINT и получил в своей функции в параметре уже готовый CompatibleDC, только и рисуй на нем.

Я примерно прикидывал, и не нашел ничего такого специфичного, чтобы не позволил сделать класс окна с окном. Потому не стал его раздваивать.

С предопределенными WinAPI контролами (Button, EditBox), тоже самое что и с окном, что хочешь, то и навесил на них.

 

Есть например и специфичные окна, как например самодельный PopupMenu. Можно было наследовать его о таким обрызом

Спойлер

Но PopupMenu не нуждается ни в Menu ни в Полосах прокрутки. Поэтому PopupMenu выведен в свой собственный класс, и наследуется не от Control класса, как например это делают Window, Button, EditBox, а наследуется сразу от GUI.

PopupMenu не нуждается в тех объектах-свойствах в которых нужнаются эти.

 

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

 

2 часа назад, Xipho сказал:

но, еще раз повторюсь, всё нужно использовать в разумных пределах.

Я запомнил этот момент. Лишний раз не нужно оверинженерить, как говорил ты и книга.

[youneuoy]

1 час назад, Antonshka сказал:

PopupMenu не нуждается ни в Menu ни в Полосах прокрутки

в c++ поддерживается множественное наследование и т.п. Мне кажется это тот случай, где его можно было бы применить. А можно было бы и не применить. Вариантов масса, просто сделай как-нибудь для начала.

 

1 час назад, Antonshka сказал:

наследуется сразу от GUI

метод update слишком размыт, а GUI, от которого наследуются виджеты - нет?😃

Изменено 2 августа, 2022 пользователем youneuoy

[Antonshka]

33 минуты назад, youneuoy сказал:

метод update слишком размыт, а GUI, от которого наследуются виджеты - нет?😃

По идее да, тоже размыто 😜. Но в случае с update я думаю что будут ложные холостые вызовы. Например если есть 100 кнопок, из которых активны только 99 . Система сделает 99 вызовов update просто так. 99 проверок if легче же для системы чем 99 вызовов?

 

38 минут назад, youneuoy сказал:

Вариантов масса, просто сделай как-нибудь для начала.

Уже сделано, мы просто теперь обсуждаем правильность сделанного. Вообще просто обсуждаем как сделано.

[youneuoy]

27 минут назад, Antonshka сказал:

99 проверок if легче же для системы чем 99 вызовов?

99 вызовов мало нагрузят систему. К тому же кнопки находятся в окнах/других элементах. Если неактивно окно, то вызовы для кнопок выполняться не должны ведь и т.п.

29 минут назад, Antonshka сказал:

Уже сделано, мы просто теперь обсуждаем правильность сделанного. Вообще просто обсуждаем как сделано.

мы не знаем как сделано, ты ведь пару кусков+пару размытых описаний запостил и всё.

[Xipho]

Оптимально будет выложить код на гитхаб в приватный репозиторий, и добавить желающих в контрибьюторы

[Antonshka]

30 минут назад, Xipho сказал:

Оптимально будет выложить код на гитхаб в приватный репозиторий, и добавить желающих в контрибьюторы

Понял, так и сделаю. Не буду ждать пока поправлю все.

Несколько дней назад я создал Github аккаунт. Раза с 10 только получилось разобраться как правильно обновлять проект. Пока не знаю как вести обсуждения, впрочем, пока не до них.

Я отправил приглашение для Xipho Github.

@Xipho можно мне написать что этот проект совместная работа с тобой? А также всеми, кто помогал в разрешении вопросов, конечно же.

 

Если у кого-то также есть желание, присоединяйтесь. Нужно ваше имя на Github, для отправки приглашения.

[youneuoy]

1 час назад, Antonshka сказал:

Нужно ваше имя на Github, для отправки приглашения

кидай, посмотрю тоже https://github.com/youneuoy

[Antonshka]

13 минут назад, youneuoy сказал:

кидай, посмотрю тоже https://github.com/youneuoy

Добавил. Я заметил у тебя в коде употребление префикса m_ (m_cheatSize).

Про свой я уж молчу.

[youneuoy]

9 минут назад, Antonshka сказал:

Я заметил у тебя в коде употребление префикса m_ (m_cheatSize)

Это не мой код🙂Я его взял у какого-то пользователя с форума когда программированию учился только и по этому шаблону наделал патчей в память. Код с утечками, недоработками и т.п., но это неважно в данном проекте(я только самые критичные проблемы поправил, чтобы оно просто всегда работало). В другом проекте я иначе это сделал, но в имеющийся перетаскивать не стал, нет желания несколько тысяч строк кода переделывать.

[Xipho]

2 часа назад, Antonshka сказал:

можно мне написать что этот проект совместная работа с тобой?

Это на твоё усмотрение )