Attila Kovacs

Except it's kingly slow and the queue will be processed right after the job is finished, also replaying every mouse / keyboard event happened meanwhile the loop was running.

You still have to call Application.Processmessages in your loops. Otherwise you have to hook in a lower level. ( I think, I would have to test to be sure if SetWindowsHookEx would work)

As your blocking task runs in a modal form with an own message loop I would not concern about calling Application.Processmessages. However, with a small addition. I would hook Application.OnMessages (as long as the blocking code runs) to handle only WM_PAINT and the messages sent to the Abort button (if any). (in this example WM_TIMER is included only for animations, and btnStart for not be stuck in down state) Of course this would also prevent the system from a restart, for that, you should watch for other messages too, and handle properly, if its a problem. procedure TfrmDoSomething.MyOnMessage(var Msg: TMsg; var Handled: boolean); begin if (Msg.hwnd = btnStart.Handle) and (Msg.Message = WM_MOUSELEAVE) then else if Msg.hwnd = btnAbort.Handle then else case Msg.Message of WM_PAINT, WM_TIMER: ; else Handled := True; end; end;

I can't see anything broken. SHIFT overrides NumLock and CapsLock. That means, with NumLock ON pressing SHIFT + 0 = pressing insert. Releasing SHIFT means, you are holding the 0 key, releasing 0 means you are releasing the 0 key, and not Insert. That's how windows works.

Interesting approach, but yes, could be.

I'm not sure about the 50 meters, but there is also https://www.delphihtmlcomponents.com/reports.html

Uwe, why am I not surprised? <o> 🙂 I should try MMX some day.

I assume you talking about every other active datasets (which could block) and not the one which is failing (which is blocked). Well, backup and start to debug with simplifying the queries. Also, compare the installed drivers on those workstations.

IIRC this could also caused by blob fields in the query, which are only fetched if needed (by default).

"Fetchall" comes to mind. If a result set of a query is only partially fetched (because of the size) it blocks the connection. http://docwiki.embarcadero.com/RADStudio/Rio/en/Fetching_Rows_(FireDAC)

Only god and google knows.

Maybe accidentally set to async mode?

Just lean back, not your fault. And it's always the installer's code which ends up in the signatures, not the RTL.

This info is actually cool. I was never paying attention to it. I was thinking the main form were the first form created any way. But with this, it's enough to write: frmYourFormsNeededToCreateIfAny := TfrmYourFormsNeededToCreateIfAny.Create(Application); frmLogin := TfrmLogin.Create(Application); if frmLogin.DoLogin then Application.CreateForm(TfrmMain, frmMain); Application.Run; or similar no need for Terminate prior to .Run;, no need for ShowMainForm := False, no unnecessary OnCreate() of the main form. however initialization and finalization will run (of course), and prepare, that adding new forms via IDE will screw up your dpr mostly every time.

I tried VB and it was too slow for me. How do you come over that everything lags?

Like in the title, if I can see and have time to read the [Parsing...] hint in the IDE code editor, the IDE just shuts down silently, without saving anything.. crashes silently. (10.1.2), Anyone else having the same issue? Sometimes multiple times in a row, sometimes no issue for days.

Before creating a bug report I wanted to ask if someone could confirm that ctrl-F4 doesn't work in CPU View since ages, or do I have some 3rd party which interfere?

Hm, thanks Uwe, this would satisfy me too, but it's not the case... 😞

@FredS What happens if you add s := Copy(s, 1, Length(s) - 1) + Copy(s, Length(s), 1); after s := TCursiveNumbers.ToText(c); in the main loop?

what is TCursiveNumbers.ToText? Does it changes the length of the string?

Mainform is always the first form you create. Make sure you are not creating the mainform or any other twice.

That means Application.ShowMainForm := False; and Application.Terminate; and Application.Run; if login fails, and you won't get a flickering mainform and you will have a clean termination of the application including calling the finalization section in the mainform.

Ok, here is the thing: Application.Terminate only sends a message to the application to terminate. It will be processed in the main Application message loop, which you can start with Application.Run. To avoid showing the mainform, set Application.ShowMainForm := False; prior to .Run;

@Mark Williams Can you see what I'm writing? Just for the record.

I'm not sure what your "exit" does, and I can't see your code, but with the code below finalization is called: if not DoLogIn() then begin Application.ShowMainForm := False; Application.Terminate; Application.Run; end;