Leaderboard

Binary DFM are devils work and must be burnt at the stake whilst vigorously waving pitchforks and shouting obscenities. Version control systems handle them poorly (not that text DFMs are far better in this regard, but, you can manage, once you move any pictures to a datamodule). Actually they are just binary blobs most of the time and will consume unnecessary storage Everything else, the other guys said

TRestRequest has also a method ExecuteAsync with handlers for successful completion and error handling (in addition to the event handlers OnAfterExecute and OnHTTPProtocolError). Depending on your specific needs it may boil down to just a simple call like this: RequestLogin.ExecuteAsync( procedure begin ShowMessage('server up'); end, True, True, procedure begin ShowMessage('server down'); end);

Your declaration of TPowerRequestType is missing a {$MinEnumSize 4} Not sure if the record should also be packed. Personally, I would add it, but the declaration from Winapi.Windows.pas is also omitting it. More Information here (German Language)

Try install from the folder where Getit save the downloaded files, with Delphi closed, solved for me. I think this happens after install it in 10.4

@Carlo Barazzetta Thank you! Your components are a must-have for High-DPI enabled applications. I would say High-DPI is a second revolution in Delphi desktop development after Unicode.

Perhaps a simple "Open as text" in the context menu of a DFM in the project manager may be sufficient.

OK, this is making more sense to me, and I can better appreciate the inconvenience.

I'm encountering this problem regularly when some component isn't installed in the IDE or is installed but in a different (usually older) version. It would be nice to simply open that dfm as text and be able to make rudimentary changes to it. Most of the time it is enough to remove or change some properties from the dfm to make it load normally. The IDE always offers to delete a property or control, but I don't trust it (and I have reasons for that). Currently I open the dfm in a text editor but that's rather inconvenient.

You are massively underestimating this 😛 If you refactor a base component other visual components dervive from, loading/opening projects might fail. I support the Idea that the ide still loads the dfm as text. Right now it does not allow me to look at it, which is cumbersome. Just like WPF in VS where I always get the XAML editor but not a visual editor when the XAML is invalid.

In this situation, it is best not to block the main thread at all. Disable the UI if you need to, but let the worker thread and main message queue run in parallel normally, and have the worker thread notify the main thread when it is finished, eg: procedure TForm2.Button1Click(Sender: TObject); var Thrd : TThread; begin Thrd := TThread.CreateAnonymousThread( procedure begin Sleep(10000); end ); Thrd.OnTerminate := ThreadFinished; Thrd.Start; // disable UI as needed ... end; procedure TForm2.ThreadFinished(Sender: TObject); begin Memo1.Lines.Add('Thread finished'); // enable UI as needed ... end;

procedure TForm9.Button1Click(Sender: TObject); var Thrd : TThread; Ret : Cardinal; HandleArray : array [0..0] of THandle; begin Thrd := TThread.CreateAnonymousThread( procedure begin Sleep(5000); Memo1.Lines.Add('End of Thread'); // Not reliable! end ); Thrd.Start; HandleArray[0] := Thrd.Handle; // The thread above is waiting for 10 seconds within itself. // We will wait for the above thread to finish before the main thread freezes while TRUE do begin Ret := MsgWaitForMultipleObjects(1, HandleArray[0], FALSE, INFINITE, QS_ALLINPUT); if Ret = WAIT_OBJECT_0 then begin Memo1.Lines.Add('WAIT_OBJECT_0'); break; end; if Ret >= (WAIT_OBJECT_0 + 1) then begin Memo1.Lines.Add('WAIT_OBJECT_0+1'); Application.ProcessMessages; continue; end; if Ret = WAIT_TIMEOUT then begin Memo1.Lines.Add('WAIT_TIMEOUT'); break; end; Memo1.Lines.Add('Else') end; Memo1.Lines.Add('Thread finish'); end; Pay attention to change the access to Memo1 from the thread. Pay attention to re-entry issue. You should probably prevent it.

The simplest option is to use either TThread.CreateAnonymousThread(), eg: uses ..., System.Classes; procedure TFrmLogin.StartLogin; begin TThread.CreateAnonymousThread( procedure var Success: Boolean; begin try RequestLogin.Execute; Success := RequestLogin.Response.Status.Success; except Success := False; end; TThread.Queue(nil, procedure begin AfterLogin(Success); end ); end ).Start; end; procedure TFrmLogin.AfterLogin(Success: Boolean); begin if Success then begin ShowMessage ('server up'); do something ... end else begin ShowMessage ('server down'); do something else ... end; end; Or similarly, TTask.Run(): uses ..., System.Threading; procedure TFrmLogin.StartLogin; begin TTask.Run( procedure var Success: Boolean; begin try RequestLogin.Execute; Success := RequestLogin.Response.Status.Success; except Success := False; end; TThread.Queue(nil, procedure begin AfterLogin(Success); end ); end ); end; procedure TFrmLogin.AfterLogin(Success: Boolean); begin if Success then begin ShowMessage ('server up'); do something ... end else begin ShowMessage ('server down'); do something else ... end; end;

Sounds like an 'Awesome' feature while entering financial data into a spreadsheet