Start for word length 8
6016 words loaded from dictionary file: ..\Dictionary\ORF3.txt
Graph was made: edges number = 871
Если вы много занимаетесь отладкой приложений под Windows — вы, возможно, слышали о таком замечательном механизме, как Image File Execution Options (IFEO). Одна из предоставляемых им возможностей позволяет отлаживать приложение в условиях, более приближенных к боевым. Записав в нужное место в реестре специальный ключик, мы можем вместо программы автоматически запускать её отладчик, позволяя ему делать свои отладочные дела. Однако кто сказал, что этот механизм (фактически — перехвата запуска чего угодно) можно использовать только в подобных целях? Эта статья вовсе не об использовании вещей по назначению.
Под катом рассказ о том, как я попытался выжать побольше из этого механизма в своих добрых целях, и какие подводные камни мне встретились на пути. А у меня тут хорошие, отборные камни.
Хей, привет. 2017 год на дворе. Даже простенькие мобильные и браузерные приложения начинают потихоньку рисовать физически корректное освещение. Интернет пестрит кучей статей и готовых шейдеров. И кажется, что это должно быть так просто тоже обмазаться PBR… Или нет?
Многие, наверное, слышали о замечательном способе решения программистских задач под названием метод утенка (rubber duck debugging). Суть метода в том, что надо сесть в ванную, расслабиться, посадить на воду игрушечного утенка, и объяснить ему суть той проблемы, решение которой вы не можете найти. И, чудесным образом, после такой беседы решение находится.
В своей прошлой статье на Хабре, где я рассказывал о разработке программы для инспектирования Wi-Fi сетей для macOS, в роли утенка оказался сам Хабр: я пожаловался на то, что нам никак не удается придумать способ реализации code blocks из Objective-C в Delphi. И это помогло! Пришло просветление, и всё получилось. О ходе мыслей и о конечном результате я и хочу рассказать.
Изучать ООП (объектно-ориентированное программирование) можно двумя способами: или прочитать сотню книжек, в которых дается голая теория об устройстве классов и принципах наследования, полиморфизма, инкапсуляции, но так ничему и не научиться, или перестать беспокоиться и попытаться на практике освоить новые приемы, переработав, к примеру, готовые коды, а лучше с нуля изготовив что-то простое, но красивое.
Во всех книгах, посвященных паскалю, delphi и lazarus (я нашел аж целых две о последнем), очень схожая часть, посвященная ООП. По этим книгам можно много узнать о том, насколько круче ООП устаревшего структурного подхода, но так и не получить достаточных навыков применения этого на практике. Конечно, любой программист, использующий визуальные IDE, уже по умолчанию использует ООП, так как все компоненты и структурные элементы визуального приложения представляют собой объекты, однако свои собственные структуры и абстракции перенести в парадигму ООП бывает очень сложно. Чтобы понять всю прелесть и оценить открывающиеся перспективы, я решил сделать небольшое приложение, которое в конечном итоге превратилось в простенький screensaver. Заодно вспомнил о существовании тригонометрии.
Приложение будет рисовать на экране в случайных местах пятьдесят полярных роз с разными характеристиками: размер, цвет, количество лепестков. Потом их же затирать и рисовать новые, и т.д. Используя принципы структурного программирования, можно, конечно, сделать обычный многомерный массив объемом на 50 и в нем сохранять все уникальные характеристики. Однако стоит вспомнить, что паскаль подразумевает строгую типизацию данных, а, следовательно, массив не может состоять их элементов с разными типами. Можно сделать массив из записей (record), но чего уж мелочиться, от записи до класса — один шаг. Вот его мы и сделаем.
procedure DllMain(dwReason: LongWord);
begin
case dwReason of
DLL_PROCESS_ATTACH:
begin
//**************************
end;
DLL_PROCESS_DETACH:
begin
//***************************
end;
end;
end;
begin
DllProc := @DllMain;
DllProc(DLL_PROCESS_ATTACH);
end. 
Delphi и C++Builder разработчики, использующие VCL не по наслышке знают о вездесущей проблеме мерцания контролов. Мерцание происходит при перерисовке, вследствие того, что сначала отрисовывается фон компонента, и только потом сам компонент.
И если в случае с наследниками от TWinControl частичным решением проблемы является установка свойства DoubleBuffered в True, что заставляет контрол отрисовываться в буфере (однако DoubleBuffered работает тоже не идеально, к прим.: контрол перестает быть прозрачным), то в случае с TGraphicControl решение с DoubleBuffered просто невозможно, из-за отсутствия у TGraphicControl окна, установка же DoubleBuffered в True у родителя не помогает, из-за того что отрисовка вложенных TGraphicControl-ов происходит уже после прорисовки родителя в буфере.
Обычно остается только одно — смириться с мерцанием, и максимально упростить отрисовку для минимизации эффекта, или использовать по возможности исключительно TWinControl-ы, что не всегда возможно и удобно.
Однажды намучившись с мерцанием, я не выдержал и решил решить эту проблему, раз и навсегда!
Как мне удалось решить проблему?
