|
That is a work of art!
|
|
|
|
|
Names changed to protect the innocent....
private void FillGrid()
{
}
private void Case_SelectionChanged(object sender, EventArgs e)
{
FillGrid();
}
private void FillCase(string PatientID)
{
case.ItemIndex = 0;
}
protected void Search()
{
FillCase(PatientID);
case.EditValue = caseNo.Trim();
Case_SelectionChanged(new object(), new EventArgs());
FillGrid();
}
So, in 4 lines of code in Search(), we call a lengthy FillGrid function 4 times....Really?
modified 25-Oct-11 12:06pm.
|
|
|
|
|
That example is not complete, is it? All of the functions you show are private/protected, none is public, and only one gets called by a user interaction. The real fun must be somewhere else. Didn't you see a function like:
private void Button1_Click(object sender, EventArgs e)
{
FillCase("");
Search();
Case_SelectionChanged(new object(), new EventArgs());
FillGrid();
FillCase("some value");
Search();
Case_SelectionChanged(new object(), new EventArgs());
FillGrid();
... and some more lines of code
}
|
|
|
|
|
He just wanted to be on the safe side and assured that the grid is filled, no matter what happens
And from the clouds a mighty voice spoke: "Smile and be happy, for it could come worse!"
And I smiled and was happy And it came worse.
|
|
|
|
|
From what I can see the grid won't actually be filled if the FillGrid throws an Exception. Unless there is a deleted try catch block there that recursively calls the FillGrid Method again in its catch block...
It's an OO world.
public class Naerling : Lazy<Person>{}
|
|
|
|
|
Did you got the guy fired, cause of such guys the software can't cope up even with hardware advancements. Even with a quad core machines and GBs of RAM we still have the same performance issues we used to have in the days of Pentium I and a few MB of RAM.
|
|
|
|
|
AsOfDateBlankLabels();
if (this.g_eFormMode != PortfolioDetailFormMode.Portfolio_Edit)
{
c_boolSetDefaultValues = false;
}
c_boolSetDefaultValues = true;
I need say no more.
And before you ask, AsOfDateBlankLabels doesn't use it. At all.
|
|
|
|
|
Where's the problem ? It compiles... :p
/me running
|
|
|
|
|
Did I read it wrong but it looks the the "c_" variable will always be true
|
|
|
|
|
Exactly ; there's no point here to set it to false in the if statement as it is assigned to true just right after.
|
|
|
|
|
Sorry... it is in there for Justin Case
(yes|no|maybe)*
|
|
|
|
|
That's what you get when you pay coders by the line.
Heck, sometimes they'll even throw in documentation!
|
|
|
|
|
Bert Mitton wrote: documentation
What?
|
|
|
|
|
public FileContentResult ExportToExcel(object datasource)
{
var grid = new GridView();
grid.DataSource = datasource;
grid.DataBind();
var sw = new StringWriter();
var htw = new HtmlTextWriter(sw);
grid.RenderControl(htw);
byte[] excelFileBytesContent = this.Response.ContentEncoding.GetBytes(sw.ToString());
var excelFileContentResult = new FileContentResult(excelFileBytesContent, "application/vnd.ms-excel");
return excelFileContentResult;
}
It kinda works, but WTF???
|
|
|
|
|
Excel can load Html tables no problem. There are some CSS issues that arise from it. But it really does work quite well.
And while it doesn't appear that in this case you're going to have any styles being applied, if you did apply formatting to the GridView, they would be reflected in the excel document.
|
|
|
|
|
GibbleCH wrote: Excel can load Html tables no problem.
I agree, but for a business requirement?
|
|
|
|
|
I'm actually using a similar technique in a recent app we have written. However, the HTML passed to excel comes from the browser. This allows us to take the data, render HTML, the user then has the ability to hide/show columns, sort, filter, etc, then export the result to excel.
If I don't pass the HTML to excel (well, a per-processor that cleans it up), then I have to look at it, determine what they are currently showing, query the db all over, then try to create an excel document that mimics the displayed data WITH all the current formatting, which is a duplication of effort since all that work has already been done in rendering the HTML.
It also allows us to just modify the rendering of the HTML, and the export to excel is almost always working automatically without also having to modify the code that generates the excel document.
|
|
|
|
|
It is all good an well till you get to text that looks like numeric data to excel.
Eg: a telephone number with a leading 0. You end up with a number without the leading zero. Or a long number (say ID or SS nr), displays in exponential form.
|
|
|
|
|
Yea.. had the problem with the 0 in the excel part too.
But we used it too, because the calc method had a lot of logic to output HTML, so we reused it for the excel outtput. Worked like a bomb (but the 0 was problematic)
|
|
|
|
|
I generate my cells with classnames, then run the data through a filter, and setup proper mso-number-format styles on the cells prior to sending it to excel. It works well
|
|
|
|
|
Thanks for the tip.
Yea.. that project was done in record time about a year ago. But will keep it in mind!
|
|
|
|
|
That's actually relatively neat. I can't think of a more concise way of getting data into an Excel readable format without using interop or a library like Aspose which costs money (and sticking it on the clipboard and reading it back doesn't count, that has a big nasty side-effect).
|
|
|
|
|
|
Well, using a whole library just for that is kind of overkill, still. That's a really useful looking library, though.
|
|
|
|
|
Here is a lovely one I hand coded earlier. (names changed and many innocuous lines removed to protect the innocent code around it.)
void ReduceCandidates(OblongCollection candidateOblongs)
{
for (int index = 0; index < candidateOblongs.Count; ++index)
{
Oblong fittedOblong = candidateOblongs[index].Reduce();
}
}
This looks like a simple piece of code that nothing can go wrong with.
Unfortunately it occasionally produces an object disposed exception on the line indicated.
OblongCollection and Oblong are both immutable classes with finalizers and implementing the dispose pattern.
What I think must be happening is a new Oblong is created in the OblongCollection indexer, the Oblong then goes out of scope and the Reduce method is called on it. In the Reduce method a method is called on the sole instance variable, but before the method is executed the finalizer kicks into action. This sees that the Oblong is no longer in scope, no instance variables are being used so disposes of the Oblong and calls the finalizer, trashing the object that the Reduce method is calling.
Took me a while to figure out what was happening - I did not want to just blindly change the code. Fixed code below. (Yes, I know a foreach would be better here, if possible, but I want to keep this simple).
void ReduceCandidates(OblongCollection candidateOblongs)
{
for (int index = 0; index < candidateOblongs.Count; ++index)
{
using (Oblong currentCandidate = candidateOblongs[index])
{
Oblong fittedOblong = currentCandidate.Reduce();
}
}
}
Time to throw the Exception ElectrocuteCoder in every finalizer I guess
|
|
|
|