Xipho

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 часов назад, ComCrow сказал:

Мы знаем, что картинка начинается обязательно с 0x89, 50, 4E, 47, и обязательно заканчивается на 42, 60, 82

Примерный алгоритм в картинке под спойлером. Укладываемся в один проход. Этот алгоритм довольно медленный, есть варианты его распараллелить

Ну Ну и да, байты надо проверять не вложенными условиями, это бред вообще, а в одном. Типа

if (t[i] == 0x89 && t[i+1] == 0x50 && t[i+2] == 0x4E && t[i+3] == 0x47) {
  //тут включаем режим записи и все такое
}

Это базовые вещи на подумать. И еще на подумать - есть варианты реализации побыстрее и получше.

%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3B%22%20edge%3D%221%22%20source%3D%223%22%20target%3D%2212%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%223%22%20value%3D%22%D0%9F%D0%B5%D1%80%D0%B5%D0%B1%D0%B8%D1%80%D0%B0%D0%B5%D0%BC%20%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%B5%20%D0%B8%D1%81%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B3%D0%BE%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0%20%D0%BF%D0%BE%D0%B1%D0%B0%D0%B9%D1%82%D0%BE%D0%B2%D0%BE%22%20style%3D%22rounded%3D0%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22160%22%20y%3D%2280%22%20width%3D%22200%22%20height%3D%22100%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%224%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D1%3BexitY%3D0.5%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%226%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%22600%22%20y%3D%22265%22%2F%3E%3CmxPoint%20x%3D%22600%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%225%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%226%22%20target%3D%2222%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%226%22%20value%3D%22%26lt%3Bspan%26gt%3B%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%20%26lt%3Bbr%26gt%3B%2B3%20%D1%81%D0%BB%D0%B5%D0%B4%D1%83%D1%8E%D1%89%D0%B8%D1%85%20%26lt%3Bbr%26gt%3B%D1%80%D0%B0%D0%B2%D0%BD%D1%8B%26amp%3Bnbsp%3B%26lt%3Bbr%26gt%3B%26lt%3B%2Fspan%26gt%3B0x89%2C%2050%2C%204E%2C%2047%26lt%3Bspan%26gt%3B%3F%26lt%3B%2Fspan%26gt%3B%22%20style%3D%22rhombus%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22400%22%20y%3D%22187.5%22%20width%3D%22159.31%22%20height%3D%22155%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%227%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%229%22%20target%3D%2216%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%228%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3B%22%20edge%3D%221%22%20source%3D%229%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2280%22%20as%3D%22targetPoint%22%2F%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%2280%22%20y%3D%22520%22%2F%3E%3CmxPoint%20x%3D%2280%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%229%22%20value%3D%22%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%20%26lt%3Bbr%26gt%3B%2B2%20%D1%81%D0%BB%D0%B5%D0%B4%D1%83%D1%8E%D1%89%D0%B8%D1%85%26lt%3Bbr%26gt%3B%D1%80%D0%B0%D0%B2%D0%BD%D1%8B%26amp%3Bnbsp%3B%26lt%3Bbr%26gt%3B42%2C%2060%2C%2082%3F%22%20style%3D%22rhombus%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22178.8%22%20y%3D%22450%22%20width%3D%22162.4%22%20height%3D%22140%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2210%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2212%22%20target%3D%2214%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2211%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BentryX%3D0%3BentryY%3D0.5%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2212%22%20target%3D%226%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2212%22%20value%3D%22%D0%A0%D0%B5%D0%B6%D0%B8%D0%BC%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8%20%D0%B2%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%3F%22%20style%3D%22rhombus%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22200%22%20y%3D%22210%22%20width%3D%22120%22%20height%3D%22110%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2213%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2214%22%20target%3D%229%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2214%22%20value%3D%22%D0%9F%D0%B8%D1%88%D0%B5%D0%BC%20%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%20%D0%B2%20%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22200%22%20y%3D%22360%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2215%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2216%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%22260%22%20y%3D%22700%22%2F%3E%3CmxPoint%20x%3D%2280%22%20y%3D%22700%22%2F%3E%3CmxPoint%20x%3D%2280%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2216%22%20value%3D%22%D0%92%D1%8B%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D0%B5%D0%BC%20%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8%2C%20%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D0%B2%D0%B0%D0%B5%D0%BC%20%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22200%22%20y%3D%22620%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2217%22%20value%3D%22%D0%94%D0%B0%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22260%22%20y%3D%22320%22%20width%3D%2230%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2218%22%20value%3D%22%D0%94%D0%B0%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22260%22%20y%3D%22590%22%20width%3D%2230%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2219%22%20value%3D%22%D0%9D%D0%B5%D1%82%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22310%22%20y%3D%22240%22%20width%3D%2240%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2220%22%20value%3D%22%D0%9D%D0%B5%D1%82%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22550%22%20y%3D%22270%22%20width%3D%2240%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2221%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2222%22%20target%3D%2223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2222%22%20value%3D%22%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D1%82%D1%8C%20%D0%B2%D1%8B%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%84%D0%B0%D0%B9%D0%BB%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22419.66%22%20y%3D%22370%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2223%22%20value%3D%22%D0%92%D0%BA%D0%BB%D1%8E%D1%87%D0%B8%D1%82%D1%8C%20%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22419.66%22%20y%3D%22460%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2224%22%20value%3D%22%D0%94%D0%B0%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22480%22%20y%3D%22340%22%20width%3D%2230%22%20height%3D%2220%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2225%22%20style%3D%22edgeStyle%3DorthogonalEdgeStyle%3Brounded%3D0%3BorthogonalLoop%3D1%3BjettySize%3Dauto%3Bhtml%3D1%3BexitX%3D0.5%3BexitY%3D1%3BexitDx%3D0%3BexitDy%3D0%3BentryX%3D0.5%3BentryY%3D0%3BentryDx%3D0%3BentryDy%3D0%3B%22%20edge%3D%221%22%20source%3D%2226%22%20target%3D%223%22%20parent%3D%221%22%3E%3CmxGeometry%20relative%3D%221%22%20as%3D%22geometry%22%3E%3CArray%20as%3D%22points%22%3E%3CmxPoint%20x%3D%22480%22%20y%3D%22620%22%2F%3E%3CmxPoint%20x%3D%22600%22%20y%3D%22620%22%2F%3E%3CmxPoint%20x%3D%22600%22%20y%3D%2260%22%2F%3E%3CmxPoint%20x%3D%22260%22%20y%3D%2260%22%2F%3E%3C%2FArray%3E%3C%2FmxGeometry%3E%3C%2FmxCell%3E%3CmxCell%20id%3D%2226%22%20value%3D%22%D0%97%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D0%B2%20%D1%84%D0%B0%D0%B9%D0%BB%20%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B9%20%D0%B1%D0%B0%D0%B9%D1%82%22%20style%3D%22whiteSpace%3Dwrap%3Bhtml%3D1%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22419.65999999999997%22%20y%3D%22540%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E

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

