Open Office Macro Horizontal Odd-Even Row Compare

 Sub HorizonatalCompareOddEvenRows()  
   vSelection = ThisComponent.CurrentSelection  
   oSelect=ThisComponent.CurrentSelection.getRangeAddress  
   oSelectColumn=ThisComponent.CurrentSelection.Columns  
   oSelectRow=ThisComponent.CurrentSelection.Rows  
   CountColumn=oSelectColumn.getCount  
   CountRow=oSelectRow.getCount  
  oSelectSC=oSelectColumn.getByIndex(0).getName  
   oSelectEC=oSelectColumn.getByIndex(CountColumn-1).getName  
   oSelectSR=oSelect.StartRow+1  
   oSelectER=oSelect.EndRow+1  
   NoCell=(CountColumn*CountRow)  
   If CountColumn=1 AND CountRow=1 Then  
    MsgBox("Cell " + oSelectSC + oSelectSR + chr(13) + "Cell No = " + NoCell,, "SelectedCells")  
   Else  
    MsgBox("Range(" + oSelectSC + oSelectSR + ":" + oSelectEC + oSelectER + ")" + chr(13) + "Cell No = " + NoCell,, "SelectedCells")   
   End If  
   colorArray = Array(RGB(255,141,6), RGB(255,141,36), RGB(255,141,66), RGB(255,141,96), RGB(255,141,126))  
   colorAraySize = UBound(colorArray)  
 For colIndex = 0 To CountColumn-1  
   For rowIndex = 0 To CountRow-2  
           If (rowIndex mod 2) = 0 Then  
               vSel = vSelection.GetCellbyPosition(colIndex,rowIndex)  
               vNext = vSelection.GetCellbyPosition(colIndex,rowIndex+1)  
               s = vSel.getString()  
               s2 = vNext.getString()  
                 If Len(s) > 0 AND Len(s2) > 0 Then  
                   'Print s, s2, "(",colIndex,",",rowIndex,")","(",colIndex,",",(rowIndex+1),") Comp result",StrComp( s, s2)  
                   If StrComp(s, s2) <> 0 Then  
                    index = rowIndex mod colorAraySize  
                    vNext.CellBackColor = colorArray(index)  
                   Else  
                    'vSel.CellBackColor = RGB(255,255,255)  
                   End If  
                 Else  
                   'Print "Nothing is selected"  
                 End If  
           End If    
   Next  
 Next  
 End Sub  

Application logging guide lines - 2

Ref: http://www.bugfree.dk/blog/2009/07/22/basic-logging-guidelines/

Basic logging guidelines

Next to unit testing I believe in logging to improve the quality of an application. Instrumenting code with logging (or tracing for that matter) should be an integral part of writing production code. Yet, I’ve often found it not to be the case or that what got logged only made sense to the developer who wrote the entry.
Not logging implies that debugging the application outside the development environment is largely based on guesswork. That’s interesting given that most applications spend the majority of their life running outside the development environment.

Life in the sandbox

I suspect the absence or low quality of log statements can be, at least partially, explained by developers not finding them useful during development. The debugger available there is generally inferior to the print-lining approach of logging. That said, I’d argue that many developers don’t concern themselves enough with how their code behaves in a production environment. Rather than investing a small amount of time in adding log statements up-front, their focus is solely on satisfying functional customer requirements.
A related case could be made for exception handling. For instance, rather than asserting the validity of an argument up-front and throwing an appropriate exception, the code may later fail with a NullReferenceException. Not throwing the exception up-front, close to where the actual error occurred, one will have a hard time tracking down the issue. Especially since a stack trace with symbols and line numbers is rarely available in a production environment.
For someone having to resolve the issue, almost any clue as to the cause would be most welcomed. Without a clue that someone would walk around in the dark in the hope of stumbling into a solution.

End users aren’t the only users

As software developers we have to acknowledge that end users aren’t the only users of our software. System administrators, developers, and the like should also be factored in during development. Especially since the cost of instrumenting code at key places, early on, doesn’t add significantly to the overall development cost. Focusing on what can go wrong and communicating it well saves time, money, and frustration down the line. And as a bonus you might create better self-documenting code.
That said it’s important to strike a balance between logging too little and too much information. A log should be detailed enough to reveal patterns of use. Ideally, the log should read like a story with short sentences detailing what’s about to happen, what did or didn’t happen, and possibly why.
I’m not suggesting that we turn logging into a runtime version of literate programming. But simply that sufficient contextual information be provided, i.e., instead of logging “URL = ‘bugfree.dk’”, consider the more elaborate “Retrieving URL for indexing: ‘http://bugfree.dk’”.

Keep your statements clean

On the other hand, log statements shouldn’t be immune to the DRY principle. So make sure to have the logging framework automatically capture common bits of contextual information, such as the date and time of the entry and the class and method within which the log statement originated. On a similar note, don’t explicitly log when a method is entered or existed. Instead, treat such a case as a cross-cutting concern and take an Aspect Oriented approach to logging it.
Lastly, not every method requires (extensive) logging. Figuring out when and what to log is key. Debugging the application, fixing bugs, and experience should provide guidance into what’s useful to log.

