David Heffernan

Sure, if you ask for an audit, then you want to see the outcome no matter what. But a program that yaps when it manages the to successfully save a file is poor UI. In fact, I've never ever seen such a program.

Much more valuable is not to show any dialog at all and not to ask them to make a choice about whether they want to see it, and just have the program do the right thing.

Last thing I want to see from an application is a modal dialog telling me that the app just did what I told it to.

You can read the C standard to find out how it handles that enum. Then double check with a compiler. I mean you surely aren't going to commit this without double checking with a C compiler?

So TParallel doesn't service the synchronize queue?

As for that zip file, you synchronise the pop but not the push. Anyway, replace the code with a lock and take it from there.

There are other forms of locks that you might use. For cross platform code you'd use a monitor.

It could still be related to the code that you have, which we don't have. Anyway, it's a bad idea to force the code onto the main thread just to serialise it. Use a lock instead.

Hard to say with incomplete code. We can only guess as to what PopNode and PushNode do, not to mention the code that operates on the nodes.

Type that word into Internet search engine.....

Put madExcept in the IDE via a package and then use madTraceProcess to find out what it is doing whilst saving.

The classic way to do that is a page control where every tab has TabVisible set to False

Antagonising your customers and making them hate you is never a good business plan.

If this is true, you can't even buy what they claim you need. You have to purchase new licences. You can't purchase maintenence once it has expired.

The component vendor is applying a development methodology known as "wishful thinking". FastMM4 doesn't get this wrong.

The reason you don't call FileExists is that CreateFile will fail and GetLastError will tell you that the file does not exist. You have tell us why you believe that CreateFile should fail in the scenario that concerns you. Another program already opened the file? With what flags? Rather than have us spend time trying to guess how to recreate the problem, can you provide a complete console app that reproduces the issue.

Why do you call FileExists? A single call to CreateFile can tell you what you need. The code as it stands won't tell you whether or not the file is in use. What is hdl? Use THandle as stated above. As for the problem, debug it! Use GetLastError if CreateFile fails. If CreateFile succeeds then there's presumably something wrong with your logic.

Not Delphi!

Task dialog is not suitable for that. However, the form you described, which led me to suggest task dialog, is a very different beast from these forms. The forms you described did not have an edit control or 7 check boxes!!!! Very hard to give advice when you don't describe the actual problem.

That's an odd comment. For dialogs with a message, and couple of checkboxes or buttons then they are perfectly flexible. If you want to customise every individual form then what are you even asking? Just design each one in the designer.

Kinda pointless to measure a getter that just returns or sets the field. Try measuring one that does some work.

No. I'm not even sure what such a framework would look like. Sounds like massive overkill.

I wouldn't consider using the designer for such a thing. I would build the form dynamically in code. Your example of a dialog with a handful of checkboxes and buttons is just the Vista task dialog.

Any developer or organisation that cares about quality should be flexible enough to accept bug reports from a variety of channels. Clearly if the reporter can enter a high quality report in the project bug tracker, then that is the ideal. But in reality that is not always possible. Sometimes these reports are unclear and imprecise and the project owner has to edit the report. And sometimes the reporter just won't take the required steps. Sometimes the reporter is stubborn and for inexplicable reasons refuses to give their email address and a password to sourceforge 😉 But what developer would here of a bug in their software and not want to fix it? Any developer that is prepared to let bugs pass if they aren't in the tracker should just give up. Incidentally, it grinds my gears that Emba killed QC without transferring open reports to the replacement. On numerous occasions I have been asked by Emba staff to resubmit to QP the litany of open floating point related bugs that I submitted to QC. It makes no sense to me at all that any developers that care about quality would do that.

I'm sure you are right. It just seems weird that any git program could have performance issues when all they are doing is wrapping git.