dummzeuch

GExperts has recently gained a few new features: Two new experts to start/stop recording and to replay a keyboard macro. These are minimal experts which allow you to add additional keyboard shortcuts to the existing IDE functionality. The idea and the code were contributed by Dejan M. Goto Previous / Next modification Editor Experts. These again ... https://blog.dummzeuch.de/2018/12/15/new-features-in-gexperts/

fixed

Or you could compile to the application folder and (re) move the other files in a post build event. That way the debugging still works.

Embedding a DLL can be done without extracting it (at least for some DLLs for 32 bit Windows programs). But I am not sure whether this would work with that DLL. My dzlib contains a unit for that: u_dzRessourceDllLoader.

I think you found all options. There are no others. I would Kick the person who bought this component without source. (Who was / is an idiot, nobody did that even back when Delphi 7 was new.) Suggest not updating to Delphi 10.3 but 10.2 (which will be rejected) Go with the DLL solution.

OK, so what I originally wrote was basically correct: Fork the original repository to create your own copy of it on GitHub Create a local clone of your own fork using e.g. GitHub Desktop Make the change. Commit it Push it to GitHub On the repository's website create a pull request. I just did that, let's see what happens. https://github.com/project-jedi/jvcl/pull/74 Thanks everybody who helped. The crucial step is to first *fork* the original repository on GitHub rather than clone it. (OK, maybe I am not to stupid to use git after all.)

When searching for "windows fastest way to check if a file exists" I get lots of hits that claim there is no API for it and one should use GetFileAttributes or FindFirst instead. But there is PathFileExistsA which according to the description does exactly that: Check if a file exists. It has been around since Windows 2000. Yet, FileExists in System.Sysutils still uses GetFileAttributes. Am I missing something? Is maybe GetFileAttributes actually faster than PathFileExistsA ?

OK, I hereby admit (yet again) that I am apparently too stupid to work with git. Thanks for trying to help, but I won't bother. I have more important things to do.

Sorry to be such a noob: I have cloned the repository to a local directory, made the change and committed it. Pushing it of course won't work because I have no write access the the remote repository. If I select "Branch -> Create Pull Request" the app asks me to push the commit (which I don't because see above) and the takes me to the github page. I'm lost now. Are you sure I don't need to clone the repository to my own github account first?

OK, I'll give the GitHub Desktop app another try. Thanks a lot! btw: unit JVJclUtils; function LeftStr(const S: string; N: Integer): string; { LeftStr return a string right-padded to length N with blanks. } WTF? Took me quite a while to figure out why my bugfix didn't work.

They simply call SysUtils.FileExists.

In the teechart support forums?

This is nothing to write home about, really, just a small change: Previously when starting the tool, the main window was shown for a short time before it got hidden. Now that no longer happens. Don’t now what this is about? You are probably lucky then and don’t need this tool. But if you still want to know, go to the dzEditorLinenedsFix page. https://blog.dummzeuch.de/2019/03/23/dzeditorlinendsfix-1-0-4-released/

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.