dummzeuch

@osterhaegar I got the time until the list is shown and filtered down further. Consistently to about a second with my largest project (>5000 units, 140000 identifiers) on Delphi 2007. Reading the cache files for the units takes the longest time now. They are on an SSD, so there isn't much I can do unless I add them all to one project specific cache file, which I'm considering. With Unicode Delphis it's significantly worse though, there the sorting part takes more than half a second rather than 100 milliseconds. Again having a pre-sorted project specific cache file would help. One unexpected cause for the delay was that I had set the timer, that checks whether the unit parser thread has finished, to 500 milliseconds. Reducing this to 50 milliseconds shaved off another 400 milliseconds from the total time. (Yes, I timed it. I know that I claimed it took 1 second on my machine even before Osterhaegar's an my optimizations. That was wrong, it was more like 2.5 seconds for the above mentioned largest project. Smaller projects (like GExperts itself) took about 1.5 seconds.) But at least I know now where the 3 seconds that Stefan experienced came from.

Opps, I missed the part about the standard defines. Sorry.

Since I just stumbled over the following declaration in Toolsapi.pas: type TGetSrcLinesFunc = function (LineNum: Integer; ClientArg: Pointer): Integer {$IFDEF LINUX} cdecl; {$ENDIF} {$IFDEF MSWINDOWS} pascal; {$ENDIF} IOTAProcess90 = interface(IOTAProcess70) ['{BEBD67CA-F6FC-44A7-ACBF-E314DB085827}'] { Indicates if process properties can be set on this process (via the thread view) } function CanSetProperties: Boolean; { Called when the user asks to set properties for this process (via the thread view) } procedure SetProperties; Which breaks the GExperts unit exports parser because the code is invalid, if neither LINUX nor MSWINDOWS is declared, but I just tested your tool and it works: I wonder how your tool handles this. Do you add one of these symbols to the parser? If yes: It only has one index independently of the platform, so how does it decide which one to use while creating that index?

We have lots of legacy code that still uses "with" and I'm hesitant to touch this code because of this (Guess what's also missing? Unit tests. I add them when I find the time, but progress is slow.) A tool that reliably removes "with" statements would be awesome. Unfortunately it's also far from trivial.

