vb.net windows app question

[Skiddex]

alright, so i am having a lot of trouble getting this function to work...program always dies on me. i want to auto size the column headers, but cant get my datatable set up correctly, so here it goes. the first method is where i declare and fill the datatable, set it was the source for the datagrid and then call the autosize method. THE AUTOSIZE METHOD WORKS. i found it online and i know its something with how i have named/not named my table.

it always throws ex3 (Dim ex3 As New Exception("Invalid tablename in the DataSet")) when run so i need to figure out how to set up the mapping name corectly.

thanks ahead of time!
-Dan

 

[torpid]

That code is not very good. It's creating exceptions before they are known to be needed which can be a costly operation. I don't understand why you have to pass the mapping name to the function. It can just get the mapping name according to the tablename of the datatable that is attached to the datagrid.

To answer your question, whatever tablename is applied to the datatable in your GetPENF56() function should be the name passed to Autosize instead of "edit". Unless you are overriding it, it most likely is just "" or "Table1" depending on how you are getting the table.

 

[kamper]

Originally posted by: torpid
It's creating exceptions before they are known to be needed which can be a costly operation.

Uh, that's pure bull. A single object creation is not expensive, especially not in light of the complexity of the rest of the method. Throwing exceptions can be expensive, but isn't a problem unless it's done repeatedly but none of that matters because I highly doubt that this method is going to be called all that frequently.

What is wrong with it is that it's very confusing because the exceptions have poor names and are very disjoint with the places they are thrown from. I've never seen that style before.

