dummzeuch

The Goto expert is work in progress. I'm not yet sure where I want to go with it. So far it's simply a replacement for the Goto enhancement.

I removed a unit from the 10.3 dproj file this morning. It might work now, but I cannot test it.

I also needed such a tool a while ago but could not find one. I ended up changing the code in GExperts to dump the contents to a file.

I'm currently on vacation and have no access to IDEs newer than XE4, so I can't check this. Would you please file a bug report on SourceForge so it doesn't get lost?

Oops, so a component/expert built with 10.3.2 does not necessarily work for 10.3.0 or 10.3.1? Since people without maintenance don't get the point versions, they are double fscked. Or the component/expert vendors/maintainers have to create two versions of their exes meaning they have to keep the older IDE versions around. And since it's not possible to install e.g. 10.3.1 and 10.3.2 on the same machine, that means they have to use multiple computers or multiple VMs. Great, just great!

https://blog.dummzeuch.de/2018/08/04/improved-uses-clause-manager-in-gexperts/

And this is the first error message? Or is there another one before it?

Yes, I know, it was about time ...

With which version of Delphi does it compile? (Sorry, if you stated that before, I missed it.) I tried Delphi 2007, just because that's the version I have configured to open dpr files by default.

* The sources for tb2k (Toolbar 2000 ?) are missing. (Just downloaded them from http://www.jrsoftware.org/tb2kdl.php I wonder about the license though). * The obj subdirectory in pngimage is missing. (adler32.obj and friends (I guess that's a reason to use the dcus. 😉 ) adler32.obj is part of Delphi since XE2, haven't checked whether it works and also about the other missing obj files yet, but I seem to remember that pngimge became part of Delphi around that time. No, just copying the obj files from Delphi 10.3 didn't work: "Unsatisfied forward declaration _llmod") I think I'll give up for now.

Thanks a lot for providing the sources. I just had a look at them and found that there are plenty of dcu files in the same directory as the pas files. Is there a reason for including the dcus at all?

After being bitten too many times, I only install the components with the vendor's installer the first time to get the source code (because that's the only way to get the source code for many components). I then check the source code into source control and remove everything that was installed into my IDE(s) and search paths and whatever. Then I compile the components from source (cursing a lot along that process because component vendors simply don't adhere to any standards) and install them into the IDE I need them. Once that works, I document the process and try to automate it. I then test the (automated) process by removing all traces of the components again and installing them. I fix any bugs of the process I encounter then (there are always bugs). After the installation process works, I remove any paths the installation process added to the IDE configuration. Component sources are always part of my projects that use them. I add them as svn:external to the project and add the search path as relative paths to the project. Rinse and repeat for any IDE version which needs them. Once that's done, everything usually works smoothly. But to get there is a pain in the lower back.

File a bug report, giving them as much info of your OS and graphics hardware setup as possible. And don't forget to include screenshots like the one above and also one which does not show these controls at all.

When you register a new wizard with the IDE using the Open Tools API function IOTAWizardServices.AddWizard you get an index back. Is there a way to get any information about wizards added that way? I'd prefer getting a list of them with the associated index, but a function that for a given index gives me information about that wizard would also be fine. The reason I'm asking is that I sometimes get an error message when closing the IDE telling me about an error in Wizard xx, where xx is a number (17 in my case), and I would like to know which of the installed wizards is causing it without having to disable each of them and hoping the error occurs (which does not happen reliably enough for this method).

Just in case anybody has got write access to RosettaCode: There is a bug in the Pascal implementation: https://rosettacode.org/wiki/Averages/Mean_angle#Pascal It checks the average cosine against eps like this: if c > eps then MeanAngle := RadToDeg(arctan2(s,c)) else // Not meaningful MeanAngle := 0.0; But it should actually check the absolute value of c like this: if Abs(c) > eps then MeanAngle := RadToDeg(arctan2(s,c)) else // Not meaningful MeanAngle := 0.0;

No, but you won't see them if you have disabled themes (which is no longer supported but can still be done using the registry).

Having read a bit about the theory, I think the check for sumcos (or sumcos/count) being significantly different from 0 is valid. The algorithm converts the angles to vectors and adds these vectors, it then calculates the angle of the resulting vector. To do that, it calculates the arctan of sumsin / sumcos which would be undefined for sumcos = 0 (or very near 0). But since it uses vector addition, also sumsin = 0 and sumcos = 0 would be a problem because that resulting vector would point to the origin and therefore it would not be possible to calculate an angle. I guess that's what Boris meant here: Also, this does not work as expected in some cases: MeanAngle(0, 0, 30) does not return 10, as I would have expected, but 9.896. There is a nice explantion of the math here: Averaging Angles - math doctors

There is a not obvious button to the left of the desktop selection dropdown in the title bar, which shows a menu:

So it should look like this: function MeanAngle(const a:tAngles;cnt:longInt):double; // calculates mean angle. // returns 0.0 if direction is not sure. var i : LongInt; s,c, Sumsin,SumCos : extended; begin IF cnt = 0 then Begin Result := 0.0; EXIT; end; SumSin:= 0; SumCos:= 0; For i := Cnt-1 downto 0 do Begin sincos(DegToRad(a[i]),s,c); Sumsin := sumSin+s; SumCos := sumCos+c; end; Result := RadToDeg(arctan2(SumSin,SumCos)); end; * no division by cnt * no check for eps

So, what do you propose the code should look like instead? (Especially when removing the divide by cnt.) I must admit that I have only compared what it does to some other contributions on the site, not really tried to research the algorithm itself.

How do I do that with other wizards? After all I am registering only mine. One odd thing I found was the the index returned by IOTAWizardServices.AddWizard is always 0, which is odd given that according to the splash screen my wizard is not the first to be registered. Many examples I found on the interwebs treat this as an error. But I could not find any official documentation on the results of that function. (And I don't think that's the cause for the error message.)

I didn't say that I think some other wizard is causing mine to crash. I just know that there is one wizard which crashes the IDE (or rather causes the error message) on shutdown. I am not sure that it is my wizards that's causing the crash. That's why I wanted so see which one "expert17" actually is. If it's mine, I have to look further, if it's another one, I might just have to live with it. Yes, of course I have tried to debug it. I have found one problem that might have caused the error (never mix interfaces and object references...). It hasn't occurred since then, but that might just have been pure chance. Yes, I do. The wizard I am talking about is GExperts, so listing what it does might be rather time consuming. It depends on the default IDE designtime and runtime packages.

Two more formatter bugs just got axed: #133 Code formatter does not support the "Final" keyword #134: Formatter does not handle variant records with methods correctly Also found a problem with the Uses Expert, but that was not in the released code yet.

I have got two programs, both written in Delphi using the VCL. Program1 excecutes Program2 using CreateProcess, passing some parameters. In some circumstances I would like Program2 to return a string to Program1. Since CreateProcess only returns an exit code, which is a number, this requires some additional communication. Converting program2 into a DLL or Package is not an option in this case, neither is integrating the source code of program2 to program1. The simplest way would probably be that program1 passes a file name to program2, program2 creates that file, writes the string to it and exits. It could of course be implemented much more complicated, e.g. via sockets, Windows Messages, Shared Memory or even WriteProcessMemory. Have you done something like this? If yes, which method did you use and what was your experience?

My recommendation is simple: Don't use the WITH keyword. There are not just the problems you mention. It can also be difficult to determine the scope of an identifier within a WITH block. Example: var Caption: char; procedure TMyForm.Button1Click(Sender: TObject); type TSomeRec = record Caption: integer; end; var Caption: double; SomeRec: TSomeRec; begin // [lots of code] with SomeRec do begin // [lots of code] Caption := 'bla'; // <- which Caption variable/property/field is accessed here? And why does it not compile? end; end; We have had this discussion so many times that it is really pointless to start it afresh. Just google it.