dummzeuch

Normally, when a VCL program is started via double click or commandline it shows its main window in the foreground thereby taking the focus from the previously active window. Is there any way how such a program can prevent that? I still want it to show the main window but the focus should stay with the previously active window. I don't want my program to get into the foreground at all, not just move the window into the background or minimize it after a short time. No flickering, no interrupting the user from the work he is currently doing.

I ended up using the following code: constructor Tf_MyForm.Create(_Owner: TComponent); begin inherited; WindowState := wsMinimized; ShowWindow(Handle, SW_SHOWNOACTIVATE); end; So far it seems to work fine.

As of Delphi 2007, there isn't. But I found one option: WindowState := wsMinimized; Application.MainFormOnTaskbar := false; Not quite what I am looking for, because the window is shown minimized rather than normal, but for now that's ok.

Still was a but. It didn't work for units in the project either.

It's difficult to say how many LOC "my" application has, because as I said I always compile 3rd party libs / components. With that, the largest one (I think) builds 1.843 million lines of code, another one gets to 1.074 million LOC. But since I have no idea how much of that is 3rd party stuff (JCL, JVCL, TeeChart, FastReport, ccpack, ccrexif, tComport, DSpack, DSPmaster, dxgettext, gdiplus, GraphicEx, graphics32, Indy10, jedimath,mtxvec, nativeexcel, synedit, tdbf, tregexpr, VirtualTreeView), I can't really say how much of that is our own code. A complete build with Delphi 2007 of the largest one takes about 25 seconds on my computer. Hm, I think that's getting rather off topic now.

Ok, so the applications I am working on are far from being "large enough" then. A full build of even the largest one takes about 10 seconds on my computer, only compiling is only marginally faster. On the CI server it takes longer to update the source code than to build the applications. And I thought these applications were already large...

What do you consider a "large enough application" in this context?

Yes, I noticed that one. Thanks. I haven't got the rights to grant svn write access on the GExperts project on source forge. But if you send me a patch I will commit the changes.

There would be quite a lot of useful things that could be done if there was an up to date parser for Delphi code. Unfortunately there apparently isn't. I tried to update Martin Waldenburg's parser, which is used in GExperts, but it's just not easy to do. The Castalia parser, which is based on MW's parser unfortunately is incompatible in too many places to use as a replacement without too many changes. But by the look of it, it supports more recent language constructs. It's still not complete though, and definitely doesn't support the latest additions.

The GExperts Grep Search expert has various options to tell it which files to search: The current file All files in project All files in project group A directory list (separated by semicolon) That sounds like an exhaustive list, but it isn’t. Both, project and project group, were only searching files explicitly listed in the project(s). Files that were linked into the project using the search path, were not searched. Until now, that is: There is now an option to use the MAP file instead of the DPR file for project search. https://blog.dummzeuch.de/2019/03/03/gexperts-grep-can-use-the-map-file/

I always build 3rd party sources with the project. That's the only way I can be sure that the executable is based on the code it is supposed to be. And since compile times in Delphi are really short, it doesn't have any drawbacks in my opinion.

Kick those lazy bastards into the ass! 😉 As a workaround you could add a {$warnings off} and {$hints off} into theses 3rd party units.

What do you mean by "log filled with various warnings"? Do you really have more than a hand full? That's the first thing I kick a coworker's ass for, if it gehts checked in to SCM. OK, a possible solution would be to configure these hints / warnings you are really interested into be errors in the project configuration -> Building -> Delphi Compiler -> Hints and Warnings. edit: Apparently that's not possible for hints but only for warnings.

The map file lists all units that have been linked into the executable. So it is the easiest way to get a list of these units. Grep then uses the same algorithm as the Uses Clause Manager's identifier tab to find the source code for these units. That algorithm uses the project (as the first step) and all configured search paths (including the browsing path as the last step), so it should find the same source code as the compiler / linker does.

Not a bug. ToolsApi.pas is not in the search path (only ToolsApi.dcu), so it isn't parsed. You can see that in the Unit Uses list of GX_About: There is no Location info for that unit because it cannot be found. OK, that means that the list of indirect depencencies is not complete, because it does not contain units that are only in the uses list of units that are not in the search path. Hm, not sure I like that.

Possibly a bug

... and then you switch to the "indirect dependencies" tab and ... ?

That list already contained all used units, including those indirectly used. And the list for the project (root node in the tree) contains all units of the project.

Was already used, that was the first thing I checked.

Done. I even improved performance of the indirect list by a factor of about 5 to 10 (I didn't do any exact timing on the original code, so I don't know. But it now takes less than 2 seconds for the GExperts project where before it took more than 10.) Note to self: If the performance of some code is bad, check whether it stores and accesses data in the UI all the time. Remove this access and watch the performance skyrocket. Another note to self: TListView is one of the worst performing controls out there. If you want to improve performance further, use a TStringList or maybe even better a virtual string list.

@mael Which Delphi version are you using? And what does the GExperts -> Keyboard Shortcuts expert show for Alt+Ctrl+C on your installation? Please answer on https://sourceforge.net/p/gexperts/bugs/114/

@PeterPanettone Isn't GExperts -> Project Dependencies what you are looking for? The only shortcoming is that it does not list the indirect dependencies for the whole project, into which I am looking right now. If it's possible to be done easily, I will add that.

I cannot reproduce this in Delphi 2007. Which Delphi version are you using? And what does the GExperts -> Keyboard Shortcuts expert show for Alt+Ctrl+C on your installation? Please answer on https://sourceforge.net/p/gexperts/bugs/114/

If it's not available with full source code, I'm not going to buy it. I have been burned twice with buying components / libraries in binary form only where the company went bust a few years later. Apart from that I like the idea of using SVG for graphics a lot. It would solve several problems I am currently facing.

There are now two experimental options for searching forms that address these issues at least for standard components. The output still needs some polishing.