Application logging guide lines

Ref: http://watchitlater.com/blog/2009/12/logging-guidelines/

Logging Guidelines

Logging – this is something we as developers do very badly – perhaps we need to ban the debugger. Unless you’ve worked in first-line support or in OPS, the only time you ever look at a log file is as a last resort. This is unfortunate, since the last resort may occur when you are trying to figure out why someone has lost money or when your company is about to be sued by a client (usually for losing their money, video, kids photo, etc). I’ve decided to compile a short guide about logging to both stimulate my thinking, and to jot down some notes for the next time I stand in front of a whiteboard and rant about logging in a production system. Not all of this is my own thinking and I am grateful to John Dickson for first sparking the idea that logging matters.
Why do we log?

• Audit trail & application status
• Automatic monitoring for errors and warnings
• Helping track down configuration problems
• Helping track down bugs

What logging level should be used?
FATAL
This should generally only be used for recording a failure that prevents the system starting, i.e. the system is completely unusable. It is also possible that errors during operation will also render the system unusable, but typically these will be identified as java.lang.Error instances (such as an OutOfMemoryError), and hence we will not likely catch them, since catching Throwable should only be done in very special cases.
ERROR
Records that something went wrong, i.e. some sort of failure occurred, and either:

1. The system was not able to recover from the error, or
2. The system was able to recover, but at the expense of losing some information or failing to honour a request.

This should be immediately brought to the attention of an operator. Or to rephrase it, if your error does not need immediate investigation by an operator, then it isn’t an error.
To permit monitoring tools to watch the log files for ERRORs and WARNings is crucial that:

• These get logged
• Sufficient information is provided to identify the cause of the problem
• The logging is done in a standard way, which lends itself to automatic monitoring.

For example, if the error is caused by a configuration failure, the configuration filename should be provided (especially if you have more than one file, yuck), as well as the property causing the problem.
WARN
A WARN message records that something in the system was not as expected. It is not an error, i.e. it is not preventing correct operation of the system or any part of it, but it is still an indicator that something is wrong with the system that the operator should be aware of, and may wish to investigate. This level may be used for errors in user-supplied information.
INFO
INFO priority messages are intended to show what’s going on in the system, at a broad-brush level. INFO messages do not indicate that something’s amiss (use WARN or ERROR for that), and the system should be able to run at full speed in production with INFO level logging.
The following types of message are probably appropriate at INFO level:

• successfully initialised
• transaction started, member: , amount:
• transaction completed, txNo: , member: , amount: , result:

Using Log4J’s MDC or NDC should provide a mechanism to avoid repetition of contextual information when creating log files, allowing the log file entries to have a standard format (see the DEBUG section below).
DEBUG
DEBUG messages are intended to help isolate a problem in a running system, by showing the code that is executed, and the context information used during that execution. In many cases, it is that context information that is most important, so you should take pains to make the context as useful as possible. For example, the message ‘doTransaction() started’ says nothing about which merchant the transaction is for, the type of transaction, the amount, or anything else that might help us to relate this to a transaction that failed.
Using Log4J’s mapped diagnostic context (MDC) or nested diagnostic context (NDC) there is a common mechanism provided for thread-based (effectively request-based) context (things like session IDs, transaction IDs etc.), so if some of the context in your message should be common to all log messages for this request, set it in the context (and make sure your PatternLayout can display it).
In normal operation, a production system would not be expected to run at DEBUG level. However, if there is an occasional problem being experienced, DEBUG logging may be enabled for an extended period, so it’s important that the overhead of this is not too high (up to 25% is perhaps OK).
The following types of message are probably appropriate at DEBUG level:

• Entering ., : , [: …]
• Method . completed [, returning: ]
• .:
• .:

Please note that DEBUG messages are intended to used for debugging in production systems, so must be written for public consumption. In particular, please avoid any messages in a non-standard format, e.g.
DEBUG ++++++++++++ This is here cause company “Blah” sucks +++++++++++
If a DEBUG message is very expensive to generate, you can guard it with a logger.isDebugEnabled() if check. Just make sure that nothing that happens inside that if block is required for normal system operation. Only sendmail should require debug logging to work :).
When to log an Exception?
Ideally, an exception should only be logged by the code that handles the exception. Code that merely translates the exception should do no logging. With nested exceptions available on Java 5+, no context should be lost when an exception is translated.
‘Enterprise’ Logging
Some OPS environments use automatic monitoring tools that will display to an operator a screen containing error details parsed from the log file and suggested information for dealing with the error. In order to do this such systems usually require prior knowledge of all possible error conditions and a way to map them to suggestions. It is common in such systems to have specific error codes for certain conditions (e.g. host unavailable is error 1024). Error codes also provide a way to avoid needing to internationalise error messages for various locales while still providing ‘enough’ detail to get someone started.

Who is going to Born (Boy or Girl)

I don't know whether this can trust or not.