dummzeuch

I haven't received any feedback yet. Does that mean everything works fine and nobody has any ideas on improving that functionality? Or was Ian the only one who tried the new version, and nobody else bothered?

By default, the width of the drop down list of a TComboBox is the same as the width of the control itself, and even in the latest Delphi version there apparently is no property to set it. Why is that so? Good question. There are probably many third party controls that offer this because it is rather simple to implement. But on the other hand, if it is that simple, why isn’t it a feature of the default control? It can really be a pain in the lower back that some entries are just not displayed correctly as seen in the picture above. Setting the drop down width is as simple as sending the CB_SETDROPPEDWIDTH message to the control’s handle: 1 SendMessage(TheCombobox.Handle, CB_SETDROPPEDWIDTH, MinimumWidthInPixels, 0); It does not allow to shrink the width of the drop down list though, because it sets the minimum width, not the actual width. There is this answer on StackOverflow for that particular problem. The result isn’t very visually appealing though, because the list is left aligned rather than right. Read on in my blog post https://blog.dummzeuch.de/2019/06/22/setting-the-drop-down-width-of-a-combobox-in-delphi/

Yes, @Uwe Raabe is correct: That's an error from GExperts Grep Search. Normally this would only be shown when searching a project or project group and a file referenced in the .dproj or .groupproj file does not exist. Looking into my crystal ball: Did you maybe select "All files in project group" but don't actually have a project group? Delphi internally always creates a group "ProjectGroup1", even if there is only one project, but in that case there is no file for it.

So, why is that a problem? Is the code wrong? Or is it just not the way you would have written it?

The GExperts PEInformation expert then probably won't be of much use either, even though it allows to access some more data (and it only supports 32 bit executables) But I thought I'd mention it anyway.

There is a batch file in the images subdirectory which creates the GXicons.rc file. I should probably put that into the pre build scripts.

Android <> Windows Microsoft has a track record of staying backwards compatible for a long time

It's possible to determine the Delphi version from the .dproj/.bdsproj/.dof file, with some limitations.

Nice idea. But of course I have got something to complain about some suggestions I find it rather difficult to see those light gray lines on a dark gray background. Maybe I'm just getting old and it's my eyes not the tool, but anyway. Why not use black lines on a white background? I know that "dark mode" is all the rage, but readability shouldn't be thrown out of the window for that. It would be nice if the input line for the project file supported autocomplete dropping a file from explorer Dropping a .dpr file from explorer onto the main window to load it would also be nice. I'm sure I will think of some more possible improvements. What are your plans for this tool? Are you going to release the source code? Or make it a commercial tool?

Underwhelming featurewise might just mean they focused on fixing bugs. I could live with that. Many of the features introduced in the recent releases didn't really matter for me personally. One can hope ...

That's the dialog shown by the "Filter Exception" expert. Just disable that expert and you get the default dialog back.

Ok, I think I understood the request now. And I also think that's the way the GExperts formatter works already. It only adds line breaks where there was a space character.

There have definitely been some improvements in the Delphi 11 IDE, but also quite a few bugs, in particular in the support for HighDPI. Most of them have been fixed in 11.3, but it's far from flawless. But you might never encounter some of these bugs, depending on the hardware you are using. I can't really compare to Berlin because I have never used it. The version that currently works best for me is 10.2 (Tokyo). I'm looking forward to Delphi 12 though: New Features, hopefully some bugfixes and very likely new bugs. (I'm not in the Beta, so this is purely guesswork.)

I don't think that's possible with the currently available options.

The first is a command line tool. The second doesn't make much sense for the average Delphi user, only if you want to write a plugin for hacking the IDE. The third does not work within the IDE.

This is not the right place for feature requests. You should post it on Sourceforge, where the chances are higher that I see it when I have some time on my hands. Of course, feel free to implement it yourself and append a patch to the request. It's not rocket science, you know.

Actually I invested many hours to improve the performance of the formatter. But that was many years ago. I don't know how I found the time for that. Probably by not wasting so much time in front of the bloody TV...

No, there are other kinds of strings where this could be usefull, e.g. JSON or CSV data for e.g. unit tests.

Hm, looks like I actually finished that work I was talking about, and had forgotten 😉

That is not a menu of the IDE but one added by some plugin or possibly a property editor. (Or it is part of a higher SKU than I know, e.g. Delphi Enterprise or Delphi Architect)

There are only two options for now: Hide Window Menu Move the Component menu to Tools Both can be found on the IDE tab of the GExperts configuration dialog. I have no plans exending this functionality, but I am - as always - accepting patches.

@Attila Kovacs I had started some work in this direction (not just for TMenuBuilder but also some of the other tool windows that seem to open at random positions (Action Manager, Popup Menu Builder ...) but never finished it. If you have got some working code, I'd be willing to try including it into GExperts. Best way would be to open a feature request on Sourceforge, attaching the code.

You are missing the point. We are not talking about missing/incomplete/buggy IDE features here (or at least I am not) but the pain in the lower back any new language features poses for third party tools that parse the source code, in particular the GExperts sources formatter, where the code isn't really well structured.

It has been donated by its original author to the GExperts project, so it has the same license as GExperts itself. The source code is part of the GExperts sources, but lives in a subdirectory of its own with few dependencies to any outside code.

I wasn't talking about Yukon. I can live with the formatter not supporting multi line strings, if (!) it turns out the change is too complicated. But these not supported language features add up over time and once they reach a certain threshold it simply doesn't make much sense use the GExperts. In an ideal world I or somebody else would start implementing support for new language features during the beta phase. But I'm not participating in the Beta and of some other Beta tester has made those adaptions, I don't know about it (he wouldn't be allowed to tell me). Btw. you could still use that feature, simply enclose those constructs in {(*} and {*)} so the formatter will leave that code alone.