Я бы остановился на таком варианте, если он допустим. Он мне вполне нравится

Он, разумеется, допустим. Но, как по мне, компонент должен "рисовать себя сам". И тогда у тебя получится очень простая иерархия вызовов. Кто-то (система) у родительского окна вызывает метод Draw, родительское окно у всех своих дочерних компонентов вызывает этот же метод, и так по цепочке до самого нижнего компонента. А тут у тебя получается то, о чем я говорил - размазывание ответственности. По сути, родительскому компоненту незачем знать детали отрисовки дочерних компонентов. Каждый отвечает сам за себя. Снова делаю отсыл к классу Glyph из книги "банды четырех". Там прямо очень четко это объяснено.

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

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

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

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

Как схлопнется три условия, если лучше проверять условия не в методах рисования, и перед их вызовом

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

Да, по поводу "как схлопнется три условия". Смотри, я увидел в твоем коде, что во всех этих трех условиях код практически одинаковый. Следовательно, я бы его схлопнул примерно как-то так (псевдокодом)

void checkAndDrawTooltipItem(ToolTipItem &item) {
     if (item != NULL) {
          dynamicTextYOffset = item.rect.top;
          ...
          DrawToolTipTexts(item.data)
     }
}

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

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

Сравнивая с тем, что выдают уже готовые hex-редакторы обнаружил, что к таким числам прибавляется 256

https://en.wikipedia.org/wiki/Two's_complement

По остальному - я вообще ничего не понял, если честно. Можешь алгоритм текстом расписать?

Пока единственное, что могу предложить - не читай файл в память, а делай его отображение на память https://docs.microsoft.com/ru-ru/windows/win32/memory/creating-a-file-view

По-хорошему, в метода не должно быть "побочных эффектов". И если задача метода нарисовать кнопку, то проверять, надо ли ее вообще рисовать - выглядит как не его ответственность.

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

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

Если у тебя и сам if состоит из одного выражения, и else из одного - тогда да, смысла ставить нет, в других случаях - смысл есть, чтобы было единообразие кода. Я не устану повторять - в идеале код должен читаться, как книга. Из-за этого мне синтаксис Rust не очень нравится - его местами тяжело читать из-за его макроконструкций.

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

Не знаю, нормально так или нет.

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

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

У тебя тоже есть занятные примеры в коде. 😊

Это же не мой репозиторий, это форк, посмотри внимательно ))

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

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

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

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

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

Надо посидеть, подумать, прикинуть архитектурно как это разрулить. Можно глянуть с точки зрения паттернов.

У нас на канале есть несколько видео о том, как отделять игрока от врага. Рекомендую их посмотреть.

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

Короткие функции, занимающиеся только рисованием.

Пробегусь чисто поверхностно:

