dummzeuch

https://blog.dummzeuch.de/2019/03/31/changes-between-gexperts-1-3-12-and-1-3-13/

https://blog.dummzeuch.de/2019/03/30/gexperts-1-3-13-experimental-twm-2019-03-30-released/

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

1. Kick the person who bought this component without source. (Who was / is an idiot, nobody did that even back when Delphi 7 was new.)
2. Suggest not updating to Delphi 10.3 but 10.2 (which will be rejected)
3. Go with the DLL solution.

OK, so what I originally wrote was basically correct:

1. Fork the original repository to create your own copy of it on GitHub
2. Create a local clone of your own fork using e.g. GitHub Desktop
3. Make the change.
4. Commit it
5. Push it to GitHub
6. 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.)

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.

I have just discovered a bug in TJvCustomAppIniStorage.DeleteSubTreeInt and fixed it. So now I would like to contribute it back to the JVCL.

Just so I am sure I understand what I need to do to create a pull request for a bugfix in the JVCL:

1. Create a GitHub account (done)
2. Create a repository on GitHub
3. Clone the existing JVCL repository to a local directory using git
4. Change the parent repository to my repository somehow on the command line
5. Make the change
6. Commit and push it to my repository
7. Somehow (I am not quite sure how yet), create a pull request on that using the github website.

And all that so somebody can actually look at it and decide that it is a bug and copy my code to fix it?

Is it really that complicated or am I missing something here?

10 hours ago, Holger Flick said:

There is the new unit IOUtils. What does TFile, TPath, or TDirectory use?

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/

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.

3 hours ago, Attila Kovacs said:

I'd try to override the "show" process and call showwindow with SW_SHOWNOACTIVATE.

Maybe there is already something in VCL. 

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.

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.

On 3/19/2019 at 9:43 AM, dummzeuch said:

Not a bug.

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

28 minutes ago, Sherlock said:

Thank you! I thought I was the only one with "small" applications. My main application only has 18.000 LOC client side and roughly 5000 LOC server side. And its a medical device developed for cross platform use...

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.

1 hour ago, Stefan Glienke said:

Large enough that you don't want to rebuild third party code every time you hit F9+something or waste minutes on the CI server

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...

17 hours ago, Stefan Glienke said:

If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue.

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

1 hour ago, edwinyzh said:

I'd like to bring this to your attention - I created a ticket about suppressing all error dialog boxes during the GREP search, over a week ago.

Yes, I noticed that one. Thanks.

1 hour ago, edwinyzh said:

On the other hand, I'm wondering if is it possible for me to make svn commits to the repository for fixing small issues like this 🙂

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.

3 hours ago, PeterBelow said:

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

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.

1 minute ago, Jacek Laskowski said:

I knew that you're sticking to it ... 🙂
I try to eliminate warnings from my own code, but I have warnings from external libraries, eg Synapse, DCPCrypt and others.

Kick those lazy bastards into the ass! 😉

As a workaround you could add a {$warnings off} and {$hints off} into theses 3rd party units.