Leaderboard

Yeah, modal dialogs and popup are deeply invasive. Find a different way to let the user know.

I would try to find out when used memory grows in size. After opening a certain form, or after compiling, or after starting the program, or after interrupting of execution Ctrl-F2... Try to temporary disable third party plugins and CodeInsight features (Error insight, Help insight).

May be it will be easier to define empty System.Actions unit for Delphi XE than to fight with Delphi RIO (put it in a directory, where XE will search, but RIO will not).

What IDE add-ons/experts do you use?

When you load different libraries 64/32 bit

The TDictionary.Keys property uses a singleton, so no matter how many times you read the Keys property itself, there will only be 1 TKeyCollection object in memory. However, every time you call ToArray() on that collection, it will allocate a new array in memory and populate it with the current keys. Dynamic arrays are reference counted, so every assignment to the local tdictkeys variable will decrement the refcount of the old array, freeing it, and increment the refcount of the new array. When the method exits, the refcount of the last array allocated is decremented, freeing it. If the dictionary is continuously growing in count, then the loop above will allocate larger and larger arrays accordingly, , where a new array is allocated before the previous array is freed. So yes, that has the potential to cause an OOM error over time, depending on just how large the dictionary actually grows. At the assembly level, yes. But if the binary has external dependencies on DLLs/APIs that don't exist on the machine (and modern versions of Delphi's RTL do use APIs that don't exist in Win2K), then the binary will not be loaded by the OS and will not be allowed to run any of its code.

F.i. SnagIt uses Shift-F9 for Video Capture per default.

Another program may capture Shift-F9 ?

You can hexdump each compiler EXE to see which conditional symbols are actually available. That is what I do sometimes.

Well, I am sure you will understand that it's not really nice to advertise another product in a thread specifically presenting HxD. I have invested many years into it (since 2002), and it has been Freeware all the time. A little respect for that effort would be appreciated.

I finally got to the bottom of this error. It's a bug in the Parallel Programming Library that ships with 10.3.2 and 10.3.3. Here's what happened... After I downgraded to 10.2.3 I was just pleased that the freezing stopped. I was also concerned that I'd be stuck using 10.2.3 for ever. So this week I upgraded again; this time to 10.3.3 in the hope the bug didn't show up in this version (the bug had initially appeared in 10.3.2). Unfortunately it showed up—I was gutted! I tried replacing the memory manager - that didn't work. I tried checking for resource leaks; there weren't any. I then switched the main rendering routine to use OmniThread instead of the PPL and that corrected the bug. It seems that after being under load, and then left for a while, the PPL's can suspend some threads for a period of up to 1 minute. If the suspended thread is in a "for" loop the program freezes. Eventually the application comes back to life but it happens repeatedly. The bug wasn't present in 10.2.3 but was present in 10.3.2. I'm elated that the bug is gone! Steve

Been experimenting with it myself and there are things I like. I will give a full report on it once they address some things I reported.