Leaderboard

Many of us miss call stacks in Delphi and have to use heavy or commercial libs. Luckily Microsoft cares of us and provides necessary API's. Here's the unit // Stack tracing with WinAPI // (c) Fr0sT-Brutal // License MIT unit StackTrace; interface {$IFDEF MSWINDOWS} uses Windows, SysUtils; const DBG_STACK_LENGTH = 32; type TDbgInfoStack = array[0..DBG_STACK_LENGTH - 1] of Pointer; PDbgInfoStack = ^TDbgInfoStack; function RtlCaptureStackBackTrace(FramesToSkip: ULONG; FramesToCapture: ULONG; BackTrace: Pointer; BackTraceHash: PULONG): USHORT; stdcall; external 'kernel32.dll'; procedure GetCallStackOS(var Stack: TDbgInfoStack; FramesToSkip: Integer); function CallStackToStr(const Stack: TDbgInfoStack): string; procedure InstallExceptionCallStack; {$ENDIF} implementation {$IFDEF MSWINDOWS} procedure GetCallStackOS(var Stack: TDbgInfoStack; FramesToSkip: Integer); begin ZeroMemory(@Stack, SizeOf(Stack)); RtlCaptureStackBackTrace(FramesToSkip, Length(Stack), @Stack, nil); end; function CallStackToStr(const Stack: TDbgInfoStack): string; var Ptr: Pointer; begin Result := ''; for Ptr in Stack do if Ptr <> nil then Result := Result + sLineBreak + Format('$%p', [Ptr]) else Break; end; function GetExceptionStackInfo(P: PExceptionRecord): Pointer; begin Result := AllocMem(SizeOf(TDbgInfoStack)); GetCallStackOS(PDbgInfoStack(Result)^, 1); // excluding the very function GetCallStackOS end; function GetStackInfoStringProc(Info: Pointer): string; begin Result := CallStackToStr(PDbgInfoStack(Info)^); end; procedure CleanUpStackInfoProc(Info: Pointer); begin Dispose(PDbgInfoStack(Info)); end; procedure InstallExceptionCallStack; begin Exception.GetExceptionStackInfoProc := GetExceptionStackInfo; Exception.GetStackInfoStringProc := GetStackInfoStringProc; Exception.CleanUpStackInfoProc := CleanUpStackInfoProc; end; procedure UninstallExceptionCallStack; begin Exception.GetExceptionStackInfoProc := nil; Exception.GetStackInfoStringProc := nil; Exception.CleanUpStackInfoProc := nil; end; {$ENDIF} end. test project program Project2; {$APPTYPE CONSOLE} {$R *.res} uses Windows, SysUtils, StackTrace in 'StackTrace.pas'; // Demo subs procedure Nested2; begin Abort; end; procedure Nested1; begin Nested2; end; procedure Nested0; begin Nested1; end; begin try InstallExceptionCallStack; Nested0; except on E: Exception do Writeln(E.ClassName, ': ', E.Message, sLineBreak, E.StackTrace); end; Readln; end. and output

It is a nice start. But from experience, having just the raw stack addresses is still a PITA to debug. I took a similar approach in one of my projects (not using the build-in Exception.StackTrace callbacks, though), but I also output the module name that each address belongs to, and for a DLL module I also worked out the exported function name+offset based on the address. I was planning on adding logic to resolve non-DLL function names using the generated MAP file, but I didn't get that far before the project was discontinued.

Welcome to date format hell. Once you go that way, you will find out that there are many more different date formats than you ever imagined and that many of them are incompatible to each other. My favourite example: US: MM/DD/YY UK: DD/MM/YY If you have the choice always go with an international standard: ISO 8601

Because its wrong - you are handling the result of v shr 32 as if it was v div 10000000000

I wonder why you think you can't use a TDateTimePicker? Have you tried? Whence is the date if not from the user? Because anything else should already be under your total control.

Yeah, that will do it. Rendering your version unlicensed. I found this: So you can see if renaming them back (after making a copy) will work.

It seems like the latest version of ICS solved the problem. Tested with 2000 clients disconnecting / reconnecting many times, now working like a charm. Nevertheless I implemented watchdog in case service stops listening, but didn't manage to trigger it. Anyway, thanks for the tips

