Thursday, April 08, 2004
Sunday, April 04, 2004
Windows Messages
I'm a windows programmer by trade. While working on the batch processor for my photo sharing website, I stumbled upon an interesting feature of windows, Custom Error messages.
If you look at the FormatMessage function, you'll notice it can take an HMODULE to load the message from. But how are these messages created?
The messages are in a special format, compiled by the message compiler (mc.exe)
Each message takes the following form:
For example, the following is a message indicating (for the Event Log) that a service has started:
Most of the specifics are in the MSDN Library.
When you run the compiler on the message, it creates a resource file, a header file, and a binary file, which contains all of your messages. This can be handy for those of you who want to provide users of your library better information.
In the beginning of the this post, I mentioned something about the event log. As it turns out, the event log uses this same mechanism to build it's text information for each of the event entries. Otherwise, it complains, quite verbosely about not being able to read the text for the event ID. More on that later.
If you look at the FormatMessage function, you'll notice it can take an HMODULE to load the message from. But how are these messages created?
The messages are in a special format, compiled by the message compiler (mc.exe)
Each message takes the following form:
MessageId = [ID Number]
Severity = [Severity Code]
Facility = [Facility Name]
SymbolicName = [Identifier]
Language=[Language Name]
[Message Text]
.
For example, the following is a message indicating (for the Event Log) that a service has started:
MessageId = 0x01
Severity = Success
SymbolicName = DPAOL_MSG_SERVICE_STARTED
Language=English
Service Started
.
Most of the specifics are in the MSDN Library.
When you run the compiler on the message, it creates a resource file, a header file, and a binary file, which contains all of your messages. This can be handy for those of you who want to provide users of your library better information.
In the beginning of the this post, I mentioned something about the event log. As it turns out, the event log uses this same mechanism to build it's text information for each of the event entries. Otherwise, it complains, quite verbosely about not being able to read the text for the event ID. More on that later.
Subscribe to:
Posts (Atom)