Tuesday, August 26, 2008

Turning off ASP.NET LOGIN RETURN URL ability

A standard part of the way that the LOGIN controls work in .NET is that they append the RETURN URL to the query string, and when you successfully log into the application, they drop you back right where you were.

Which makes sense if you're knee deep in an application when you lose your authentication ticket for some reason.

But, what happens when you don't want that behavior. How do you make it where the application always sends you to the default page regardless of where the user had been.

Fun, eh?

Basically, what must occur is that you'll need to handle an event from the LOGIN control, called LOGGEDIN. When handling this event, it then becomes a simple matter of redirecting the user to the default page of the website. What's produced looks like this:

Protected Sub Login1_LoggedIn(ByVal sender As Object, ByVal e As System.EventArgs) Handles Login1.LoggedIn
End Sub

Simplicity in action, once you catch on.

Monday, August 25, 2008

My RDLC covers my footer

Running IE7 I found a fun little issue regarding the RDLC ReportViewer in .NET and my footer as defined in my CSS Layout coming from my Master Page. Basically, the footer was appearing underneath the scroll bar from the iFrames (see the image to the right there).

What confused me at first was the fact that it was happening in IE7 and not IE6. An odd state of affairs at the baset of times.

My guess as to why, is that in IE6, scrollbars are generated INSIDE the element, and they changed that in IE7, but all of us CSS coders are still telling IE to perform according to the IE6 ruleset.

So, to accomplish this little bitty task, what I needed to do was put in another CSS class into the div that wrapped my ReportViewer (and the iFrame which it generates). Since my ReportViewer is running at 400 pixels, I just created the following CSS class and applied it to the DIV that wraps around the viewer:

.viewer { height:425px;}
A small and simple bit of CSS eh?

What that snippet of CSS does is push my footer down just that little bit necessary in order to make sure that it is always displayed (see picture to the left). Also, since it's just a class, then I can apply it only on those pages where necessary rather than on the MasterPage or worse having to create a new MasterPage.

Better yet, due to CSS's ability to stack, I can just append it to an existing DIV rather than having to create a brand new div.

Wednesday, August 13, 2008


I posted yesterday about some travails I was having with RDLC and the behavior of drill through reports. The basics of that was that the system was requiring a second full postback on to process any events generated by a drill through report.

Well, after a bit of sleep, I succeeded in bypassing that whole issue.

To get the necessary behavior, I worked in two steps. The first was in the DRILLTHROUGH event handler, and the second was in the PRERENDER event handler.

So, first things first. Previously, in the DRILLTHROUGH event handler I was getting my data and my parameters, and setting them to the DRILLTHROUGH report. Much the way that every document out there states you're supposed to do. To that, I say BAH!!

My solution required me to not assign the new datasets and parameters to my drillthrough report, but rather to the local report assigned to my ReportViewer class (i.e. the PARENT report).

But, this would make the drill through report devoid of data you claim? Well, that's the whole bit about the PRERENDER class. In there, I check the ReportViewer's LocalReport instance to determine if we're in a DRILLTHROUGH situation, and if so, then I call the PERFORMBACK function of the ReportViewer class.

Which basically pushes us back to the parent report (i.e. the one that I assigned the new datasets to).

Insert an appropriate level of diabolical laughter here, and then we're all sorts of good to go. Now, onto my next problem.

Tuesday, August 12, 2008

RDLC Post Backs

Now, I'm annoyed.

I've never been overly fond of the whole Crystal Reports/MS Reporting control schemes. It's more of the fact that I just don't like reporting than anything inherently wrong with those controls.

Yet, I'm now true and peeved concerning RDLC.

Backstory: I'm building this report, which displays 3 levels of the application's hierarchy at a time, and that bottom level is responsible for doing the drill through effect. Well, going from step 1 to step 2 worked perfectly fine. But stepping from 2 to 3 just cause a postback and redisplaying 2 on the first click. On the second click, the step 3 portion of the report displays correctly. Additional playing about with the EVENT HANDLERS show that this behavior occurs regardless of which event is being fired (though some events still process).

So, now that that huge blurb of backstory is done, I'm still stuck here trying my darnedest to figure out just what is going on.

EDIT: Solving problems since '77.

Thursday, August 7, 2008

First Day of Next Month in VB.Net

This is not exactly that hard of a thing, it's just something that I've found myself doing quite a bit in one of my current projects, and I thought of this nice, easy way to do it which I don't want to lose.

Previously to do this, I'd add a month to the current date, use that date object to get the month as integer, build the new date as a string, and then cast said string to a DateTime object.

That's a lot of steps for what should fundamentally be a simple exercise.

Well, it is; provided you don't do it how I was. Check out this snippet of code:

Now.AddDays((Now.Day - 1) * -1).AddMonths(1)
Beautiful huh? What's happening here is that I'm using the NOW function to return a date, I am then subtracting the current day-1 from that date object. What that works out to is as follows: if today's the 15th, then by plugging into the AddDays function 15-1*-1 I'm literally subtracting 14 days from the 15th, which leaves us with the 1st. Pretty huh?

Once I got to the first of the current month, I then add a month to that date, which will return the first of the next month.

Blog Widget by LinkWithin