In the last weeks, there was a lot of refactoring under the hood.
In the past, we used a special docking engine, while all other UI controls came from DevExpress. We now switched to the docking engine of DevExpress which gives us the opportunity to offer more than 30 different and very stylish skins for Log4View.
For example, what do you think about Summer 2008?
I like this one a lot, perhaps because after a long and cold winter, spring is now coming to southern germany.
But of course, there are also more serious skins available.
Of course, we also did a lot of bug fixing. You can find a list of all changes in the Release Notes.
As soon as the TCP receiver is configured and started, it tries to connect to the configured TCP appender. Theses connection attempts are repeated every second until the connection is established.
But what happens, if Log4View is already running before the logging application is started. Depending on when the last connection attempt was made, there is a delay of up to 1000 ms until Log4View successfully connects to the newly started application.
Are the messages lost, which had been sent before the connection was made?
The TCP appender is using an internal buffer, which stores the messages of the last 5 seconds and sends them prior to any new messages as soon as a new connection is made. This makes sure, that you don’t lose messages when Log4View is running before you start your logging application. If you start Log4View afterwards, you get at least the last 5 seconds before you started Log4View.
BTW: You also don’t have to worry about long periods where the logging application doesn’t send log messages. The TCP appender sends a short dummy message, if no log messages were sent in the last second. This makes sure, that the TCP connection stays open as long as the logging application and Log4View is running.
After having published Log4View 2010.2, some users told me, that they had difficulties with the UDP appender.
As a matter of fact, the new field “Hostname”, which we added to the UDP receiver form, can only accept IP addresses (e.g. “127.0.0.2”). There is no DNS resolution for the host name in the UDP receiver.
Even worse, the host name is empty by default, which makes the UDP receiver fail. So please make sure, that you provide a valid IP address.
We will fix this in the next release.