Rudy Velthuis

It is a problem. Really? I hardly ever see controls that are either unfamiliar or unusable. The controls are not the problem. They may be hard to control programmatically, but that is not a usability problem.

If so, then you replied to a comment that doesn't lead anywhere. I was going to stop after the comment. But we all know that threads do not just end like that. But telling something is off-topic and then stopping the discussion does make sense, IMO. So if you don't prolong it, it works.

That is off-topic.

Hmmm... basically, the differences are not that big. The looks may differ but most control sets on different platforms or UI frameworks have similar functionality. There may be some differences between desktop and mobile, but among them, there are not that many basic differences. Sure, there will always be some that try out new controls (like the Office people at MS did and probably still do) and if they catch on, others will copy them. If they don't, they will slowly disappear again. Note that all the big vendors have usability labs, and the smaller ones can and will copy the successful idioms. Even the IMO worst of all of these, Android, is still easy enough to use and doesn't present you with many surprises. So UI controls/idioms are not the problem. The design/structure of an UI, or set of dialogs can however make big differences. I already mentioned the few very bad designs for parts of our dental software. They have usability problems because the designers/engineers don't know the proper workflow in a dental clinic. And because for such items, there are no standard controls. (Weirdly enough, the previous software we had, which was DOS-based, did some of the things we now have problems with much better).

No, not through the entire development process. A few sessions together should do. But I think they are present in leading UI manufacturers.

Yes, I got that already, thanks.

Yes, I noticed, but that is not really detecting keyboard actions, is it, it is just very indirectly detecting some of them. Hooking up the editor, if possible, would be the best way, IMO. I just don't know how. <g>

Fortunately. Engineers might think they are the perfect designers, but they aren't either. And it is usually management that wants something flashy, not the designers. A good designer will improve what the engineer does, but this only works if they work together. FWIW, the client is not entirely clueless either. They know their domain. So they should be involved too. I know a few pieces of dental software that could have been vastly improved if a dentist, or even better, a dental assistant, had been involved. The workflow for the assistant would have been much more efficient.

In Delphi? I must admit the last time I did something with .NET and native Delphi was a long time ago, but can we do GetType() or similar in Delphi?

David, You wrote there, that WindowCommand is pretty unreliable. And that is the only one I see that might have been of interest.

Weird, very weird...

Can you compile with the command line compiler? Problem is that an internal error is a bug in the compiler or linker, so it is extremely hard to work around. One can give some general advice, but it is not sure that that always works. AVxxx seems to hint at an AV somewhere.

Once you get an internal error, you should perhaps restart the IDE, because sometimes it seems to destabilize the compiler.

Sometimes, type inference can cause an internal error, e.g. when the type is TArray<something>. If you specify the type, it works.

Has anyone ever used the macro recorder in the IDE? Just move the cursor to the first line, start recording, press end-of-line key, add comma, press down-arrow key, press start-of-line key, stop recording. Now just replay as many times as needed. Can't be for more than a few lines (and not hundreds of them, I hope). I often do things like that, for instance when I'm converting a header to a Delphi unit. The macro recorder is extremely useful for often repeated actions (i.e. on many lines) that are not so easily done with a regexp search and replace. The latter is the other way to easily convert certain patterns. Update: I see @dummzeuch had the same idea.