dummzeuch

As far as I know they can only read from the registry. I'm also not sure when the IDE updates these entries: Whenever they change or only when closing.

I know of only one "pure pascal" solution for jpeg compression: nativejpeg

You could try to use libjpeg-turbo (or even the original libjpeg, but I don't recommend it). I don't know how do use that with TBitmap32 though, I only used it with TBitmap and a BGR-in-memory-buffer. There are Delphi interface units for it.

Bug report(s) on Sourceforge please.

general FAQ bug reports

Bug report on SourceForge please.

Some things that were obvious in the VCL apparently are not in FMX. I want to change the background color of a single control on a form, e.g. set a TEdit control which failed input validation to yellow. This must not affect the color of the other controls on the form. In the VCL I would simply set TheEdit.Color := clYellow. An FMX TEdit does not have a Color property. Instead apparently one has to use styling, controlled by the properties StyledSettings, StyleLookup and StyleName. Am I missing something? How can I accomplish this?

Now this is interesting. I wonder whether the TVirtualTreeView descendant used in the Delphi IDE also implements that API. Not having access to the entries in these various trees has prevented me to implement some useful functionality.

You are out of luck. TVirtualStringTree is completely written in Delphi and does not have an underlying Windows control, so there are no messages that can be intercepted.

That would be illegal. Are you saying that it would be illegal to ask a friend to compile Delphi source code on their own copy and send me the exe? No, it would be illegal to send you "the compiler exe". That's what he wrote, but apparently he meant to write "the compiled exe". That would be perfectly legal. Sorry for the misunderstanding.

That would be illegal.

Hm, all GExperts units have an underscore in the name: GX_Whatever and all units in my dzlib library do too: u_dzWhatever as well as most units and forms in the projects at work: w_Whatever and u_Whatever. We are not using D11 yet at work (and for GExperts I try to avoid it too because it always breaks the dfm files), but that doesn't bode well. I wonder whether using underscores in unit names is that uncommon that nobody has come across a problem with that during the beta.

Yes, they have been broken basically since forever and for the CurlyHalfCommentEnd one I don't really care much. But the MultilineFunctionDirective bug is really annoying. I must find some time to finally fix that. The way the tests currently work is by checking the all the supplied settings with various input files and comparing them to the output files. Testing one particular setting is currently not really part of the test. Maybe it would be easier for you to simple create a new TTestCase and, based on the default settings of the formatter, only run the two tests you mention. btw: Thanks for caring about the unit tests. That's a first for any contributor.

I seem to remember something about that on on StackOverflow. GExperts only shows a warning if more than one instance of the same IDE version is opened. I usually disable that warning because I actually want to habe multiple instances (for multiple projects on multiple virtual desktops). Then I have no idea what the problem might be. You can download the help file from SourceForge just in case your version is broken.

Maybe its not the file itself but the project that's broken?

I'm pretty sure that wasn't meant as a joke. You didn't mention that it happens rarely, so he probably assumed the problem to be reproducible. In that case uninstalling stuff until the problem goes away would have been a good strategy.

GExperts does not have such a functionality. As for the help not showing: Is that a standard installation or did you copy the help file somewhere else? The help file in the installer is definitely fine, I just checked. It's many years out of date though since I have never updated it.

Given code like this: var arr: array of TSomeLargeRecord; begin SetLength(arr, 5000); // fill the array SetLength(arr, 100); // work with the smaller array end; Does the last call to SetLength actually reduce the memory required for the array? I'm suspecting that it only reduces the internally stored capacity but the memory will remain allocated until the array is finalized, that is it goes out of scope, is set to NIL or SetLength(arr,0) is called.

Then I'm out of ideas. Last resort is probably reinstalling Delphi and keeping your fingers crossed that it actually solves the problem. Hm, maybe: If you have got another working Delphi installation, you could try to export the registry settings from there and import them into the broken installation (can't break much more, can it?) Alternatively you could export both and compare them using a text comparison tool, maybe that sheds some light on it.

Can you still open the IDE by starting bdslauncher.exe? Does double clicking a .dpr or .dproj file still work? What happens if you start bdslauncher.exe from a cmd prompt and pass a .pas file as parameter?

Have you tried to set the default application for .pas files again? In recent versions of Delphi that's an option in Tools -> Options, not sure about Delphi 2007. On the other hand, personally I don't want to open .pas files with the IDE but prefer Notepad++ for that. And I don't want to open .dpr, .dpk and .dproj files with bdslauncher either because it always opens them with the latest Delphi version (or the one that has been registered as the default handler last) rather than the one the project actually needs. Shameless plug: dzBdsLauncher

