Leaderboard

I can't believe I just made a case for Application.ProcessMessages after 25 years of trying to get people to stop using it 🤦‍♂️

Also see: https://www.indyproject.org/2021/02/10/links-to-old-indy-website-pages-are-currently-broken/ I never had free time to fix it.

Indy Wiki is here, and is working: https://github.com/IndySockets/Indy/wiki And if you have Rad Studio installed you have the offline documentation (Help/Third-Party Help/Indy Library Help)

Yes it will. The reason it will not pump messages is that it's not being given an opportunity to do so. This is the equivalent: Button.Enabled := False; Sleep(1000); Button.Enabled := True;

It's because you aren't processing any windows messages while the panel is disabled, so when you enable it again the mouse click message is still waiting in the message queue.

Unlike VCL, FMX hides Win32 window messages from you. And, it ignores most window messages in general, it only handles a handful of select messages for its own purpose. Since you are forcing the Taskbar button to appear on a sub-Form, you will have to manually subclass the Form's window so you can handle window messages like WM_ACTIVATE, eg: type TSubToolBarForm = class(TForm) private ... {$IFDEF MSWINDOWS} protected procedure CreateHandle; override; {$ENDIF} ... end; ... {$IFDEF MSWINDOWS} uses Winapi.Windows, Winapi.Messages, Winapi.CommCtrl, FMX.Platform.Win; function SubToolBarSubclassProc(Wnd: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM; uIdSubclass: UINT_PTR; dwRefData: DWORD_PTR): LRESULT; stdcall; begin case uMsg of WM_NCDESTROY: begin RemoveWindowSubclass(Wnd, SubToolBarSubclassProc, uIdSubclass); end; WM_ACTIVATE: begin if wParam in [WA_ACTIVE, WA_CLICKACTIVE] then begin SetFocus(Wnd); //SetForeGroundWindow(Wnd); //BringWindowToTop(Wnd); end; end; end; Result := DefSubclassProc(Wnd, uMsg, wParam, lParam); end; procedure TSubToolBarForm.CreateHandle; var Wnd: HWND; ExStyle: LONG_PTR; begin inherited; Wnd := FormToHWND(Self); ExStyle := GetWindowLongPtr(Wnd, GWL_EXSTYLE); SetWindowLong(Wnd, GWL_EXSTYLE, ExStyle or WS_EX_APPWINDOW); SetWindowSubclass(Wnd, SubclassProc, 1, DWORD_PTR(Self)); end; {$ENDIF}

No, they were merged into Indy's master code about a month after the release of 12.2. https://www.indyproject.org/2024/10/20/sasl-oauth-support-finally-added-to-master/

This raises the question why you need absolute path names for the dcu output in the first place. IIRC that is a no-go for build systems and should be avoided in development systems, too. Although I also use alternative dcu output paths (usually to separate dcu output for different projects in a project group in addition to separate platforms and build configurations), all of these are relative to the project. As I often have multiple work trees of a repo, I would open a can of worms when all of them were using the same dcu output folder.