Using the singlespace environment in an lstnewenvironment, in LaTeX

I was working on a LaTeX document and I had \linespread{1.6} set for double line spacing. But then I added some code snippets to the document with the listings package and I wanted my code to have single line spacing, rather than double line spacing. So, I tried putting them both in a new listings environment to abstract them into a single environment:

\lstnewenvironment{javacode}[2]
{
\begin{singlespace}
\lstset{language=java, label=#1, caption=#2}}
{
\end{singlespace}
}

But upon compiling, I was getting the following 'error':

Overfull \hbox (6.0pt too wide) in paragraph at lines 6--6
[][][][][][][] 
[1]) [2] [3])
*

The Fix

Upon some research, I found the following question which provided a solution to my problem.

The solution to the singlespace environment problem, as suggested by that answer, is to not use the singlespace environment but instead to use \singlespacing instead.

Therefore, this is my final working code:

\lstnewenvironment{javacode}[2]
{
\singlespacing
\lstset{language=java, label=#1, caption=#2}}
{}

Removing the vim error: viminfo: Illegal starting char in line

Last time, I tried opening my gVim and got the following error:

E575: viminfo: Illegal starting char in line: oads/BFSDFSForArticle/BFSDFSForArticle/src/Main.java
E575: viminfo: Illegal starting char in line: ^I"^I24^I0

After some digging around, I realized that this problem is because for some apparent reason, my viminfo file got corrupted.

This viminfo file is mostly used for temporary working data and does not contain any settings, and thus it is safe to delete it. So that's what I intended to do, but finding it was another story.

After I searched my vim installation directory without being able to find this file, I decided to completely uninstall vim and install it from scratch again. But, much to my surprise, the error was still there when I ran vim after the new installation! Which obviously means that the viminfo file was not located in my vim installation directory.

I then ran gVim with the Verbose option, -V. This option instructs vim to tell you everything that its doing, and it is controlled by levels. You can specify the level via -Vn, where n is the level of data that you want to see. By default, if you run -V, the level is 10 (-V10).

For the purposes of actually locating the viminfo file, level 1 is sufficient:

C:\Program Files\Vim\vim72>gvim -V1

This prompted the following message box:

This gave me the information I was looking for. As you can see, the folders I am looking for are $HOME and $VIM. These are environment variables, and to actually see what paths they are mapped to, open vim and run the following commands:

:echo $HOME
:echo $VIM

Those two commands will show you the paths that the variables are mapped to. In my case, $HOME pointed to C:\Users\Andreas and $VIM pointed to C:\Program Files\Vim.

Now since I had uninstalled vim earlier on (thus completely removing C:\Program Files\Vim), the folder I checked for the file was C:\Users\Andreas.

I navigated to the folder and voila, there was the file I was searching for: _viminfo. I deleted that file, and the error was gone.

Disallowing access to files in an ASP.NET website with HttpForbiddenHandler

Disallowing access to files in ASP.NET is a very easy task to accomplish.

In this example, I will disallow access to the file called private.txt that is situated at the root of the website.

When I access this file normally, I get the following:

To disallow access to the file, use the Error Generator Handler HttpForbiddenHandler. This generates a 403 Forbidden error when the user tries to access that file.

To use the handler, simply add it to your <httpHandlers> section in the web.config:

<httpHandlers>
    <add verb="*" path="private.txt" type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

This is what the user will not get when he tries to access the file:

---

The HttpForbiddenHandler can also be used to disallow access to multiple or even folders.

In the following example, I will be disallowing access to all the files that have the .private extension:

<httpHandlers>
    <add verb="*" path="*.private" type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

"Object reference not set to an instance of an object" when using HttpContext.Current.Cache in an ASP.NET Custom Web Server Control

Recently I was developing a custom ASP.NET Web Server Control, and I was making use of the Cache to read data only once, and not after every PostBack.

But when I then tried to view the Control in the Design View of an ASP.NET page, I got the following:

I then traced the problem to the following Property I had in my Control:

public IEnumerable<provider> Providers
{
    get
    {
        if (HttpContext.Current.Cache[ProjectSettings.CacheKey] == null) //This line was throwing the exception
        {
            return null;
        }
        return (IEnumerable<provider>)HttpContext.Current.Cache[ProjectSettings.CacheKey];
    }
}

The Object reference not set to an instance of an object exception was being thrown because I was trying to access a key from the Cache when the Cache was null. This is because when the website is not running, the HttpContext.Current will not be available and thus be set to null.

Fixing the problem

Therefore, to cater for this problem with the Design View rendering, I made use of such a "hack":

public IEnumerable<provider> Providers
{
    get
    {
        /*
         * Begin Hack:  The following [if (HttpContext.Current == null)] is used because 
         *              of the Visual Studio Designer, to supress the 
         *              "Object reference not set to an instance of an object" error
         *              that is displayed in the Design View
         *              - Dreas Grech.
         * */
        if (HttpContext.Current == null)
        {
            return new List<provider>();
        }
        /*
         * End Hack.
         * */

        if (HttpContext.Current.Cache[ProjectSettings.CacheKey] == null)
        {
            return null;
        }
        return (IEnumerable<provider>)HttpContext.Current.Cache[ProjectSettings.CacheKey];
    }
}

As you can see from the above code, I added a condition that checks if the HttpContext.Current is null and if it is, just returns a new List<provider>:

if (HttpContext.Current == null)
{
    return new List<provider>();
}

Removing the default span from a Custom Web Server Control

If you have ever developed a custom Web Server Control for ASP.NET, you may have realized that the Web Server Control automatically encapsulates your control inside a span tag:

This is because the WebControl's constructor sets HtmlTextWriterTag.Span as the default begin tag:

protected WebControl() : this(HtmlTextWriterTag.Span) { 

}

Fixing the issue

To fix this, all you need to do is override the Render method in your Control class , as follows:

protected override void Render(HtmlTextWriter writer)
{
    RenderContents(writer);
}

That way, you will be suppressing the outer span tag from being rendered.

Further Explanation

The following is the implementation of the Render method inside the WebControl class:

protected internal override void Render(HtmlTextWriter writer)
{
    this.RenderBeginTag(writer);
    this.RenderContents(writer);
    this.RenderEndTag(writer);
}

As you can see, it's calling the RenderBeginTag method of the same WebControl class:

public virtual void RenderBeginTag(HtmlTextWriter writer)
{
    this.AddAttributesToRender(writer);
    HtmlTextWriterTag tagKey = this.TagKey;
    if (tagKey != HtmlTextWriterTag.Unknown)
    {
        writer.RenderBeginTag(tagKey);
    }
    else
    {
        writer.RenderBeginTag(this.TagName);
    }
}

The RenderBeginTag is rendering tagKey, which is set in the constructor we saw earlier on:

private HtmlTextWriterTag tagKey;

protected WebControl() : this(HtmlTextWriterTag.Span) { }
public WebControl(HtmlTextWriterTag tag)
{
    this.tagKey = tag;
}

Therefore, by overriding the Render method in our WebControl subclass to only call the RenderContents method, we will be bypassing the following methods that render the span tag: RenderBeginTag and RenderEndTag.

protected override void Render(HtmlTextWriter writer)
{
    RenderContents(writer);

    /* instead of: 

    Render(HtmlTextWriter writer)
    {
        this.RenderBeginTag(writer);
        this.RenderContents(writer);
        this.RenderEndTag(writer);
    }

     */
}