Posted by jpluimers on 2013/05/21
One of the things you must be careful with is reentrancy in your application through a message loop.
The most obvious way is Application.ProcessMessages: it will loop until all messages from the Windows message queue are processed, whether your application is ready for them or not.
A less obvious way is because of modal dialogs or forms. They have their own message loop which might cause global reentrancy in your application (for instance through TTimer objects).
That was the case for this problem: stack overflow with repeated DispatchMessageW in the call stack.
A couple of ways to try to avoid these issues:
- Don’t cause a secondary message loop.
You can refrain from calling Application.ProcessMessages, but you cannot always avoid modal dialogs.
- Protect each of your event handlers by disabling the path to it as soon as it gets called.
This means disabling the Enabled property for instances of TTimer, TControl, TAction, or other objects that cause events.
via: windows – stack overflow with repeated DispatchMessageW in the call stack – Stack Overflow.
Posted in Delphi, Development, Software Development | 2 Comments »
Posted by jpluimers on 2013/05/16
For 10 months ago, Iris started Asking a ‘stupid’ question, every day for 365 days.
Virtually all of them very valid questions that remind me of various stages in my software career, and will remind me during the stages still to come.
Her motto is “there is no such thing as a stupid question”.
I agree, and would go even further: keep the questions coming every day of your life, as it is the only way of learning.
via: For 10 months ago, Iris started Asking a ‘stupid’ question, every day for 365 days ».
Posted in Development, Software Development | 1 Comment »
Posted by jpluimers on 2013/05/15
It is unwise to pass objects allocated in one framework over a DLL boundary to a different framework.
In the case of Using C dll in delphi return nothing, someone tries to pass an Interface to some memory in the C side over to Delphi.
Unless that interface is COM based, don’t do that!
In a more general way: don’t pass memory allocated on the DLL side over to the client side, no matter what kind of client you have.
From the DLL, either pass simple types, or fill buffers allocated at the client side.
via: Using C dll in delphi return nothing – Stack Overflow.
Posted in Delphi, Delphi 1, Delphi 2005, Delphi 2006, Delphi 2007, Delphi 2009, Delphi 2010, Delphi 3, Delphi 4, Delphi 5, Delphi 6, Delphi 7, Delphi 8, Delphi x64, Delphi XE, Delphi XE2, Delphi XE3, Development, Software Development | 5 Comments »
Posted by jpluimers on 2013/05/14
I had some notes on Delphi WSDL and SOAP peculiarities somewhere, but I misplaced them.
Luckily, I found some links that explain most of my notes well:
Posted in Delphi, Software Development, Development, SOAP/WebServices, Delphi XE2, Delphi 2007, Delphi 2010, Delphi XE, Delphi 2009, Delphi XE3 | Leave a Comment »
Posted by jpluimers on 2013/05/09
Posted in .NET, C++, Cloud Development, COBOL, CommandLine, Delphi, Development, Fortran, iSeries, Java, Pascal, RegEx, Scripting, Software Development, Web Development, xCode/Mac/iPad/iPhone/iOS/cocoa | 3 Comments »