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.

AFAIK, they are working on that. I think this is even mentioned in one of the roadmaps (or one of the online events?), but I might be wrong.

AFAIK, any useful word processor can scale the document anyway, so that is not a problem. In Editors, you can set the text size too. The problem is that some people with high resolutions won't be able to read the menus and similar fixed size texts.

This is the first incarnation of the new theming IDE. I'm sure they'll find ways to make it a lot snappier. They had problems with one of the earlier versions too (not sure which one) and it became much better in the next version. And gimmicks can be implemented by 3rd parties too, if they can find out what people need or would like to have.

Oh, Ok, I understand what you mean. Yes, that's possible.

Then you should not have replied to a message purely about (the superiority of) the Wordstar keybindings. Actually, the current Rio IDE is terribly slow. Previous IDEs, especially Tokyo, were fine. Not with every gimmick some other IDEs provide, but very usable. Actually, on my system, VS is terribly slow too, perhaps even slower than Rio, but certainly slower than Tokyo or Berlin. Had some C# code to try out and it took ages before I could do anything.

Slow? Keybindings are not slow. Or do you mean a little more than just keybindings? The entire (new, themed) IDE is slow. It constantly redraws and needs ages to do simple things like showing the options dialog.

I very much doubt the Wordstar key bindings hold you back. And when wheels stop rolling, you don't reinvent the wheel. That's plain silly. You clear the way so the wheels are free to roll again.

Yes, indeed, so would I. But you have to create and free those, to really stay inside the type system.

Yeah, well, you can do a lot when cheating.

LOL! It seems they mean method pointers in Delphi, especially how they were used for events, and they don't want them. Ok, their decision. When I first saw events at work (a demo at CeBit 1995) I was impressed. The VCL and especially the way properties and events worked were the main reason I ordered Delphi 1 at the spot. I don't care if they are pure OOP (I actually don't see why not).