dummzeuch

Do you really want to check out the whole repository or only the trunk? If the former, this is correct, if the latter, add /trunk to the URL. The result will then be a working copy that can be updated with svn update From within that directory.

Try to spot these: fViewSignups:= tfViewSignups( Self ); Also quite difficult.

Does anybody know what happened to the DIBControls by Droopy Eyes Software? Their website vanished in 2007, but the Wayback Machine remembers it: https://web.archive.org/web/20071009172906/http://www.droopyeyes.com/default.asp?mode=ShowProduct&ID=3 I was able to even download the sources (Haven't looked at them yet). Have these components maybe been included into any other component packs? Does anybody have experience using them? twm

I definitely wouldn't, at least not if it is about transferring large amounts of data between programs on the same computer.

Given a unit that exports a function that should be inlined: unit bla; {$INCLUDE 'jedi.inc'} interface function blub: integer; implementation function blub: integer; {$IFDEF SUPPORTS_INLINE} inline; {$ENDIF} begin Result := SomeCalculationHere; end; Is it OK to put the inline only in the implementation? Or does it also have to go to the declaration in the interface section? It compiles OK this way, but I don't know whether it would still be inlined. I'm asking because I would like to keep the interface as clean as possible which means avoiding to clutter it with an ifdef.

As I add new functionality to GExperts the menu it displays grows larger and larger. On small monitors (there are still computers with e.g. 1024×600 pixels screen size in use, usually not with the latest Delphi version though) this means that the menu has to be broken into chunks, each with a “more” entry at the end to display the next chunk. While this has been implemented for years (decades actually) it didn’t work very well. For Delphi 6 the code was completely broken (I might have been the culprit myself) it still had some bugs with all later versions. No more. Today I fixed those bugs and tested it with screens as small as 640×480 pixels. Also, when moving the GExperts menu into the Tools menu, there was a problem that the maximum number of entries for a chunk was not calculated correctly which would mean that the “more” entry could end up outside the visible area. This has also been fixed. Unfortunately this does not solve the underlying problem: The menu keeps growing. There are now a maximum of 45 + 3 Entries in that menu. [read on in my blog post]

From my blog post: But thanks for your suggestion on how to group them. I'll keep that in mind once I get to actually implement it.

That page is petty much dead. The only way to reach anybody of the Jedi team (the few that are left) is through GitHub.

If you want this bugfix to be included in the JVCL, you will have to create a pull request on Github.

If dropping frames is not an issue, why bother with such a large buffer? Two frames would be enough.

If that's acceptable, simply using files would probably be the easiest way. Since we don't know what those programs actually do with the images, that's difficult to decide. If files are too slow, I would probably go with memory mapped files with two buffers and a combination of mutexes and events (event as in syncobjs.TEvent). One buffer is always available for the sender to fill. It doesn't check, just locks it (using the mutex), writes to it, unlocks it and sets an event to signal that data is available. The receiver is the part that manages which buffer is currently to be written to. It then waits for the event, switches the write buffer to the other one and starts processing the data. If that takes longer, the sender will overwrite the data in the write buffer as long as necessary. Yes, I think that would work. Needs a bit of polishing though.

I'm in the process of restructuring the GExperts sources. Currently the trunk is broken. If you want to compile your own DLL, use the https://svn.code.sf.net/p/gexperts/code/tags/before-switching-to-original-dzlib tag.

They compile again. But there are still a few warnings and hints I need to investigate. Also, some testing will be in order.

I just had a nasty surprise with Delphi 10.3 when trying to build a project that worked fine with previous Delphi versions. The problem turned out the text one of my pre build events wrote to the output. It contained the string "error :" [...] read on in my blog post

I apparently doesn't care whether there is a space between 'error' and ':' or not. I haven't investigated any further, e.g. if "warning:" also counts as a compiler warning. Even if it is meant as a feature, it's definitely not implemented correctly as there should not be such an additional and confusing error dialog. And of course it should have been documented.

Let me rephrase that: "The request, that I think has low priority, might have higher priority for a customer and he might be prepared to pay for it."

It's also a question whether the customer is willing to pay for his request to be implemented. My low priority request might have a much higher priority for the customer.

already reported: https://sourceforge.net/p/gexperts/bugs/132/

Fixed, try now.

Oh great, it's yet another Theming issue: The menu items on my computer are 24 pixels high, but GetSystemMetrics returns 20. That's why too many menu items were displayed which resulted in the menu being too high and overlapping with the main menu entry. On top of that, I can no longer debug GExperts in Delphi 10.3.3: The IDE crashes when the GExperts initialization starts. But not the debugged IDE but the debugging IDE. 😞 If that wasn't odd enough: I can start an IDE with GExperts fine, it ony crashes if I try to debug it.

Hm, I just tried to reproduce this on my computer. Doesn't happen. Could you please select the GExperts menu via keyboard (which should not have the effect of executing the first menu entry) and create a screenshot? Edit: Forget it. I just managed to reproduce it.

Please check that you are using the latest svn sources. Your first post says "13 hours ago", that would have been about 21:00 yesterday (CET). It might just have overlapped with my last commit.

That's one of the problems that I thought I fixed yesterday. What's your screen resolution(s) and scaling? If multiple monitors: Which one is primary and which one is the IDE on? Do you have the task bar on both?

Run the batch file in the images folder first.

Theming is a gift that keeps giving: https://quality.embarcadero.com/browse/RSP-27318 (Of course this is not my working environment, I just created it to track down a problem with GExperts.)