Rudy Velthuis

8 hours ago, Dany Marmur said:

23 hours ago, Rudy Velthuis said:

So UI controls/idioms are not the problem.

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.

16 minutes ago, David Heffernan said:

Public service announcemen:

 

If you don't reply to a comment that is leading nowhere, the thread just ends. 

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.

9 hours ago, AlekXL said:

actually, the only way to fix it is to have  compiler opensourced and local skilled software engineer hired --   to investigate such issue. He could resolve issue, and then report it!

So vote the issue

 

That is off-topic.

8 hours ago, Dany Marmur said:

Today there are an abundance of UI idioms out there

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).

13 hours ago, Sherlock said:

Ay, there's the rub: Please! Pretty please! Find me a good designer! When they are not even present in most of the leading UI manufacturers, surely there must be some kind of global shortage.

I am painfully aware of the fact, that an engineer will fail at creating a good UI as well. So the best thing is to have them both talk with each other through the entire development process...a costly thing. *sigh*

No, not through the entire development process. A few sessions together should do.

But I think they are present in leading UI manufacturers.

1 hour ago, Remy Lebeau said:

You don't have to create instances of the class if you use a non-static 'class' method for the event handler.

Yes, I got that already, thanks.

29 minutes ago, Uwe Raabe said:

If you are not actually interested in the key itself, but only in the fact that the editor content has changed, you might get away with EditorViewModified.

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>

On 4/5/2019 at 9:22 AM, Rollo62 said:

Unfortunately 99.99% of the people out there are NO engineers

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.

On 5/6/2019 at 9:47 AM, Stefan Glienke said:

Probably by calling Type.GetType(string)

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?

31 minutes ago, David Hoyle said:

Try the following:

https://www.davidghoyle.co.uk/WordPress/?p=349

David,

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

4 minutes ago, FredS said:

99.9% of the time recompiling fixes it. For the remainder, commenting out a line , any line, do a build all then uncommenting the same line will fix it..

Weird, very weird...

7 hours ago, FredS said:

Yeah, except yesterday I tried to compile that project via msbuild and it still generated the same error:

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.

On 3/31/2019 at 7:16 PM, FredS said:

Good idea but here is what happened:

1. Was unable to generate the Internal Error this morning
2. The Project Group also contains some components so I right clicked and ran 'Install'
3. After that a 'Build' generated the Error
4. Commented out all 'Assert.'
5. After a bit of tweaking all compiled
6. Was not able to reproduce the Error by running 'Install' again
7. Uncommented chunks of 'Assert.' until I could generate the Error
8. But commenting those back in still generated the Error after running 'Install'

As I have postulated for years, the compiler appears to get confused about which directory its in or something else internally goes haywire.
The degree of which appears to get better or worse with each release..

 

Just to be clear; 'Install' is executed via the context menu so the active project does NOT change in the Project Group. Certainly rhymes with the 'I did a few things and it broke' we see a lot..

 

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

On 4/1/2019 at 4:50 PM, PeterPanettone said:

Thanks, Stefan.

 

I would have preferred "the old way" which is more formal.

 

BTW, are there any drawbacks in using inline variables? I am not sure, but I remember having read somewhere that there is still a bug in using inline variables.

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

On 4/7/2019 at 11:15 PM, PeterPanettone said:

I could easily write a small script-tool which fixes the commas. But at a more general scope, it would be interesting if it was possible to fix these syntax errors with the help of the compiler?

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.

On 4/15/2019 at 12:52 PM, Микола Петрівський said:

If Embarcadero had been testing IDE for HiDPI, then they would spot the problems in IDE manifest first of all. But manifest remains broken for several releases already. So they clearly do not test for HiDPI. And in the docs you will not find any statements, that IDE is HiDPI-aware.

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.

On 12/8/2018 at 9:29 PM, PeterPanettone said:

otherwise they would not be able to read any text in a word processor.

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.

6 hours ago, Nasreddine said:

@Rudy Velthuis You are right the VS loading time is terribly slow. but I think If Embarcadero continues like this, we will not only have to deal with an IDE that lacks "good gimmicks" but also a very slow one too.

 

If they Continue down this road, they will make it easier to dump the IDE than trying to fix any thing anymore.  

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.

3 hours ago, uligerhardt said:

No, that's why I'm talking about class methods. You can use them like this:

type
  TMyEventHandler = class
  public
    class procedure OnError(const AMessage: string);
  end;

Something.OnError := TMyEventHandler.OnError;

The method has to be non-static to provide the needed Self parameter.

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

1 hour ago, Nasreddine said:

@Rudy Velthuis You completely missed the point of my post. I meant the IDE not the WordStar key bindings.

 

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.

2 hours ago, vhanla said:

I just wish Vim mode support. I found one "extension" but it is very slow.

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.

On 5/3/2019 at 4:42 PM, Nasreddine said:

@Rudy Velthuis Elites reinvent the wheel when the wheel stops rolling.

Clueless become elites when the wheel don't hold them back from solving problems (currently it is slowing them down)  

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.

10 hours ago, uligerhardt said:

FWIW: If I have to adapt the interface of the routine anyway I would make it into a (non-static) class method of a dummy class and stay completely inside of the type system.

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

19 hours ago, Remy Lebeau said:

And yet, it CAN be done with plain/static functions.  I do it all the time when writing test apps that have no UIs.  It is just a matter of adding an explicit Self parameter to the function, populating a TMethod record with the address of the function in the Code field and an arbitrary value in the Data field, and then assigning that TMethod to the target event via a type-cast.

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

1 hour ago, Chris Rolliston said:

By the by, this historical piece is quite an amusing read:

 

https://web.archive.org/web/20120627043929/http://java.sun.com/docs/white/delegates.html

 

Sun's reply to Microsoft adding delegate types to its Windows-centric version of Java (Visual J++ being Anders Hejlsberg's main project in between Delphi and C# I think...?).

Quote

This decision was made in consultation with Borland International, who had previous experience with bound method references in Delphi Object Pascal.

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).