First of there is no 10.5 - I assume you meant 11. That's like the mother of pointless benchmarks. We know that default MM is prone to problems with heavy multithreading. Test with FastMM5 because that has addressed that issue. For using TBB, I think it was mentioned in another thread that also the memory footprint should be considered. Part of the improvement might come from the better system routines such as Move (FillChar has already been improved in 11.1) - I have been working on an improved version but I am afraid we will not get it before Delphi 12. Also - I think I mentioned this before: in the age of supply chain attacks and malicious code being distributed via open source platforms, I would be very careful about using some binaries. You mentioned before how you compiled them: why are you reluctant to post the code on GitHub so everyone can compile it themselves?

Instead of hijacking this thread with yet another off-topic wall of text about why Embarcadero sucks and Delphi is doomed, maybe you could start your own thread? This was in reponse to the OP who posted a bunch of suggestions for delphi from a Developer's perspective. There have been tons of such posts here and elsewhere over the past decade, some quite eloquent and some more debatable. This discussion forum is dominated by DEVELOPERS, like you and I. We have our perspectives, we love Delphi and we all pretty much would LOVE to see it continue to grow and expand and get better. But after all of the proposals, submissions through official channels, and every conceivable attempt at begging, prodding, and encouraging Embt to do different things, it has become painfully obivous that ... they just are not interested. They don't "suck". They are operating in the best interests of their SHAREHOLDERS. We are DEVELOPERS -- NOT SHAREHOLDERS! SHAREHOLDERS want PROFITS while we DEVELOPERS want MORE FEATURES! Any overlap is mostly coincidence, driven primarily by Microsoft and Apple. Not us Developers. The CUSTOMERS paying the bills want LOW-RISK INVESTMENTS. Everywhere I've worked in the past 10+ years has had one thing in common: they only want me to touch code that HAS TO BE CHANGED. They don't want me to use NEW FEATURES. They don't want REFACTORING. They don't want the code "cleaned-up". A couple changed their policies that require every line that shows up as changed in the change logs must relate back to a specific trouble ticket. "Refactoring" for its own sake was not allowed. They DO want: simple, straightforward changes that use existing coding patterns and language features found in D7-era code (around when the apps were built) so it looks and behaves the same as all the rest of their code. The last place I worked, most of the core code they used in production had not been touched since 2007. I was told on my first day, "DO NOT TOUCH ANY OF THE CODE WITHOUT MY APPROVAL!" I found and documented several bugs, and was told point-blank, "you must be wrong, this code has not changed in over a decade; there are no bugs in it." Except it went from running in Win XP to Win 7 to Win 10, and now it does weird and unexpected stuff sometimes that I captured on camera. They didn't want to hear about it. I asked one Dept head (at a State Agency) why they don't rebuild their code in the latest version of Delphi using more contemporary stuff. His answer: Because their State's CTO basically said, "All new software development will be done in C#/.NET." Period. End of story. Seems their Legislature authorized a 10-year agreeement with Microsoft to provide them with everything they'd need, and that was that. I've heard similar things from multiple places I've worked, both public and private. This is NOT MY OPINION! I personally don't think Embt "sucks". I personally don't think Delphi is "doomed". I think Delphi's evolution is being dictated by two things: (1) SHAREHOLDERS who are only interested in profits; and (2) CUSTOMERS who are interested in REDUCING RISKS IN EXISTING PRODUCTION CODE. I love Delphi. I love the Developer community. And I don't see Embt's focus on Delphi changing any time soon to make it more aligned with that of Developers other than coincidentally. For example, I've seen dozens of proposals for language extensions, many of which would be useful to most Delphi Deverlopers on an almost daily basis. But the only two that were added to D11 ... I've never ever seen discussed. I was honestly totally surprized when inline 'var' declarations appeared in the language. That's a marginally useful feature to me, and not one I would have ever expected to see added. But its introduction broke a bunch of far more useful things in the IDE. They would have been better off not introducing it until everything in the IDE worked properly with it. D11 reportedly hasn't fixed anything that was in D10.4.2. The last place I worked, we were asked after D10.3 came out if there was anything added to the language that might justify the risk of upgrading everything. Inline vars were all there was, and the consensus was that they did not justify anything, especially because they broke a lot of stuff in the IDE. Unfortunately, the company went ahead and paid the maintenance fee anyway. Why? Because the cost of NOT paying was more risky and costly. Yet we're still waiting for MANY VERY USEFUL ADDITIONS to the language! This is how the game has been rigged: customers (companies) will continue to pay their maintenance fees whether they use what's been added or not. And SHAREHOLDERS LOVE THAT! Developers ... not so much.

if Attribute Is MyAttributeOne then vs if (Attribute Is MyAttributeOne) then