Topics

• I know that update projects with tasks ready to report functionality was requested in the past and is already in the ToDo list. I just wanted to add that the Update project(s) right-click context menu entry could be equivelently available not just in the Tasks window, but also in the History window.
• History size could get few additional options to keep results for more than 30 days, possibly also a Forever option?
• There is an "Extra / Update all projects" menu entry. I think that such operation is not that common in projects' micromanagment Because I can relatively simply switch to the Projects window, select all available projects with left-mouseclick to top + Shift-left-mouseclick to bottom + right-mouseclick Update.
  Possibly a menu entry to "Report all finished" tasks a.k.a. "Update all projects with tasks in Ready to report state" would be much more useful?
• It is currently not possible to move the (project or task) line selection up/down with cursor keys, to resize the lines' selection with Shift+cursor keys (this all is already functional in the Messages window), or to select all lines with Ctrl+A or some equivalent (like Home + Shift+End keys, which works in Messages).
  Nevertheless, moving the "current" line is somehow supported in these window, because if the window height is smaller then the number of projects or tasks, the list is being scrolled by Up/Down cursor keys or PgUp/PgDown as if some invisible imaginary line would be moving them.
• In the Projects window, it is not possible to select an arbitrary
  list of projects by e.g. left-mouseclick to third + Shift-left-mouseclick to seventh - you can just select first-to-last. Ctrl+click is working correctly

Sorry for reporting also bugs in the wish list, I felt this belonged together.

My BT 0.29 seems to consume some 205 MB memory (Private, Pagefile). The Peak Working set is also around 220 MB, but settled down to 8 MB, thus it possibly happened just at the startup (a couple of minutes ago).

Is such (IMO) excessive memory requirement necessary for BT?

The application has 3 computers defined, but just 1 is reachable, 2 are and will out of reach.
Among the allocated memory, the process has 3 x 53.43 MB and 3 x 10.7 MB (possibly pre-allocated) blocks of memory (in the system commit), which seem to correspond to the 3 defined computers. Are they necessary to be statically pre-allocated in their whole size and in advance?

I've just noticed thet my TThrottle 1.71 is using an incredible number of handles: according to Process Manager, after a week of runtime (and consuming 3:50 hours of kernel time and 1:02 hours of user time) it uses 1 330 535 Handles, 102 GDI Handles, 261 USER Handles. (For those unaware - just 10 apps on my system use more than 1000 handles, just 4 of them between 2000 and 6000 handles.) The first number does not move, the latter two numbers oscillate around the mentioned values. I've noticed it in the Task Manager - TThrottle was consuming 10.5 MB of system's Paged Pool (maybe 15% of the whole system).

This is just an initial notice, later I'll investigate when the number of handles does go up...

After "desperately seeking my rosetta@home project for a couple of seconds long", I've noticed that the projects are alphabetically listed case-sensitively, i.e. first the projects which names begin with a capital characters, followed by projects beginning with lower case characters.

Could the sorting be done in a case-insensitive way?

Just a minor cosmetic problem, seen in TTh 1.69 and at least one previous version:

• In the Programs tab, the "Temperature / Core" field has a gray background, which also indicates that its value can not be edited. The "Run time / Running Cpu" field next to it has a white background, which may suggest that it can be edited, although the field is also read-only. This field should be IMO grayed too.

At some point in time I'd like to make a Slovak translation.

It should be also understandable for most Czech users, or a good starting point to create their native translation. (I could also create a rough Czech translation in paralell, but I do not intend to be laughed out .)

One wish to the automatic graph scaling:
Currently when any curve touches any 10º line, the graph is resized accordingly, that an additional free 10º area is visible on both sides of the touched line.
When the Throttling curve is constantly drawn at 100% (and the temperature curves are below it), the graph is unnecessarily resized by one more completely free 10º area above the line (100º - 110º). But there is actually one more free area 1º wide.
Could the resizing be redefined to "If any curve crosses any 10º line (i.e. should be displayed at e.g. 91º or 69º), then the graph is resized by one more completely free 10º area above/below"?

A bug:
When my target temperature is set to 75ºC, after changing the preference to use ºF, the target temperature is recalculated to 167ºF, but the graph remains displaying the target temp line at 75ºF. Even after changing the target Fahrenheit temperature, the graph keeps displaying the target line at its Celsius temperature.