From the what-were-they-thinking-dept.
From the what-were-they-thinking-dept.
...
if (some condition) then
begin
Application.ProcessMessages;
Sleep(1000);
end;
...
...
if (some condition) then
begin
Application.ProcessMessages;
Sleep(1000);
end;
...
When I find something like that I usually call it "integrated potential for performance improvement" :)
ReplyDeleteStefan Glienke LOL
ReplyDeleteGot an explanation from my co-worker.
Thing is, we have some panels which are expanded when you enter them and reduced when you exit. A poor man's layout manager from the days of 640x480 monitors.
If a panel is supposed to be read only (the "some condition") then they actually wanted the panel to stay expanded for a second so the customer could see what's in it, before moving the focus elsewhere, forcing the panel to reduce in size again.
Still think the code is... yeah.
There was no comment explaining the purpose of the code?
ReplyDeleteThe explanation makes sense, but... it's not the way to do it, is it :)
David Millington HAH, you're funny you!
ReplyDeleteNo of course no comments. I assumed it was junk code and removed it, that's when I got the explanation.
Good way for splash screen when your PC is extremely robust :)
ReplyDeleteSuch codes always related to UI/UX. Removing those sometimes no harm, but "bad" user experience. Of course, there are some better ways to implement instead of those. ;)
ReplyDeleteAlmost all bug rates can be reduced with adequate amounts of sleep () calls
ReplyDeleteThe old code, the old style and the old mistakes... :)
ReplyDeleteProbably this is a part from a big procedure - with many and many lines of code. No events and so on... Usually - such a code is in the main thread of the programs and most probably the reason is to wait for something (the result from something which is maintained in the other thread or other program) and at the same time, the program does not seem frozen.
Or... in a procedure which is in awaiting the outcome from the synchronous process. For example - the results from the sensors of some machine which were not returned immediately. But... if this is the same case (and in this case) - the value for the "sleep" method (1000) also is not ok. So... this method...
:)
Maybe there has other reason?
What did you do with this code?
- Replace the code with something else?
- Just delete this... ?
- Rewrite the logic in the new... ?
The method "delete" - usually is not a good idea. (from my practice)
:)
In my case, the routine this call was in was called from an event handler, and the Application.ProcessMessages caused recursion.
ReplyDeleteI solved it by using my "async post" component, just a trivial little thing which takes an anonymous procedure, posts a window message to itself and executes the procedure in the message handler. I then called this horrible method "async", so it's executed after the event handler was finished.