Adding Alerts to the EZLogger Task List

Overview

In this article, I explain the design and implementation of the alert system within EZLogger. The goal of this feature is to automatically detect county or patient-specific alerts associated with a forensic report and add them to the user's Task List (Tasks.xml) when the user presses Btn_L.

Purpose of the Alert System

I created the alert system to ensure that important notifications about a report are not only displayed during initial review (Btn_B), but also logged into the task list for ongoing follow-up. Instead of the user needing to manually remember alerts, they are now persisted inside EZLogger's Task List.

How the System Works

When the user presses Btn_L in the ReportWizardPanel, it triggers the ShowBtnLMessage method inside ReportWizardHandler.vb. This method, after validating that an active document exists, calls AlertHelper.AddAlertsToTaskList(doc). This is where the main work happens.

Reading Key Fields from the Document

Inside AddAlertsToTaskList, I pull two pieces of information from the active Word document:

• Patient Number
• County

Instead of manually accessing document properties (which is fragile in Word COM interop), I use my central helper method DocumentPropertyHelper.GetPropertyValue(). This makes the access consistent and prevents invalid casting exceptions.

Loading Alert Definitions

Once I have the patient number and county from the document, I load the global alert definitions by calling two helper methods:

• ConfigHelper.GetPatientAlerts(globalConfigPath)
• ConfigHelper.GetCountyAlerts(globalConfigPath)

These helpers read the global_config.json file, locate the "Alerts" and "county_alerts" sections, and return them as dictionaries.

I purposely chose to call these helpers separately instead of trying to optimize for speed by manually parsing JSON inside AlertHelper. I wanted the system to remain clean, reliable, and easy to maintain.

Adding Alerts to the Task List

If a patient-specific or county-specific alert is found matching the report, I format the alert text by replacing any internal line breaks (vbCrLf) with semicolons (; ) to keep the Task List entries readable.

Each alert is added as a separate task by calling TaskListHandler.AddTaskFromReport(). I decided this approach was better than lumping all alerts into one giant task, because it makes the follow-up process more manageable for the user.

The TaskListHandler automatically saves the updated list back to Tasks.xml so that the alerts persist between sessions.

Why I Made Certain Design Choices

• Using DocumentPropertyHelper: I had seen that direct access to Word's CustomDocumentProperties can throw uncatchable exceptions, so I standardized on safe property reads.
• Calling ConfigHelper methods: I wanted a clear separation of responsibilities: ConfigHelper deals with loading JSON, and AlertHelper simply asks for what it needs.
• Separate tasks per alert: I decided to create individual tasks for each alert to give users fine-grained control over their workflow.
• No premature optimization: Even though it might seem faster to manually parse the JSON once, I kept the existing helper structure for clarity and maintainability.

Conclusion

The alert system integration into the EZLogger Task List works reliably across SharePoint, network, and local documents. By building on top of my existing ConfigHelper and DocumentPropertyHelper modules, I kept the architecture clean and professional.

This was a critical feature to ensure that important case information is not lost during the processing and follow-up stages.