dummzeuch

voted

No, that's Visual Basic programs.

My coworkers know my obsession with the tab order in dialogs. I frequently tell them to check it before committing code to the repository (they even released it at some time 😞 ). Now I have to do the same with Embarcadero: https://quality.embarcadero.com/browse/RSP-21726 Why did I notice? Because it broke the GExperts enhancement for the Run -> Parameters dialog. Now I have to change that code yet again.

The same problem exists in Delphi 10.2 with any theme but the light one. And there the light theme isn't a real theme anyway but the native VCL look.

I had an unfair advantage: A popup menu that did work. So all I had to do was compare them.

The problem is with displaying the icons. If I do not assign anything to the Images property, it works fine. Edit: Yes, definitely the icons. I reverted all other changes but left the Images property empty and it works fine now. Not sure what to make of it. Calling IOTAIDEThemingServices.ApplyTheme on the popup menu doesn't solve the issue. But if I call it on the menu without images, it is shown themed. I think for now I am simply going to remove the icons and go forward with other stuff.

That the toolbar is not themed is a known limitation and I am not going to fix it. If somebody else wants to have a go, he/she is welcome. Regarding the menu again: Just to be sure we are talking about the same menu. There are two of them: * One is called "Editor Popup menu", that one is configurable, shows entries prefixed by numbers and is usually opened using Ctrl+H. This one works fine for me. * The other one is normally a sub menu of the GExperts main menu and contains all enabled Editor Experts. By default it has no keyboard shortcut. The sub menu works fine for me, but if I assign a keyboard shortcut or call it via a button added to any of the toolbars, I see a drawing issue. Which one are you referring to? And how to you open it.

What exactly do you mean with the "Editor Experts popup menu" ? It can't be the sub menu "Editor Experts" of the GExperts menu, at least that one works fine for me. Have you maybe assigned a keyboard shorcut to the "Editor Experts" expert and call that menu via this shortcut?

Hm, that's odd, now all of a sudden I get this error again. And I can even see it in the debugger and with a sensible call stack: I think the cause is that the editor popup menu is now filled dynamically by the IDE. It expects a given order of menu items and if that changes, can no longer find some items and tries to add them again -> Boom. That also explains why the entries appeared on the top of the menu: There are no other entries when I add them the first time.

There are two experts that accesses this menu: * Goto Previous Modification * Goto Next Modification Try to turn off these two an see whether this changes anything. Oddly enough, this doesn't happen here, but I have seen that same error message on Friday when I first started to work on GExperts and Rio. It went away later and I never saw it again, no idea what caused it.

There was a bug in the (yet unreleased) GExperts code that caused an access violation every time the Delphi IDE was closed. I have just found it, but boy was that difficult! I knew the problem existed in the current source code and by trial and error I found a source code revision that did not yet have it: #2415. So I compared those revisions and step by step narrowed it down to the changes in the unit GX_IdeFormChangeManager in revision #2433 which was a fix for a redrawing bug in the Delphi 10.2 Search Path dialog. So I removed the code I had added ... https://blog.dummzeuch.de/2018/11/24/found-the-cause-of-the-av-on-exiting-the-delphi-ide/

Yes, seems to be the same issue.

Originally the idea was that the debug dcus only contain additional information for the integrated debugger which should have no performance impact at all. This of course is only true, if all compiler (and possibly linker) settings are equal, which I doubt. E.g. enabling range checking (which I always do for debug builds) can have a significant impact on performance. No idea what the compiler options are in the supplied debug dcus. The jcldebug stack trace does not require debug dcus, but a detailed map file, which does not have any performance impact.

really? Why? Why does that matter? I don't like the intrusive spying of Windows 10 and how Microsoft forces updates on Win10 users. And I never liked Windows 7 (but support for Windows 7 has ended anyway there is only extended support until 01/2020). I don't like Windows 8.1 that much either, but switching to any other version would involve work for no gain.

OK, now I'm really annoyed: I downloaded and installed the dotNet Framework 4.7.2 which is the one the above page links to for Windows 8.1 and rebooted the computer as requested. https://docs.microsoft.com/en-us/dotnet/framework/install/on-windows-8-1 (This is a "web installer") There was no error message, but according to "Programs and Features" there is no .NET Framework 4.7.2 or 4.5, it lists only "Microsoft .NET Framework 4.6.2 SDK" and "Microsoft .NET framework 4.6.2 Targeting Pack" installed, both are from 2017: And there is still nothing higher than 4.0 in c:\windows\Microsoft.NET\framework: And of course command line compiling still doesn't work. Any hints on that? I'm now going to install with the offline installer listed here: https://docs.microsoft.com/en-us/dotnet/framework/install/guide-for-developers we'll see how that works out... Edit: Yeah, great, it tells me: Your installation did not occur. See below for reasons why. Details: .NET Framework 4.7.2 or a later update is already installed on this computer. Yeah, right. When checking the registry as described in https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed#to-find-net-framework-versions-by-viewing-the-registry-net-framework-45-and-later I find that it apparently has been installed to the 4.0 directory So I guess I should change rsvars.bat to point to that directory. I should also probably file a bug report on that, because the path seems to be hard coded in the installer. Apparently the IDE gets it right and calls msbuild in MSBuildBinPath = C:\Windows\Microsoft.NET\Framework\v4.0.30319 I got that output by changing the output to "Diagnostic" in Tools -> Options -> IDE -> Compiling and Running: OK, this is probably worth a blog post by now. 😉

That's exactly what I did (50 minutes ago): https://sourceforge.net/p/gexperts/code/2451/

Found the cause. It had nothing to do with the Favorites menu. https://blog.dummzeuch.de/2018/11/24/found-the-cause-of-the-av-on-exiting-the-delphi-ide/

Not that I know of. Since packages use the same memory manager as the IDE itself, I doubt that it is possible.

The AV just happened to me without the code for the Favorites menu but with most other changes since revision 2415. So it must be something else. (Or it is was pure chance.) I'm going to check all other changes. maybe it's one of them, but most look fairly innocuous. But not today.

Please vote, if you care: In previous versions it was possible to open a (sub-)folder in the project manager by double clicking it. Now this requires a click on the arrow. it's much easier to hit the folder name than the arrow, so I'd like to get the double click feature back. Also, opening it with pressing return rather than having to use the right arrow key would be nice. That also used to work. https://quality.embarcadero.com/browse/RSP-21689

Yes, wrong number. Bloody frames! Fixed.

I disagree in this case, but I can understand Uwe's decision.

I guess everybody in the Beta test is used to turning off error insight so nobody noticed the new bug. (I wasn't in the Beta test, but I might have done the same.)

… but I am working on it. I have already installed the new version and it compiles on my machine. But don’t hold your breath, there are some issues. Until then you can always download the sources and compile your own DLL. https://blog.dummzeuch.de/2018/11/22/before-you-ask-gexperts-for-delphi-10-3-is-not-ready/