The following is about a 32 bit Windows console application. I'm trying to improve performance for analyzing a huge Mono8 bitmap, stored in memory as a an array of bytes (no TBitmap involved). For each pixel the algorithm calculates the brightness for the pixel itself as well as a few surrounding pixels and writes the result to an array of byte. Doing this single threaded takes about 1300 ms. Since this can be done by multiple threads completely independently without the risk of race conditions I have split the work into n work packages, each processing some lines of the bitmap and each processed by a separate thread. The threads have been created in advance in a thread pool. Since there is no risk of race conditions I don't use any synchronization or locking mechanism during the processing. Synchronization is only necessary for assigning a work package to a thread and for signalling that a work package has been processed. This is the relevant code of the thread's execute method and the SetNext method called by the main thread to assign a work package to it: procedure TWorkerThread.Execute; begin inherited Execute; while not Terminated do begin FNewPackageEvent.WaitFor(500); FNewPackageEvent.ResetEvent; if Terminated then Exit; //==> FCritSect.Enter; try if Assigned(FData) and Assigned(FWorkCall) then FWorkCall(FData); finally FCritSect.Leave; end; end; end; procedure TWorkerThread.SetNext(_WorkCall: TWorkPackageCall; _Data: Pointer); begin FCritSect.Enter; try if Assigned(FData) or Assigned(@FWorkCall) then raise ESigException.Create('Programmer error: Package is already assigned.'); FData := _Data; FWorkCall := _WorkCall; FNewPackageEvent.SetEvent; finally FCritSect.Leave; end; end; FNewPackageEvent is a TEvent and FCritSect is a critical section, each unique to the TWorkerThread instance. A work package consists of a data pointer and a procedure pointer (not method pointer) to call. When a work package has finished processing a counter variable gets decremented like this: InterlockedDecrement(FCounter^); The main thread also processes one work package (it's also counted as one of the threads below) and then waits for the others to finish: while WorkPackageCounter > 0 do Sleep(WorkPackageCounter); (FCounter above is a pointer to WorkPackageCounter). Since every thread only processes one work package the counter starts as the number of threads. This works fine but I get some rather odd timing: Average time on 1 calls using 1 threads 1278 [ms] Average time on 1 calls using 2 threads 877 [ms] <------ Average time on 1 calls using 3 threads 1627 [ms] <------ Average time on 1 calls using 4 threads 1580 [ms] Average time on 1 calls using 5 threads 1511 [ms] Average time on 1 calls using 6 threads 1167 [ms] Average time on 1 calls using 7 threads 1438 [ms] Average time on 1 calls using 8 threads 1036 [ms] Average time on 1 calls using 9 threads 957 [ms] Average time on 1 calls using 10 threads 847 [ms] Average time on 1 calls using 11 threads 958 [ms] Average time on 1 calls using 12 threads 843 [ms] Average time on 1 calls using 13 threads 821 [ms] Average time on 1 calls using 14 threads 715 [ms] Average time on 1 calls using 15 threads 799 [ms] Average time on 1 calls using 16 threads 647 [ms] Average time on 1 calls using 17 threads 693 [ms] Average time on 1 calls using 18 threads 656 [ms] Average time on 1 calls using 19 threads 525 [ms] Average time on 1 calls using 20 threads 613 [ms] As you can see, distributing the work to 2 threads nearly halves the processing time, but adds some overhead which is what I would have expected. But distributing it to 3 threads all of a sudden takes more time than the single threaded approach. When adding more threads the processing time goes down again until it reaches some kind of minimum with 15 threads. This timing is from only a single call, but I also tried it with 100 calls and the average was about the same. The CPU is an Intel Xeon with 4 cores + Hyperthreading which gives me a logical 8 processor cores. Can anybody give me a hint what to look for to explain the oddity of 3 threads taking longer than 2 threads?

As Uwe said: Since this works for most others (it definitely works for me), the question is rather what is broken in your System? As a first step, start with a new project and test whether it works there. If it does, there is probably something wrong with the dproj file of the non-working project.

I am working on a cheap Fujutsu Esprimo mini PC. (I am sure that at least as many people are interested in this as in Linus Torvalds having bought an expensive Apple thingy. 😕

No, but I did today.