dummzeuch

Simple: I rarely make any calls at all. For those calls I still need to make, I prefer a SIP connection and a headset on my computer. My mobile phone contract even comes with an option to connect via SIP, but that is a remainder from old days, new contracts from that company do no longer offer this. And also, calls via SIP are not covered by the phone flat rate. So I have a different one paid for by my employer due to me working from home nowadays. I also have a land line, but that's for internet connection only, no phone was ever connected to it.

GExperts has no external dependencies (and as far as I know never had). It's just a matter of checking out the sources from svn and start the correct compile batch. All additional libraries (Synedit, Abbrevia and some more) are included in the repository. And since GExperts is a DLL (not a package) wizard, there is no conflict with other versions of theses libraries that may be installed.

I'm thinking about not bothering any more. Maybe have a generic installer for the additional files and registry entries required and letting the user compile his own DLL.. On the other hand there seem to be many Delphi developers who are adverse to compiling it on their own.

Some of this new fangled stuff is just not worth the effort. Now get off my lawn! 😉 OK, I'm getting old. More and more grey hair and receding hairline are obvious telltales. (My grandma was using the German expression "neumoderner Kram". Back then (in the 1960s) she was talking about the telephone with a dial. Having a private phone line was still something special in many areas of Germany in that time (so I heard). She never really learned the customary protocol for using it, that is, stating her name when calling. That was back then when phones didn't even display the caller's number, so you didn't know who was calling. Some kids nowadays are the same, they never learned it, because "nobody uses a phone for calls any more". And they are basically right: I rarely use my smart phone to make calls.)

