Interesting question: If you had the choice between removing a call to Application.processMessages leading to a non-responsive application which some of your users terminated on you, and told you was crashing, would you put the call back in, or would you persist, even if it means rewriting a million lines of already unstable code to add multi-threading, or would you just go home, and put your head in your hands and cry?
Well, I'd push for the refactor. But I'd get shot down because my product is in maintenance mode: bug fixes and regulatory changes only. Then I'd go home and cry.
@Warren: Unless there is time for a major mass refactoring, I would invoke the programmers' Hippocratic Oath (first, do no harm) and try to untangle things in a logical manner that doesn't impact production (much).
Lol, that makes it sound like you have no functions procedures, or classes, that all your code is in the dpr, the the use of labels is used to simulate functions and procedures. the horrors.
Nick Hodges Having a lot of ProcessMessages in an application is the sign that the developer used asynchronous, event driven, functions but didn't know how to deal with asynchronous and event driven programming. So he end up building all kind of wait loops calling ProcessMessages waiting for some event or flag to be set and then continue. Another possibility is not knowing how Windows painting works and have a lot of cases where his forms are not updated and hence he calls ProcessMessages so that the WM_PAINT message get processed.
François Piette Unfortunately, the trade-off is that instead of dealing with async events, these code bases are wide open to reentrancy issues, and if the code Nick Hodges is dealing with is anything like mine, absolutely no attempt was made to deal with them. Or worse, even more Application.ProcessMessages calls are made to attempt to deal with them when issues do pop up.
Shame on you! ;-)
ReplyDeleteGood for you, all your messages will be processed much faster. ;)
ReplyDeleteHey, I didn't write it! ;-)
ReplyDeleteWell, at least there no doubt those messages are getting processed? :)
ReplyDeleteSo, your app self mostly does nothing :)?
ReplyDelete662 in mine. What do I win? :-(
ReplyDeleteOh, and we've exposed it in the scripting interface for our product, so our customers might be making even more use of it.
Interesting question: If you had the choice between removing a call to Application.processMessages leading to a non-responsive application which some of your users terminated on you, and told you was crashing, would you put the call back in, or would you persist, even if it means rewriting a million lines of already unstable code to add multi-threading, or would you just go home, and put your head in your hands and cry?
ReplyDeleteWell, I'd push for the refactor. But I'd get shot down because my product is in maintenance mode: bug fixes and regulatory changes only. Then I'd go home and cry.
ReplyDeleteThat has to be a world record!
ReplyDelete@Warren: Unless there is time for a major mass refactoring, I would invoke the programmers' Hippocratic Oath (first, do no harm) and try to untangle things in a logical manner that doesn't impact production (much).
ReplyDeleteLol, that makes it sound like you have no functions procedures, or classes, that all your code is in the dpr, the the use of labels is used to simulate functions and procedures. the horrors.
ReplyDeleteNick Hodges Having a lot of ProcessMessages in an application is the sign that the developer used asynchronous, event driven, functions but didn't know how to deal with asynchronous and event driven programming. So he end up building all kind of wait loops calling ProcessMessages waiting for some event or flag to be set and then continue.
ReplyDeleteAnother possibility is not knowing how Windows painting works and have a lot of cases where his forms are not updated and hence he calls ProcessMessages so that the WM_PAINT message get processed.
François Piette Unfortunately, the trade-off is that instead of dealing with async events, these code bases are wide open to reentrancy issues, and if the code Nick Hodges is dealing with is anything like mine, absolutely no attempt was made to deal with them. Or worse, even more Application.ProcessMessages calls are made to attempt to deal with them when issues do pop up.
ReplyDeleteLars Fosdal You wish! Sadly, I am certain it is not. Trust me. ;)
ReplyDeleteI wrote an article about that subject: http://francois-piette.blogspot.be/2013/11/what-is-processmessages.html
ReplyDelete