dummzeuch

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.

Don't. Either he will put it back online himself, or he won't. It's his work after all.

When posting something's like this, one has to expect feedback. And usually negative feedback more than positive. It's difficult to deal with that if you have no experience. Most people have no idea how much work is takes to write a book. (I don't either, I only write blog posts and wiki articles.)

Somebody in the German Delphi Praxis claimed they are working on it. Unfortunately I don't remember who it was and whether he mentioned the source. One would expect Embarcadero to at least post a message on their site that they are aware of the problem. But on the other hand experience shows that communication from Embarcadero revolves mostly about sales.

Actually it isn't (I just looked), which explains why I missed your blog post. I suggest it for inclusion.

The Delphi 2007 IDE has an annoying bug that causes the width of the name column in the Object Inspector to shrink over time so that it is no longer possible to actually read the property names. I have no idea what causes this and it doesn’t happen in any of the more recent IDEs. It might well be an effect of one of the other plugins I have installed (GExperts, cnPack, IDE Explorer, DDevExtensions and the Ide Fixpack). The dzObjectInspectorFix plugin fixes that annoyance by periodically checking the width of that column and setting it to the configured minimum (Default: 150 Pixels). (read on in the blog post)

A few weeks back something happened with my Delphi 6 installation which now results in an access violation every time I start the IDE. I tried for several hours to find and fix the problem to no avail. It’s not GExperts related, disabling the DLL was the first thing I tried. Now I’m giving up. This will mean that while GExperts will still continue to support Delphi 6 and I will compile a dll with every release (as long as the command line compilation still works), I will not be able to debug and fix any issues. If you are still using Delphi 6 you are invited to take over this task. read on in the blog post

I knew about these controls, but not about the keyboard shortcuts. And somehow I missed your blog post even thought I am subscribed to the BeginEnd RSS feed. Thanks for mentioning it.

They probably all vanished in an empty except-end block. ... which they introduced into the code.

For my professional work, I don't mind paying for the tools (or rather my employer paying for them), as long as they provide value for that money. But for my hobby, I'm not prepared to pay > 1000 Euros for a development tool. I'd either use something that's free or stop programming in my free time. (btw: My salary isn't paid from the "products" I create but rather from the services my company provides with the help of my software.) As for paying for smartphone apps: There are a few that I'd pay for, but most are not even worth "paying" for by looking at ads. I had about 20 Euros to spend on Google Play which otherwise would have been lost. I found nothing worth buying for that and the money is gone now. In my experience, freelancers who offer to work for a few bucks an hour are usually not worth even those few bucks. When you then try to use their "product", you find that it doesn't solve the problem and creates new ones. Of course, there are probably exceptions to that rule, but I have yet to come across them.

I was about to post something similar, when I realized that David was talking about the Delphi 11.1 release.

Welcome to assisted emailing, a new service brought to you by the people who invented the seat belt beep.