Attila Kovacs

if it's a 24bit bitmap you could try with TBitmap's ScanLine

@Stéphane Wierzbicki It's not that easy as it sounds. What if a column name changes? Is it a new column or just the name changed? What if a datatype changes? etc..etc.. Anyway, I can't even imagine what can you do with this kind of data in an SQL Server where columns are occasionally added. Either you should unpivot the excel before importing it or storing the file in a blob.

In windows 10, the title bar gets smaller in maximized state as in any other states. Not just the IDE, every application. And this is not the issue. The issue is, somebody decided to put controls onto the title bar. This is such a no-go, antipattern, etc.... every kid knows that. Now you see why.

procedure AddTask(aAction: TTaskAction; aTask: TTask); overload; // Execute aTask immeditaly Does it make sense? AddTask(taQueueTaskOnly, lTask); // Execute aTask immediately

Strange, if you look at your original example, the proper function names are already there, at the end of each line, in the comments.

Yeah, it would be great.

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?