No, didn't try yet. And with @Achim Kalwa's plugin, available (which I haven't tried yet either), I'm not sure I'll bother.

Yes, the was the first one I tried.

A while ago I blogged about my problems with installing TeeChart pro in Delphi 2007, which failed because it assumed the Indy packages to be the ones originally shipped with Delphi 2007 while I had updated to a much later version from GitHub. The problem was that the Indy packages do not adhere to the standard packages naming convention in Delphi. I would like to know why that is so: Is there a specific reason why the packages (e.g. for Delphi 2007) are called IndyProtocols110.dpk rather than simply IndyProtocols.dpk and configured the version specific 110 suffix to be added by the IDE? The difference is that the generated .dcp file is called IndyProtocols110.dcp rather than IndyProtocols.dcp. The .bpl file would still be IndyProtocols110.bpl. This would have the advantage that the entries in the required section would also not be version specific, so less changes were required for updating for a new Delphi version.

I got two 4K monitors and placed them side by side. And I discovered some interesting effects in Delphi 10.4.1: on the left a 32" monitor with 3840x2160, scale set to 125%, secondary monitor on the right a 27" monitor with 3840x2160, scale set to 150%, primary monitor IDE moved to full screen on the left monitor one undocked window on the right monitor (e.g. the refactorings window) When I now try to select any entry from the main menu, regardless if with the keyboard or the mouse, it is drawn far to the left. The "File" menu is outside the screen, only when the "Recent Files" entry is selected, this submenu becomes visible. The other main menu entries are moved to the left. It probably takes quite some skill to get this effect. 😉 https://quality.embarcadero.com/browse/RSP-31126 But as I discovered during the last week, programming for multiple monitors with different resolutions and scaling is far from easy, especially in older Delphi versions (2007) where Windows is lying about the settings unless you modify the manifest. Add Remote Desktop with Windows 10 client + Windows 8.1 host to the mix and it becomes impossible. What I got to work fairly well is Remote Desktop with Windows 10 on both sides with Delphi 10.2.3. I haven't tried more recent Delphi versions. I was surprised though, that GExperts didn't show any issues. Probably just luck so far.

Ouch! What was I thinking? And of course now I don't have access to my blog to correct this mistake.

If that decision has been made, you'd probably better learn to use git. For me, there is no such external decision maker involved. Really to GitHub or rather to a self hosted git repository? Is your current SVN repository also hosted off-site?

As it stands, I'm not a big fan of Getit. From the few packages i have tried to install, several didn't install currently. And don't get me started about the 10.4.0 patches... Anyway: Did you have a chance to look at the pull requests? Is it OK with you to continue in that direction for the time being (for Indy10). Working compile scripts make it simpler to compile the packages, that's all I want to achieve for now. I've got some ideas to improve them further, but before I invest the time, I'd like to get your approval.

What do you mean by "more streamlined"? Does getit provide a mechanism to compile and install packages? As far as I know it doesn't.

I got a bug report that the C++ code generated by the Components to Code expert to free a component is wrong. Currently it generates this: TEdit *Edit1; Edit1 = new TEdit((TComponent *)NULL); Edit1->Name = "Edit1"; Edit1->Parent = ParentPanel; Edit1->Left = 56; Edit1->Top = 8; Edit1->Width = 121; Edit1->Text = "Edit1"; delete[] Edit1; According to David G. Hoyle it should be done like this: delete Edit1; but according to the bug report it should be: Edit1->Free(); I tend to believe Dave, but since I don't do any C++ Builder programming, I don't know which syntax is correct.

I have just created a pull request (*1) for an updated build script for Delphi 2007. Apart from general cleanup and testing (the original simply didn't work) there is one notable change: It does not try to copy the generated *.bpl files to c:\windows\system32 This was a bad idea anyway and would not work nowadays. Also, no output files are generated in the source directories any more, everything goes into ..\d11, dcu files into ..\d11\dcu. There is one part in there that I don't understand: Why was there a special call to dcc32 to compile the unit IdCompressionIntercept.pas ? It's part of IndyProtocol110.dpk anyway, so why compile it separately? Does it require special compiler flags? @Arnaud Bouchez If you think that's the way to go, please give me a go ahead and I'll have a look at the other scripts. (*1: I hope I finally figured out how to correctly create pull requests on GitHub)

WTF? How did that happen? Sorry!!! Yes, I meant @Remy Lebeau

@Remy Lebeau is there any reason to not use msbuild for Delphi 2007 and later? I'd hate to spend time on figuring out dcc32 parameters only to be told "Why didn't you simply use msbuild?".

No, I haven't. Didn't know there is a free version and I already have a batch solution for all my projects which has the advantage of not needing any additional software. And of course that also needs yet another tool to learn. I guess you use Continua CI at work, so you know how to use it. I'll keep that in mind though, it might be worth spending the time (and possibly money).

Because I don't want to start all the IDEs to do a compile check (double click, wait, click, click, CLICK ...). I'd rather start a batch file that calls them all, one after another. I'll do a checkout and have a look what needs to be done.

I tried, but the call stack didn't give any clue where this call comes from. I guess the IDE is calling that event explicitly as MyPopup.OnPopup(Whatever) somewhere and the parameter isn't used in the original event implementation so it doesn't care what it is. The MenuItem neither has a name nor a caption, which is odd.

That's correct: GExperts does not do any theming, it simply uses the native VCL classes. The IDE tries to do the theming for these forms. Unfortunately it not only fails in many cases but these partly themed forms look really ugly. Therefore I have explicitly disabled theming for the Grep Results form in the current source code, so at least the form is consistent in itself. I am surprised to hear that the docked from is still themed though, maybe I did these changes after the DLL you are using was built. I won't implement theming. If somebody else cares enough, he is welcome to try and send me patches. I'll be happy to apply them as long as they don't break functionality.

Not sure what you are trying to tell us. The code in question was: procedure TGotoModificationBaseExpert.HandleOnMenuPopup(_Sender: TObject); var pm: TPopupMenu; begin pm := _Sender as TPopupMenu; if Assigned(FOrigPopupEvent) then begin FOrigPopupEvent(_Sender); end; AppendMenuItem(pm); end; So this already was an 'as' operation which bombed out in Delphi 10.4 because somehow a TMenuItem was passed as Sender. The new code looks like this: procedure TGotoModificationBaseExpert.HandleOnMenuPopup(_Sender: TObject); begin if Assigned(FOrigPopupEvent) then begin FOrigPopupEvent(_Sender); end; if _Sender is TPopupMenu then begin // sometimes Delphi 10.4.1 passes a TMenuItem here, no idea how this can happen, but it caused a runtime error AppendMenuItem(TPopupMenu(_Sender)); end; end; So now I first call the original OnPopup-event and then I check whether the Sender is really a TPopupMenu before adding an item to it. I can't see how this relates to what you wrote. There was no hard unconditional cast (OK, now there is, but only after an 'is'). There is no if .. is .. then else if .. is .. then.

WTF? It's a bloody TMenuItem! That doesn't even have a common ancestor with TPopupMenu (apart from TComponent)! Who in their right mind would do that? Fixed in revision #3325

Not likely, because there is lots of code like this which would break, keeping people from updating which would hurt the bottom line. The best we can hope for is a warning or maybe even a switch to turn 'with' off. And, actually, seeing how many 'with' statements there are even in the RTL / VCL (haven't checked FMX) and even in our own code (where I try to eliminate every 'with' I come across when I edit code), that's probably a good thing. But we digress...

Did you already install the fix for Delphi 10.4.1 ?

This is the last (known) remaining class helper loop hole that was overlooked when they closed the previous one that didn't require a 'with' statement. Don't expect this to keep working in future Delphi versions. (OK, I'll shut up with this warning now.)