Details
-
Improvement
-
Resolution: Fixed
-
Major
-
None
Description
The aim of this report is to track the different improvements to the Event Log Viewer.
Part 0: previous commits
=====
- Convert the application to UNICODE (and other minor fixes): r71367 (hbelusca).
- Correctly display event binary data: r71368 (hbelusca) and r71374 (ekohl).
Other commits by myself:
- Use RichEdit box to display event text (in order to support tabs, hyperlinks, etc...); use Courier New monospaced for displaying event binary data: r71376.
- Minor UI fixes: r71377, r71678.
- Minor code fixes: r71378, r71669. Fixes to event details display: r71670, r71671.
- Change of the UI design: add a treeview on the left to list the available event logs; the events are displayed in the listview on the right. A splitter bar allows resizing the treeview and the listview. About-box is now standardized: r71836. Icon changes: r71829, r71850 (thanks Pi_User5!) and r71944.
- Minor UI post-fixes: r71852.
- Allow the user to list the events from the newest to the oldest, or vice-versa: r71851
- Further UI fixes & code cleanup: r71867.
Part 1: r71958
=====
- Perform the events enumeration in a separate thread, in order to keep the UI responsive during the operation. Also add a "command" thread, whose aim is to signal the enumeration thread for termination & wait for it, start a new enumeration thread. This is needed because, if those operations are done instead in the main app (the UI) thread (more precisely inside the main window procedure' WM_COMMAND handler), we would get deadlocks since the enumeration thread also sends UI messages to the main window procedure. Finally this allows serializing access to the global event data cache.
- Maintain the opened event logs in a linked list, this allows dynamic addition and deletion of logs (useful when the user wants to open custom event logs...)
- Add the concept of event log filters. Their power is not completely unleashed in this revision, but the base code is layed out there. They can filter either one or many event logs (currently only one log). Helpers are introduced to handle them.
- Add helpers for using FormatMessage correctly.
- Allow displaying event log properties (dialog box adapted from Pi_User5's one). The file attributes display code is adapted from shell32' one.
- Implement parameter strings insertions in event descriptions. The code is partly based on an MSDN example: Querying for Event Information.
- Display some status strings in the events listview, when it is empty and when events are being loaded. This is WIP. Implemented by subclassing the listview.
- When displaying event binary data in "word" mode, display separately the remaining bytes in case the data length is not a multiple of sizeof(DWORD).
- Update russian translation, by Olim98, see
CORE-11636.
Part 1b: small bug fixes; r71989
======
- Use helper functions for doing the filtering on the events (idea by learn_more).
- Fix the states of menu items, depending on which event log/item (log file/filter; event item...) is currently selected.
- Correctly empty the event items list & cache whenever an event log/filter is closed (and avoid a crash when all logs/filters are closed and someone attempts to open an event item), during concurrent accesses. I use a reference count and AddRef/Release helpers.
- Get rid of the annoying log loading popup, and use instead the loading message displayed in the events listview as well as a progress-bar in the status bar.
All those previous fixes/improvements are included in ReactOS 0.4.2 .
Part 2a: r72079
======
- Transform the event details dialog into a control that can be embedded:
- in a resizable dialog,
- or in a pane below the window listing the events.
Part 2b: r73043
======
- Fix FormatMessage flags sanitization.
- Use "LANG_USER_DEFAULT" instead of MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT) (these are the same, but one is shorter than the other).
- In case LookupAccountSidW fails to retrieve the user name of an associated SID, use ConvertSidToStringSidW to get the SID string directly and display it, instead of claiming there is no associated user for a given event.
- In addition to display (in the status bar) the number of events in the selected log, display the number of events actually listed. This can be useful when events filtering will be completely implemented, and it can be also useful for detecting possible corrupted logs where the number of enumerable events is different (less) than the total number of events in the log...
Part 2: See CORE-12269
Now I'm using subtasks.
Attachments
Issue Links
- relates to
-
CORE-11636 Update for Russian translation
- Resolved
There are no Sub-Tasks for this issue.