Yes. Hm, thinking about this, It should better be raise [a-z]*\( Because there might be exception names that do not start with an "e". And of course the match should be case insensitive.

Greping for “raise e[a-z]*(” and ” e[a-z]*\.Create\(” will find bugs with (not) raising exceptions.

There aren't any options with QPC. It just returns a 64 bit int. Which TStopwatch passes on to you. And the performance counter frequency is also available. There are alternative options to using TStopWatch, that's what I meant, e.g. using GetSystemTimeAsFileTime, GetTickCount, GetTickCount64. I'm not suggesting to use these for high precision timing in general, they are just options for some particular cases, e.g. if you don't want an Int64 but an Int32 for whatever reason.

Yes, I was wondering the same. There are only two reasons not to use TStopWatch: You are using a Delphi version that didn't have that yet (e.g. Delphi 2007) You want to play with various options.

None of these sources claim that QPC used together with QPF was imprecise. Just that they are based on different time sources, depending on hardware and operating system and therefore the resolution and overhead for the calls vary. As far as I understand it, there is a guaranteed resolution of at least 1 microsecond for all those cases. There are other factors that affect timing much more than these, e.g. what else is running in parallel and whether there are context switches. Also, they cannot be relied on for high precision timestamps that must be consistent between multiple CPUs, but that has nothing to do with performance measurements.

I didn't know that there was a context menu available when pressing the ctrl key - thanks for that - but ... ... unfortunately my smart phone does neither have a mouse nor a ctrl key. I already failed to add any text to the post before or after the quote construct, after I had deleted the text from the post. There simply isn't any way to set the cursor outside the quote.

I accidentally started replying to your post and then found no way of deleting a quote once inserted into a post on a mobile browser. Deleting the contents of a quote is possible - thus the empty quote, but not the quote itself. Even cancelling a reply and starting a new one will not work. The quote is somehow preserved and automatically inserted into the new post. So the only way to actually post a new reply was posting the empty one first. Sorry about that. With a desktop browser this problem does not occur, but that doesn't help if all I have available is a smart phone.

I just installed and tried it. It is indeed much faster than GExperts. One observation: When no match is found, the error message is shown in the middle of the monitor. I would have expected it near the current cursor position like the other dialog.

For a while I played with a tool called Portable Delphi (on SourceForge) which made an existing (legal) Delphi 7 installation portable by reading all registry entries and adding a start program that created these entries before starting the IDE on a new computer. This will not work with newer Delphis as the copy protection has become much more sophisticated. I wonder thought whether this approach might be possible when using a network license. Under these licenses you can have as many installations as you want, but they need a license provided by the license server in order to start the IDE. It would probably even be legal as I can't see any significant difference between a regular installation and such a copy of the files. But I'm a software developer, not a lawyer, so I might be wrong here (as I'm often wrong as a software developer too).

That's one of my major gripes with Windows. The only solution I know is to roll your own or use an existing library. So I wrote my own. You can find it here; https://osdn.net/projects/dzlib-tools/svn/view/dzlib/trunk/forms/?root=dzlib-tools in Unit w_dzDialog.

That's why it also scans the browsing path. Sorry, I should have mentioned that. Otherwise it wouldn't have found TStringList in Classes: So, the problem is, that it is too slow? Or what else do do you mean by cumbersome? I am trying to learn what to improve. For me it currently is fine (less than a second delay on the two computers I mostly work on, I wonder what makes it so slow on your computer), so I rely on others for suggestions.

you press the shortcut that calls the expert if the Identifier tab is not yet active (the dialog remembers which tab was active), press the shortcut (Alt+I) for that if there is a perfect match, the required unit will automatically be selected, so you press Alt+C or Alt+L to insert the unit into either the interface or implementation section if the expert is configured for - oops? - I thought there was an option to automatically close the dialog after adding a unit? OK, apparently somehow this option got lost, I need to look into that - you press enter to close the dialog So, if there is a perfect match, 3 key presses / combinations are required. If there isn't, you can either use the filter or the keyboard keys to select the correct identifier / unit to insert. The expert uses the current search path to determine which units are available. One drawback of this is that it might take a few seconds to determine the units and parse / cache the identifiers when invoked the first time for a project and display them. There definitely is still room for improvement here. But on a computer with an SSD it's very fast, on a HDD it's not too bad either.

Since I seem to remember that you mentioned that you use GExperts: The description of your plugin sounds a lot like the Identifiers tab of the Uses Clause Manager. What functionality are you missing there that you went to the trouble to write your own?

What is the latest Delphi version that can be installed and used on Windows XP? I know that XE2 and XE3 work, and I seem to remember that XE4 also does.

What about putting the labels/radio buttons above the input fields? That would work even if scaling fails.

So far above that it can be read at design time. The scaling of the form should take care of different DPI. As for the layout: I never bothered to use anything but the default for labels.

Put the label above the edit field.

Today I had a very strange compiler error in Delphi 10.2, that occurred on one computer but did not occur on another computer: myUnit.pas(28): error F2613: Unit 'TeEngine' not found. The project was checked out from svn on both computers, so the source code was identical. So the unit “VCLTee.TeEngine” from TeeChart was in a subdirectory of the project sources and the project’s “Search Path” on both computers. But on one computer the compilation worked fine, on the other I got the error above. The first thing I checked was that the TeeChart sources were not listed in the “Library Path”. I restrict my “Library Path” to the RTL and VCL units that come with Delphi and remove anything 3rd party libraries tend to add. Third party sources go into svn, are project specific and checked out via svn:external. Further investigation showed that the prefix “VCLTee” was not listed in the Unit Scope Names setting of the project, that’s why the compiler as only looking for “teEngine” and did not find “VCLTee.TeEngine”. But again: How could the same project compile on the other computer? It should have failed on both! read on in the blog post.

I blogged about installing it on Windows 8.1, which also works on Windows 10 if I remember correctly. Getting the dotNET version it needs proved a bit more challenging on one computer (on others installing dotNET 3.5 simply worked). I also blogged about that. (I mostly blog about those things so I can look it up if I need it again.) Edit: I'm not sure whether I ever installed Delphi 2006 on Windows 10. On my current computer, I installed it to Windows 8 and upgraded that to Windows 8.1 and later to 10. It's possible that installing directly to Windows 10 is more involved.

I just released dzBdsLauncher 1.0.6. The only change is support for detecting .dproj files created by Delphi 10.4.2 (these have a ProjectVersion of 19.2). If you don't know this tool yet, here is the description: