![]() ![]() After file has been shrunk, the Shrink function will optionally look for the start of next record/line, and further reduce size to eliminate partial record. Shrink() - Shrink file by discarding data from beginning of file.zip extension then delete // rollover file // FALSE - do not zip // bGenerateRolloverLogFile - create entry in rollover log file: // TRUE = create entry // FALSE = do not create entry // // Returns: BOOL - TRUE = success // // Rollover() // // Purpose: Rollover file to new file and optionally zip, continue // with empty file // // Parameters: lpszRolloverFileName - name to use for new rollover file // lpszFileNameBuffer - buffer for rollover file name if // not NULL, the rollover file name // will be copied into this buffer // dwFileNameBufferSize - size of lpszFileNameBuffer in TCHARs // if 0, rollover file name will not be // copied into lpszFileNameBuffer // bFailIfExists - operation if file exists: // TRUE = if new file already exists, // the function fails // FALSE = if new file already exists, // the function overwrites the existing // file and succeeds // bZip - operation if Rollover() succeeds: // TRUE = zip rollover file name of // archive will be same as rollover file, // with. ![]() It is easy to disable one or both of these macros, by replacing them with usual So I use the standard TRACE macro for debug messages, and a new TRACEERROR macro for API failures. I decided I wanted diagnostics of two types: a basic informational-type debug message, that reports values and code flow and an error diagnostic for API failures and other serious problems. With the big TRACE problem out of the way, I could now decide how to use TRACE in a consistent manner. I have made some minor changes to Paul's class (such as adding thread ID to the output), and so I renamed it to XTrace.h to prevent any conflicts. Paul's TRACE replacement is not only free of MFC dependency, it also provides file and line number output, is thread-safe, and is completely encapsulated in one header file. Luckily I found an article by Paul Mclachlan, "Getting around the need for a vararg #define just to automatically use _FILE_ and _LINE_ in a TRACE macro". I was very reluctant to do this, because alternative is to put debug output statements in application code, which becomes very messy. I am a big fan of using TRACE statements as a way to monitor actual system operation, but I was afraid I would have to yank all TRACE statements out because I did not want to be tied to MFC. When I started pulling together different pieces of code for CXFile, one of the first things I realized was that I would have to do something about all the TRACE statements that were scattered throughout the code. ![]() I also wanted to make it independent of MFC, because some older systems I work on use only Win32 SDK. My main reason for writing these functions was to make it easier to implement such systems - I wanted consistent interfaces, plenty of diagnostics about what was going on, and extensions that go beyond anything in the Win32 API. Introduction CXFile represents a collection of file-handling code snippets I have put together over a few years working on NT client/server systems. ![]()
0 Comments
Leave a Reply. |