Forum Replies Created
The keyboard buffer issue is an interesting one. The solution is not obvious. The controls react to keypress as they should, as does any Windows program. What’s missing is the focus rectangle. In fact you can use the TAB key to move the focus to the next control, you just can’t see the focus rectangle but it’s still doing it.
Remember DTI merely starts the external process and goes right back to pondering it’s navel. It’s not waiting around for the external process to end, it’s long forgotten about it. So the issue seems to be that at some arbitrary point in time DTI receives a key down message from Windows and dutifully sends it to the control that currently has focus.
You can test this:
Click on one of the CONTROLS then close that window.
Press the SPACE bar and watch the first CONTROL trigger. This is the control that has focus. Close that window.
Press TAB then SPACE and watch the next CONTROL trigger.
Press TAB then SPACE again and watch the next CONTROL trigger.
Click on the cmd.exe CONTROL, type exit and enter. Watch the control with focus trigger.
In other words, DTI is behaving exactly the way a Windows program is supposed to behave. The problem is Windows (cmd.exe) keeps keystrokes in the keyboard buffer when it probably shouldn’t.
So the question is, should DTI respond to key presses at all and exactly how should it respond?
Perhaps an option to ignore external keystrokes?
1. You’ll have to explain this some more.
2. This will be available in the next release under the guise of regular expression support.
Unfortunately no. The total driver packs is now over 30GB so torrent is the only viable solution.
This is part 1. It is a basic implementation of GetExtendedTcpTable. It shows a list of processes that have active network connections and processes that are listening.
I believe the tool you mentioned tracks the network activity of each application by module name rather than process id. The up side is when an application goes away and comes back, the counting continues, the down side is multiple connections within the application or multiple processes of the same application are counted as one.
The alternative is tracking by process id which is much more granular but also makes the list a whole lot bigger in the case of a browser for example.
Part 2, I think, is implement process network activity tracking.
3. it seems there’s no windows performance counters that will give network activity per process. I notice netstat doesn’t do that either. Netstat does show network connections and the executable associated with each connection but no throughput stats. I think I can emulate netstats using the GetExtendedTcpTable API call.
that’s the plan… regular expressions is how we’ll do it.
hrm…. It doesn’t work well in that case. Need to find a way to transform the raw data before it gets to the display.
Regular expressions here we come…..
- This reply was modified 2 weeks ago by Glenn.
Looks like charts for the most part. I recommend you read the manual around page 33 for a full explanation of the new charts.
The pipe symbol ‘|’ is used by DTI to denote a new line in the display template. There’s an undocumented common option you can use to disable that for a single item called multirow.
comment = text:this|is|multirow, multirow:0
But no-one will ever need more than 999 lines in the ini file! 🙂
I can see the code that sets the arbitrary size of the buffer and I can see the code not caring if it goes over. I’ll fix that in the next bug release due hopefully this week or so.