1 - нет фигурных скобок. Ухудшается чтение. Можно вынести все условие целиком в отдельный действительно короткий метод.

2, 3, 4 - вынести в отдельный метод, завести сущность, характеризующую рисование для этого метода, и сразу три условия схлопнется.

Типичный перегруз. Ошибки:

1. Опять местами отсутствуют операторские скобки. Да, там, где в условии одно действие, они не являются необходимыми, но для упрощения читаемости кода их всё равно рекомендуется указывать
2. Условие, вложенное в условие, вложенное в цикл, вложенный в условие, вложенное в цикл - мозг не сломался, не? Разбить на маленькие приватные методы для упрощения читаемости.

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

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

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

Это два метода для рисования

Ёшки-матрёшки! А говорил, что "Чистый код" прочитал...

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

1. Картинки надо убирать под спойлер. 

2. Тема названа не по правилам

3. На картинках ничего не видно. 

По первым двум пунктам на первый раз устное предупреждение.

Урок на канале по взлому шифрованных значений смотрел? Картинки битые, если что.

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

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

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

Например, сторонний поток читает HICON, и в это же время, главный GUI поток по какой-то причине его изменяет

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

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

Я пытался заранее разобраться с многопоточностью.

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

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

Примерное представление как должна быть построена библиотека у меня уже есть. Хотя и сомнения есть. Например из-за частого использование friend class. Но без него, мне кажется, придется писать кучу геттеров и сеттеров.

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

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

Если будет желание и интерес, посмотри пожалуйста. Вместе посмеемся

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

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

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

Ты путаешь теплое с мягким. Акторы - это не дизайн паттерн. Это модель программирования. Многопоточность и акторы - это тоже не совсем друг про друга. Тут, скорее, при многопоточности акторная модель удобна тем, что не существует общих частей данных, а значит нет рисков словить состояние гонки. Но при этом программирование акторов несет в себе большой оверхед по количеству кода, который необходимо написать, потому к этому нужно подходить с умом. При грамотном подходе с помощью акторов можно строить очень крутые легко масштабируемые системы. Но если у тебя суть много поточности состоит именно в том, чтобы передавать/получать состояния между основным потоком и остальными - тебе за глаза хватит семафоров, мьютексов, и, на худой конец, очередей.

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

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

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

И еще, мне кажется, тебя захлестнуло волной новых знаний, и ты начинаешь оверинжинирить там, где это совершенно ни к чему. Постарайся пройти путь от нечеткой постановки задачи (запилить кнопку) до деталей реализации архитектуры. И не забывай, что в идеале программировать надо интерфейсами, чтобы потом можно было без проблем запиливать столько реализаций, сколько понадобится. В этом плане очень хороша книга по паттернам от "банды четырех". Ее я тоже скидывал, вот она тоже обязательна к прочтению после ознакомления с самими паттернами. В книге "банды четырех" очень хорошо показана применимость паттернов в различных ситуациях, с которыми сталкиваются кодеры. И у нее, кстати, вполне вменяемый перевод на русский, я ее как-то не так давно перечитывал, когда на русском она мне попалась. Читал вот эту редакцию https://www.litres.ru/dzhon-vlissides/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-16419747/

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

Я с некоторого времени вообще не могу читать русские

Потому что переводы, как правило, корявые. Есть книги хорошо вылизанные. Например, переводы книг серии HeadFirst - шикарнейшие книги в английском варианте, и весьма достойно переведены на русский. Одна из них, которую я всегда джунам рекомендую наравне с "Чистым кодом" от дядюшки Боба - это "Паттерны проектирования" серии HeadFirst - более крутого разжевывания паттернов для новичков я не встречал. Впрочем, я вроде эту книгу уже упоминал.

Оставлю еще раз тут линк на всякий случай https://www.oreilly.com/library/view/head-first-design/0596007124/

О, у них обновленная версия появилась, надо будет глянуть https://www.oreilly.com/library/view/head-first-design/9781492077992/

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

Почитал "Чистый код", почитал про паттерны. Заново переписываю уже написанное.

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

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

лучше использовать только один поток для управления всем GUI

Всё так, да. Обычно так и делается - есть главный поток приложения, в нем управление GUI осуществляется, а вся остальная логика - в других потоках с уведомлением GUI, или с системой событий, как во фреймворке Qt, например.

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

Надеюсь что план правильный.

Правильный

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

А согласно книге, они есть признак грязного кода.

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

Привет! А расскажи подробнее, как ты пытался

В 06.07.2022 в 19:27, DragonForce сказал:

То-есть я должен был написать - "Дайте мне готовое решение как вызывать WINAPI функции в AutoAsm"?)

1. То есть (без дефиса)

2. Ты никому ничего не должен на нашем форуме

3. В свою очередь, на форуме тоже тебе никто ничего не должен

4. Если ты хочешь получить конкретный ответ, ты формулируешь вопрос максимально конкретно. 

5. Сформулировал неправильно - получил неправильный ответ.

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