It seems like such a trivial thing to be talking about but not knowing the difference between && vs & or || vs | can make a huge difference between working code and code that only seems to work. Let me illustrate:
It seems like such a trivial thing to be talking about but not knowing the difference between && vs & or || vs | can make a huge difference between working code and code that only seems to work. Let me illustrate:
Over the weekend I got a question about how to prevent postbacks on buttons from within jQuery tabs. But the question really isn’t specific to jQuery. There are other times when you might not want a button to post back. So how do you do this? There are several ways you might accomplish this depending on what your goal is. The first, and most obvious choice, is to not use an ASP:Button control and use an HTML input type=”button” tag instead. This will allow you to have full control over what is happening on the client side. If at all possible, this should be your first choice.
Jeff Atwood of Coding Horror writes:
“I find it difficult to believe, but the reports keep pouring in via Twitter and email: **many candidates who show up for programming job interviews can’t program. At all.**”
One of the things to keep in mind when using jQuery is that nothing is a blocking call. Sure, there is a certain sequence to when things operate. But, to be safe, you should always assume that step two will happen during step one.
Nowhere is this more evident than when retrieving content from a URL and inserting that content in your page.
The temptation is to write code that looks something like this:
There are several controls that allow you to display content based on the role a user is in, including:
And the web.config file allows us to control which pages can be viewed based on which role a user is in.
But what if you need to determine the role a user is in using the APIs? How do you do that?
Since .NET first became available, passing data around during a request has become a lot easier. The ability to set a property has made that so. Still, there are times when setting a property just won’t do the trick.
I’ve had several occasions in the past where I’ve needed to do my own authentication or I’ve needed to add some additional methods to the authentication process.
As easy as Microsoft has made the authentication process, you might think that in order to manually authenticate you’d need to write all of your authentication code manually. But nothing could be farther from the truth.
I recently received a question from another programmer I know who’s been using PHP prior to ASP.NET that made me think harder about a problem we’ve all had in ASP.NET. The basic problem is this:
PDF Tables in iTextSharp work enough like HTML tables that the slight differences between the two make programming tables for a PDF a bit confusing the first time you try.
I hope to describe some of those differences here so that your experience might be a bit smoother than mine was as you start to use tables in your PDF code.
One of the first decisions you’ll need to make as you start working on your iTextSharp table is how many columns the table should have. Keep in mind that the cells can be spanned, just like they can in HTML, so it is better to have too many columns than the bare minimum. You can always adjust later.
Once you’ve decided how many columns, you’ll need to decide how big you want each column to be. Unlike HTML, the columns will not stretch if they are too small.
Here is your initial code:
I was recently asked if I would cover some topics related to Forms Based Authentication. The person who requested this information has some specific issues that he wants covered that I won’t be covering for a while because I think there are some other issues that need to be covered first.
One of those is setting up the database.