![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}
Anders Melander
-
Content Count
2815 -
Joined
-
Last visited
-
Days Won
153
Everything posted by Anders Melander
-
Check If File is what he claim to be
Anders Melander replied to mazluta's topic in RTL and Delphi Object Pascal
Bike shedding For example like this: https://github.com/graphics32/graphics32/blob/b45d1108a8f57b66739731e952f81e2636c63abd/Source/GR32.ImageFormats.pas#L386 Example of use: const FileSignaturePNG: AnsiString = #$89#$50#$4e#$47#$0d#$0a#$1a#$0a; FileSignaturePNGMask: AnsiString = #$ff#$ff#$ff#$ff#$ff#$ff#$ff#$ff; ... function TImageFormatAdapterPNG.CanLoadFromStream(AStream: TStream): boolean; begin Result := CheckFileSignature(AStream, FileSignaturePNG, FileSignaturePNGMask); end; -
Good luck and please don't keep us informed about how it goes.
-
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
I can't see that they do. Here's the TLDR as I read it: Allen is saying that you shouldn't (mindless or not) use FreeAndNil to solve logic/design bugs and AFAICT nobody is disagreeing with that. Primoz and David are saying that they are using it to find stale reference bugs. Allen's suggestion to use a debug memory manager instead isn't valid because you can't do that on a production system, as Primoz also points out. -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
Okay, now I understand what you meant. Yes, it's true that I'm trading the ability to catch one problem for another. However, the problem you are describing does not seem to be one that we are experiencing much if ever, so I'll take that trade. Regardless, we have made an active choice to use FreeAndNil this way. Not because we don't know any better but because we have a specific (recurring, I might add) problem that it helps us solve. I totally get the argument against just mindlessly using it CCP style but I can't really see how that applies to how we use it. I'd still like to know about these alternatives I should be using though... Well, that's nice but no that's not what we are discussing. I gave an example of how and why we used it and you said that that usage had been "debunked". -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
I have not claimed otherwise. It's not a magic "find all your bugs" tool. It's a "better than nothing" tool. Again, you are arguing against real world experience on actual code. I don't see the point. I understand it and no, (roses are red, violets are blue) it does not answer my question and neither did you. Such as? Debug memory managers are not suited for this use case; They can not be used in production code because of their overhead. FreeAndNil has practically no overhead. Again, I never claimed otherwise. Sometimes is better better than never. If there was a better alternative I would happily use that but I'm not hearing any. That's fine. In our code we make our intent clear by documenting it: With comments in the code where we rely on the order of nil and free. With a section in our development guidelines and style guide about all the other cases; When, why, and how and when not to use it. -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
That's a pretty unnuanced statement. One could just as easily, and just as unnuanced, argue that not using it is CCP. If you use something, with a specific purpose, how is that CCP? -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
Oh really? It appears to me that you are arguing a theoretical standpoint against the actual real world experience I have with finding stale object pointers using FreeAndNil. Yes, that's the point. Did anyone claim otherwise? It will succeed because it has been designed to do so. How is that relevant to FreeAndNil? What second time? What logic error? What are you even talking about? All this focus on free is pretty irrelevant to my use of FreeAndNil. I'm obviously not using it to guard against double frees because it doesn't do that. I'm using it to catch access though stale object pointers. End of story. I like to think that I actually know pretty well what I'm doing but I get the impression that you imagine I code by just throwing stuff against the wall to see what sticks. -
Virtual class methods and properties
Anders Melander replied to pyscripter's topic in RTL and Delphi Object Pascal
Yes. We now know Marco can read the help. Beyond that I don't know what we learned. Maybe that they don't have any compiler engineers at hand since the product manager had to do first level support and guess about the work required. The issue was filed as a New Feature but treated as a Bug report. Not impressed. -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
Real life race condition :-) -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
Instead of FreeAndNil implying a certain pattern I think it would be better to explicitly state, in a comment, when and why a certain behavior is expected. The projects I'm working on right now has something in the neighborhood of 200 calls to FreeAndNil in it. All except two are there to catch stale pointers; FreeAndNil gives us a nice AV that we can easily debug. Free would most likely give us a sporadic random error somewhere else. The two remaining cases are in a framework where we need a container var to be nilled before the object is destroyed. I won't go into why it's necessary; I'm sure you know the pattern. Anyway, for these two cases, the comments in the code clearly document why the FreeAndNil pattern is necessary. This is an old project and the introduction of FreeAndNil, where it makes sense of course, has helped us catch and eliminate countless bugs. Before I took over as the lead the code was littered with hundreds of empty try..except blocks simply because they had given up on trying to find the cause of the exceptions. -
TDirectory - file lock out on Win 10 LTSC
Anders Melander replied to Roger Cigol's topic in General Help
Kudos to @Kas Ob. 🎖️ -
Guidance on FreeAndNil for Delphi noob
Anders Melander replied to Paul Dardeau's topic in RTL and Delphi Object Pascal
FWIW, here's an example of improper use of FreeAndNil causing a race condition because a context switch happened between between the nilling and the free: https://supportcenter.devexpress.com/ticket/details/t812550/an-av-occurs-if-the-spell-checker-whose-usethreadedload-property-is-set-to-true-reloads -
Default() and subrange types
Anders Melander replied to Der schöne Günther's topic in RTL and Delphi Object Pascal
Don't expect it to be "fixed". The best you can hope for is that it is documented. The current behavior is consistent with class initialization; If you have the same field in a class and create a new instance, then the ordinal value of the field will be zero - as expected. -
Bummer. I've just checked both my desktop (which is a *ehem* 15 years old home build) and my laptop which is the top Lenovo X1 model, 2 years old, and neither of them support S0. This means that I unfortunately can't help debug the problem. If anyone else wants to have a go at it, the command to check for S0 support is powercfg /a. Note though that if Modern Standby isn't already enabled then it requires a complete OS reinstall to enable it. Yup, you read that right. Nice one, Microsoft.
-
You are looking at the symptoms at the end of a long chain of circumstances. You need to look at the other end, which supposedly (assuming WM_TIMER is the problem) is closer to the source of the problem. If standby killed WM_TIMER then millions of applications would break so I think it's very unlikely. The bug in PuTTY wasn't that the timer didn't fire but that they assumed that it would fire with a certain time interval and WM_TIMER is never guaranteed to do that. AFAIK WM_TIMER is a low priority message which is only synthesized when the message queue is polled and no higher priority messages are in the queue (or synthesized). I don't know your application but it could be that the queue is simply flooded with other stuff after resume from standby. So instead of assuming that WM_TIMER doesn't work I recommend that you simply verify with a simple application that does nothing but write a time stamp to a TMemo every time a 1 second TTimer fires. If that doesn't work then there's a problem with TTimer and we can start examining what that is.
-
I think the timer is still alive. It just takes a (unusually long) while to fire after resume from standby. See also: https://github.com/cyd01/KiTTY/issues/475
-
VCL UI Design Challenge for Delphi Developers 💡
Anders Melander replied to bravesofts's topic in VCL
Why? In a browser? -
Multithread and thread-safe TClientDataSet?
Anders Melander replied to snodev's topic in RTL and Delphi Object Pascal
Yes. I think you should drop the idea of the workers writing to a dataset. Write to a lock free queue instead and then read from the queue from a separate thread. -
Multithread and thread-safe TClientDataSet?
Anders Melander replied to snodev's topic in RTL and Delphi Object Pascal
If by "clone" you mean a cursor clone, then the master and the clone shares the same data and modification from one thread will alter data seen by other threads (with no automatic synchronization AFAIR). So: Not thread safe. If by "clone" you mean a distinct private copy of the data, then yes it's safe. Apart from that, do you have a specific reason to use TClientDataSet instead of TFDMemTable? TFDMemTable also has clonable cursors (with pretty much the same restrictions as TClientDataSet I would think). With TFDMemTable you at least have the source and can see for yourself what goes on. -
Yeah well, threads do come with their own challenges and I have a feeling that the OP "just want it work" and get on with business. I agree that blocking the main thread for 5 seconds is too long - and I'm pretty sure Windows isn't too happy about it either.
-
I can't believe I just made a case for Application.ProcessMessages after 25 years of trying to get people to stop using it 🤦♂️
-
The purpose of Application.ProcessMessages would be to have any pending messages in the queue processed. If there is a mouse-click message in the queue then it will be processed but will do nothing because the control being clicked is disabled. Without Application.ProcessMessages then the mouse-click message will still be in the queue after the control has been enabled and will therefore be handled as a click when the queue is pumped.
-
I can't see why. Please explain.
-
I agree wrt avoiding Application.ProcessMessages but... If the form is modal then you can disable the form instead of the panel and then it should be (relatively) safe to use Application.ProcessMessages. Place it right before you enable the form again.
-
Exactly