As for the op, how about supplying a stack trace so we can figure out exactly which line is throwing the ArgumentOutOfRangeException? (That's the other problem with the premature exception declarations: it stops you from attaching the nested exception). I'd also recommend breaking up the code in that try/catch block into a few more lines to make it easier to figure out.

 

[Skiddex]

this line is throwing the exception:

sz = gr.MeasureString(dgData.TableStyles(ts.MappingName).GridColumnStyles(dcCol.Ordi
al).HeaderText, dgData.Font)

the AutoSizeDataGridColumns() method should work, im just looking for how to set up my datatable/grid/style before calling it.

 

[torpid]

Originally posted by: kamper
Uh, that's pure bull. A single object creation is not expensive, especially not in light of the complexity of the rest of the method. Throwing exceptions can be expensive, but isn't a problem unless it's done repeatedly but none of that matters because I highly doubt that this method is going to be called all that frequently.

Maybe he is and maybe he isn't calling it a lot. That's not the point... the code supplied is written with completely unnecessary code that declares an instance of an exception unnecessarily in a style which goes against all recommended patterns of exception handling. If he is calling it repeatedly to resize columns in real time as they change and it is time-sensitive, it could have a small impact.

I'm pretty sure the problem is that it's not able to map the datatable column to the column style specified because the mapping does not match.

 

[Hugenstein]

I know this is a crazy idea, but don't catch exceptions and throw your own exception unless you are going to do something with them.

- handle the exception
- have a good reason to add additional information to the exception (In which case you should wrap the exception in your customexception and preserve the original exception in the InnerException property of your new custom Exception).


Anyway, remove the exception handling around the line that is causing the error. And then you can see what the actual error is and then maybe we can help you.

 

[kamper]

Originally posted by: torpid
the code supplied is written with completely unnecessary code that declares an instance of an exception unnecessarily in a style which goes against all recommended patterns of exception handling. If he is calling it repeatedly to resize columns in real time as they change and it is time-sensitive, it could have a small impact.

I'm not in any way arguing that the style is good. It's terrible. But claiming it as a performance problem is plain silly. Please, bust out a profiler and demonstrate to me that those 3 lines take anywher near as much as 1% of the run time of the method for any reasonably sized grid (say, 4 columns, 50 rows).

 

[beggerking]

the GetPenf56() function, does it return a datatable type ? if it doesn't, then it should..

 

[Skiddex]

figured it out,

g_dbEditDT = objDB.GetPENF56()

datCurrSuppressions.DataSource = g_dbEditDT

Dim ts As DataGridTableStyle = New DataGridTableStyle
ts.MappingName = g_dbEditDT.TableName
datCurrSuppressions.TableStyles.Clear()
datCurrSuppressions.TableStyles.Add(ts)

like i said, i wasnt concerned about the ausosize function, just about how to setup the tablestyle. i ended up not using that function and just wrote my own, cleaner and nicer autosize code

 

[torpid]

Originally posted by: kamper

Originally posted by: torpid
the code supplied is written with completely unnecessary code that declares an instance of an exception unnecessarily in a style which goes against all recommended patterns of exception handling. If he is calling it repeatedly to resize columns in real time as they change and it is time-sensitive, it could have a small impact.

I'm not in any way arguing that the style is good. It's terrible. But claiming it as a performance problem is plain silly. Please, bust out a profiler and demonstrate to me that those 3 lines take anywher near as much as 1% of the run time of the method for any reasonably sized grid (say, 4 columns, 50 rows).

It won't unless you run it ten million times probably or have an extremely time-sensitive app, that's why I said it CAN be costly, not that it is. I dunno about you, but I don't go around throwing pointless code in my apps that reduces performance even by 0.0001%.

 

[kamper]

Originally posted by: torpid
It won't unless you run it ten million times probably or have an extremely time-sensitive app, that's why I said it CAN be costly, not that it is.

No, it won't ever. Look at the method. It does a loop that will run in O(n) where n is the number of columns*rows. Inside that loop is the MeasureString method which I bet will take far longer than the creation of a single exception. Add to that a few string comparisons, column lookups and grid rearrangements (and who knows how extensive those are). For my example of a 4*50 grid, the loop itself will run several hundred times longer than the exception creation at minimum.

Just as a counter example (and this is dangerous because microbenchmarking is a very bad idea), I whipped up a loop that continually created exceptions. I put a static counter increment in the exception constructor to make sure the operation didn't get optimized away and called base(string) to make it equivalent to the provided example. The average over 1million iterations was consistenly less than a 10th of a millisecond per construction. I don't think that qualifies as expensive by any means.

I dunno about you, but I don't go around throwing pointless code in my apps that reduces performance even by 0.0001%.

I dunno about you, but I don't go around throwing pointless optimizations in my apps. Thinking that way will almost always lead to worse code that isn't faster and keeps you from seeing the real problems. Seriously, use a profiler some time. Big improvements invariably come from a reduction in algorithmic complexity, not silly things like object construction outside of a significanly larger loop.

 

[torpid]

When is the stack trace analyzed? I assume that is a costly operation in some scenarios, although I do not seem to see any evidence that stacktrace / stack frames are costly now that I look.

Anyway, it's not a pointless optimization, as it is also good style. Creating instances of objects that you will only use if there is a problem is stupid.

 

[kamper]

Originally posted by: torpid
When is the stack trace analyzed? I assume that is a costly operation in some scenarios, although I do not seem to see any evidence that stacktrace / stack frames are costly now that I look.

Stacktraces obviously are not analyzed until after an exception is thrown and caught (otherwise there isn't a stack trace). As I mentioned before, throwing and catching exceptions is indeed an expensive operation because the call stack has to be unwound manually but there is no throwing going on here, it's just simple, cheap object creation.

Anyway, it's not a pointless optimization, as it is also good style. Creating instances of objects that you will only use if there is a problem is stupid.

Of course the style was stupid, as I have agreed with all along. But if it were actually faster to predeclare the exceptions (or imagine some other scenario where an insignificant optimization requires bad style) style is the better choice every single time.

 

[torpid]

Originally posted by: kamper

Anyway, it's not a pointless optimization, as it is also good style. Creating instances of objects that you will only use if there is a problem is stupid.

Of course the style was stupid, as I have agreed with all along. But if it were actually faster to predeclare the exceptions (or imagine some other scenario where an insignificant optimization requires bad style) style is the better choice every single time.

Well on this point we can agree. But on the point of... instantiating objects if they might not be used, which may developers consider good "style" because they think things at the top are good, I stand firm.

 

[beggerking]

You are both correct. That operation was expensive, but with today's CPU, its not expensive anymore..

 

[kamper]

Originally posted by: beggerking
You are both correct. That operation was expensive, but with today's CPU, its not expensive anymore..

Alright, I might be pushing this too far P) but I still don't understand why people think this is expensive. Admittedly, I don't know how much .net Exceptions do in their constructors, but they're not very complex objects so I doubt it's much. The memory allocation isn't a big deal because modern garbage collecting runtimes have extremely efficient allocation algorithms.

 

[beggerking]

Agreed. :thumbsup: