dummzeuch

Some interesting implementations, thanks. Not sure that I can use any of them though.

It all depends on the definition of "good code". Of course my code is good code. 😉 The advantage of code without comments is that you don't have to worry about the comments being wrong or outdated because the code was changed (fixed) and nobody bothered with the comments because the code compiles anyway. And of course there are those absolutely unnecessary comments like: // for all 50 entries for i := 1 to 50 do begin // process the entry process(entry[i]); end; // we are done processing all entries But some programmers (and managers) still insist that these kinds of comments are necessary and a sign of a well documented code base. I definitely disagree here. But I think we degress.

I certainly am not a Delphi expert in the sense that I don't make mistakes and always produce perfect code. (And as I just yesterday noticed (again) some of my "knowledge" about Delphi is outdated or even has been wrong in the first place). So, I don't really qualify for answering this question even though I have been working with Delphi for nearly my whole professional life. But here goes anyway: I'm never done improving or fixing even my own code base. And don't get me started on the code base of the company I work for. We still have code that is at least 15 years old and has never been refactored even though it is in dire need for that. It's improving slowly but I doubt that it will ever be up to even my standards.

Yes, I just found that too and was suprised. Apparently my "knowledge" about this minimum interval goes back to Windows 95 times. This also matches the logs that I am currently looking at: The next timer event starts in the same millisecond that the last one ended. So apparently it's not the interval that's the limiting factor here but the code executed in the event. Thanks everybody. That's the answer.

GExperts has this functionality, but only for the current unit. Feel free to use that code to build a batch tool (it's not quite so easy since you must take the project settings and search paths into account). I'll accept patches, of course. 😉

You are aware that the component palette supports incremental search/filtering? Just checking...

Unfortunately it's not always that simple: Assume a sub-procedure (since numbers is not a field): procedure GetItem(_idx: integer): integer; begin Result := numbers[_Idx]; end; Then call it with an invalid index. Range checking would detect it. Of course you could add code that checks for it: if (_Idx < Low(Numbers)) or (_Idx > High(Numbers) then raise EProgramerTooBloedError.Create('The programmer is an idiot!'); but then we are back to having to write code that could be autogenerated.

I recently found that my image processing code became about 30% faster after turning off range checking. So I added a conditional define that allows me to turn it off for some units even of it is on in the project settings. But as stated above: In debug builds I usually turn it on and that has saved my a** several times.

No, there is no such option. You could add a unit alias for it, that redirects to a unit that's already there, e.g. SysUtils. Then the unit would still be added to the uses list, but would not be compiled into the executable.

(Actually it's a Virtual String Tree, not a grid) Yes, I did, for various things. Unfortunately nothing much ever came from that, they didn't even fix the OTA bug that partly broke the Replace Component expert. And I can't waste any of my employer's support tickets on GExperts.

Unfortunately there seems to be no way to access the text in the messages window in Delphi > 7. They switched from a list view (?) to a virtual string grid when they rewrote parts of the IDE. (If somebody knows a solution for this, I'd be happy to add quite a few new features to GExperts, that become possible with that.)

If switching to 64 bits is not feasible, you could try to enable IMAGE_FILE_LARGE_ADDRESS_AWARE which might solve the issue for now. (no idea where this formatting comes from, apparently I can't turn it off)

... or get the source code.

Please file a bug report on SourceForge

These are the links about the virus scanner false positives. The download links are below that and these work fine (at least for me here on the hotel WiFi).

I didn't follow this thread so I had to scroll way back to see what it is about. There are various options to insert/remove line feeds in if then else statements. Have you tried them? If they don't satisfy your needs or think there is a bug, please file a feature request or bug report on sourceforge, detailing exactly what you want. Of course you are also free to implement any necessary changes yourself an provide a patch.

Why? Simply add it to the list of exceptions the debugger should ignore and you will never see it again.

Does the server really use the svn: protocol? I thought that was legacy. Or does it use http(s)?

Do you really want to check out the whole repository or only the trunk? If the former, this is correct, if the latter, add /trunk to the URL. The result will then be a working copy that can be updated with svn update From within that directory.

Try to spot these: fViewSignups:= tfViewSignups( Self ); Also quite difficult.

Does anybody know what happened to the DIBControls by Droopy Eyes Software? Their website vanished in 2007, but the Wayback Machine remembers it: https://web.archive.org/web/20071009172906/http://www.droopyeyes.com/default.asp?mode=ShowProduct&amp;ID=3 I was able to even download the sources (Haven't looked at them yet). Have these components maybe been included into any other component packs? Does anybody have experience using them? twm

I definitely wouldn't, at least not if it is about transferring large amounts of data between programs on the same computer.

Given a unit that exports a function that should be inlined: unit bla; {$INCLUDE 'jedi.inc'} interface function blub: integer; implementation function blub: integer; {$IFDEF SUPPORTS_INLINE} inline; {$ENDIF} begin Result := SomeCalculationHere; end; Is it OK to put the inline only in the implementation? Or does it also have to go to the declaration in the interface section? It compiles OK this way, but I don't know whether it would still be inlined. I'm asking because I would like to keep the interface as clean as possible which means avoiding to clutter it with an ifdef.

As I add new functionality to GExperts the menu it displays grows larger and larger. On small monitors (there are still computers with e.g. 1024×600 pixels screen size in use, usually not with the latest Delphi version though) this means that the menu has to be broken into chunks, each with a “more” entry at the end to display the next chunk. While this has been implemented for years (decades actually) it didn’t work very well. For Delphi 6 the code was completely broken (I might have been the culprit myself) it still had some bugs with all later versions. No more. Today I fixed those bugs and tested it with screens as small as 640×480 pixels. Also, when moving the GExperts menu into the Tools menu, there was a problem that the maximum number of entries for a chunk was not calculated correctly which would mean that the “more” entry could end up outside the visible area. This has also been fixed. Unfortunately this does not solve the underlying problem: The menu keeps growing. There are now a maximum of 45 + 3 Entries in that menu. [read on in my blog post]

From my blog post: But thanks for your suggestion on how to group them. I'll keep that in mind once I get to actually implement it.