dummzeuch

Hm, where can I download it again? There is nothing on my.embarcadero.com (not even Delphi 11 and its patches). I must be getting old, because I'm sure I had a download link (where else should I have gotten the Delphi 11 ISO from?).

Thanks for the clarification. Just in case anybody has got problems understanding what Uwe wrote: Eigenschaften -> Properties Verknüpfungen -> Shortcuts Anderes Symbol -> Change Icon

This might be a dumb question, but what do you use these icons for? For the IDE? If yes, how? Just assign it to the .lnk file that starts it?

As for replacing the shell, this looks promising: https://superuser.com/questions/1016380/how-do-i-replace-the-system-shell-explorer-exe-with-another-process-in-windows (Took me all of two minutes to find it.) Interesting project you've got there. I'm not sure whether it is worth the effort, but of you think it would be fun, go ahead. Adapting to the resolution, simply handle the appropriate messages and resize the controls accordingly. How you do that depends on the controls you use. For most it's enough to set top, left, width and height. I'm not sure where any toolkits would come into play here. VCL or FMX should be enough, but that depends on the functionality you want your program to have. Just for a launcher, I don't see the need for a specialized toolkit. btw: Have you checked the power requirements for such a computer? I'm not sure the normal car electric power supply can handle that.

In the German DP for the first time an Embarcadero employee contributed something on this topic: MEissing wrote: Which means "Search doesn't work yet". So apparently the improvement we currently see was due to some work that was done and not just by chance.

The new GExperts version still supports all Delphi versions back to Delphi 6 (with the notable exception of Delphi 😎 and even the Delphi 11 version is no longer in Alpha state (but it’s still beta, there will be glitches!). Support for per monitor DPI awareness should now work (in Delphi 11, and definitely better than in the IDE itself). There are even a few new features ... Read on in the blog post.

I could have sworn that there is a repair option, but apparently that was from an older Delphi version. Now cannot even find the Delphi 10.4 entry in my Windows 10 "Uninstall or change a program" list. Sorry for not being helpful at all.

Looks like a COM-Server got uninstalled when you removed Delphi 11, which is also being used by Delphi 10.4. The easiest fix is probably to do a repair installation of Delphi 10.4.<LastPatchLevel>

Maybe @A.M. Hoornweg should send an invoice to Emarcadero (Idera) for diagnosing the problem. That might get their attention more than us mere customers complaining.

Does that also apply to DprojNormalizer?

I've solved this problem for me by calling Uwe Raabe's Project Magician (Dproj Normalizer for older versions) as an input filter in beyond compare. Not quite as simple as it could be, because it overwrites the input file, but with a little bit of my own magic aka InplaceExeWrapper this works fine.

They are, but the info is quite RAD Studio specific.

I just released dzBdsLauncher 1.0.7. The only change is support for detecting .dproj files created by Delphi 11 (these have a ProjectVersion of 19.3).

I think @Uwe Raabe might be the one to ask regarding dproj files. I have got some basic idea how they work, but that's about it.

I remember that for one particular Delphi version there was a hidden Code Insight option to automatically fill in the parameters for a function call. What I mean by that is, given a function declared as function bla(FirstParam, SecondParam: integer; out ThirdParam: string): byte; when you enter a call to it in the editor MyVar := bla( and press some hotkey, the function call would be automatically completed as MyVar := bla(FirstParam, SecondParam, ThirdParam); I don't mean the hint on parameters that is still available, but actually adding this text into the editor. To enable this, you needed to set a particular registry key. This was only possible in one particular Delphi version (2006?) and was removed in the next version. If I remember correctly some Borland (Inprise / Codegear ?) employee blogged about it. Does anybody remember the specifics?

No, I'm not saying that.

No, because that would only create the code for one particular function call. What I'm after is generating the code for any function that's available through Ctrl+Space.

The person responsible is sitting in Australia, the access to the server is only available during business hours in California and needs the approval from somebody in Europe. And the server does not have a reset button because that would be a security risk. 😉

I'm 100% sure that it existed and that I used it at some time. I also remember being disappointed when it didn't turn up as a regular feature in the next Delphi version and couldn't be activated any more. As for it being useless, I disagree. It's useful if your calling code is just a small function and you don't have to think about naming those variables and typing them. Thus it promotes better variable names. It also prevents typing mistakes.

patch (from @Achim Kalwa) applied in revision #3811

Which opens a new can of worms...

There's always delphibasics.co.uk and of course there is the offline help in chm format. Still, I would be really embarrassed if that was my company. In particular I would try my best to communicate to my customers that I am working on the issue as hard as possible.

I still think that the "A" prefix looks bad. I prefer to use "_", which luckily I can get away with, because I'm the lead developer in our company. I'm also with some others here who think that the upper case prefixes, "F" in particular, reduce readability so a lower case "f" should be used instead (but I don't put that into practice). But somehow this feels like an age old discussion, that has been abandoned without a result many times only to start again when an opportunity comes up. And I'm really tired of discussing these non-problems.

I looked into two problems with GExperts Grep and DFM files. While it is possible to fix both, the fixes have side effects: Grep Search does not find strings in DFM files that are split in multiple lines (#49) Searching for text that gets split in multiple lines can be solved by first joining these lines: object l_Test: TLabel Left = 8 Top = 8 Width = 434 Height = 13 Caption = 'Dies ist die Ueberschrift, und sie ist sehr lang, damit es einen ' + 'Umbruch in der DFM-Datei gibt' end So instead of searching "einen Umbruch" in two lines and not finding it, we join these lines into one and then we will find it. 'Dies ist die '#220'berschrift, und sie ist sehr lang, damit es einen Umbruch in der DFM-Datei gibt' This works fine but breaks the preview in the result window. But that could probably be fixed too. But what about this: object m_memo: TMemo Left = 8 Top = 104 Width = 281 Height = 193 Lines.Strings = ( 'first line' 'second line' 'third line' 'and a ' 'veeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrrrrryyyyyyyyyyyyy' 'yyyyyy long line at the end that should get wrapped.') end There are three lines that are short and then a very long fourth line that gets wrapped into 3 separate lines in the DFM file. I can see no way how this could be detected. I wonder how the Delphi streaming mechanism handles this. (Actually it doesn't. When I load that form, I get a memo with 6 lines. At least in Delphi 2007. And that's a bug.) EDIT: Something apparently went wrong in my first test. I cannot reproduce the problem any more. Now, if I add long lines, the DFM file looks like this: object m_memo: TMemo Left = 8 Top = 104 Width = 281 Height = 193 Lines.Strings = ( 'first line' 'second line' 'third line' 'and a ' + 'veeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrrrrryyyyyyyyyyyyy' + 'yyyyyy long line at the end that should get wrapped.') end And that can easily get parsed. Grep search fails to find some words with Umlaut in fmx files (#112) (which also applies to DFM files) object l_short: TLabel Left = 8 Top = 80 Width = 83 Height = 13 Caption = 'Kurze '#220'berschrift' end Any non ASCII character apparently gets converted to its #<number> representation. Again, a fix would be to parse theses strings and convert them back: 'Kurze Überschrift' Which then would be found when searching for "Überschrift". But then, how do we search for 'first line'#13#10'second line' ? The proposed fix would convert the #13#10 numerical representation to a carriage return and line feed character respectively. Searching for "#13#10" would no longer find these. Searching for "\r\n" with Regular Expression turned on, also doesn't find it, but that might still be a bug in my code. So, after spending a few hours on these "bug fixes" I am not sure whether I want to commit them. They might break more than they fix. Any ideas on this?

I hadn't noticed. In that case it's OK to post it.