Autocomplete/intellisence in a multiline edit box - C# Discussion Boards

How to extract the sql query from a report

20-Apr-05 5:56

Easy - ListView1.Items(Index).EnsureVisible(); or myListViewItem.EnsureVisible();

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Ana-Gabriela Clem20-Apr-05 1:52

Ana-Gabriela Clem

20-Apr-05 1:52

Please help me,I want to extract the sql query from a report in C# and after I modify the sql, the report change after the new sql.
Thanks.

local method variable or global class ?

CiNN20-Apr-05 1:25

CiNN

20-Apr-05 1:25

i was wondering if it's best to use a global variable or a local one which is each time allocated?

for exemple in a paint event
i would think it's better to create the brush and graphics handle before (eg in constructor)

but in exemple code i've seen them in the paint method so they are allocated each time a paint is occured...

Enishi20-Apr-05 1:37

Enishi

20-Apr-05 1:37

depends when and how much are u gonna use them.
If the brushes are only used in the paint event , just create them there and when u finish the paint just free them , that way ull gain more resources.
A local variable is only of use to those in the same method as she is.

A global variable will be usable by all the class, if u would use the brushes in 3 or 4 methods just create it global so ull create once.Normally gobal variables are used to control methods or handles like threads and such.

if u create the brushes global ull be using the memory al the time cause ull carry them along the class, if u create them local then ull create them and freeing the memory after u used them.

Usually the few global variables u use the better structured is the class.

CiNN20-Apr-05 2:02

CiNN

20-Apr-05 2:02

i just thought that because of GC it would be bad to allocate each time

S. Senthil Kumar20-Apr-05 2:09

20-Apr-05 2:09

It would be more efficient to allocate in the constructor. You are anyway going to use it everytime a paint occurs, you might as well cache it. And because Brush and Graphics handles will have unmanaged resources, it would be more efficient to get them once and hold on to them rather than acquiring and releasing them every time.

That said, the .NET GC is very good at cleaning up objects that are destroyed soon after creation, so you might want to measure it up using a profiler.

Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro

Sebastian Schneider20-Apr-05 3:50

Sebastian Schneider

20-Apr-05 3:50

It think this might not be entirely accurate.

Caching the Graphics-handle might get you into serious trouble, as the Paint-Event is triggered very often without giving you the slightest hint WHY it occurred.

Lets say you have a window which was just resized. You still have the Graphics handle and start drawing. Everything will look ok at first glance, but you will soon notice that everything outside your original "drawing pane" is not being drawn. Lines end, circles appear as arcs ... and you have no clue what is going wrong.

Its quite simple: You are still holding onto an outdated Graphics-Object.

You should only draw when told by WM, anyway, so in OnPaint you imho SHOULD assume that major changes might just have occured. This means: Reassign the graphics object and redraw the invalidated rectangle (or the whole shebang, if you need to).

Cheers
Sid

S. Senthil Kumar20-Apr-05 4:33

20-Apr-05 4:33

I wasn't talking about the Graphics object passed to Paint(), I know it is not supposed to be cached and reused. I was talking about other Drawing related objects like Brushes.
[EDIT]My bad, it looks like I did say that for Graphics too, I didn't realise he was talking about the Graphics object specifically [/EDIT]
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro

Dave Kreskowiak20-Apr-05 5:52

20-Apr-05 5:52

Yeah, I wouldn't recommend holding onto any unmanaged handles for longer than the current paint event. Since there are limits to the number of handles (of any type) that can be checked out system-wide, its considered good practice to not hold onto them for any longer than you absolutely need to.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

S. Senthil Kumar20-Apr-05 6:04

20-Apr-05 6:04

But wouldn't the cost of acquiring the unmanaged resource (most probably through transitioning to unmanaged code) and releasing it warrant caching? And we are just caching a few handles, do you think that would make the system run out of handles?

Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro

Dave Kreskowiak20-Apr-05 14:25

20-Apr-05 14:25

The cost of allocating those resources is negligable. You're not gaining that much of a perfomance benefit by caching it. Also, if you cache the handle, then change the screen resolution or color depth, the handle is no longer valid for drawing.

No, just caching a few handles will not run the system out of resources. But it requires you to keep track of them for the duration of the application session. Just about everything in Windows has a handle attached to it, some even use thousands at a time. The performance benefit is just not worth the extra overhead of caching them.

Allocate it, use it, free it... Would you open a database connection and hang onto it for the duration of your app?

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

S. Senthil Kumar20-Apr-05 19:07

20-Apr-05 19:07

I actually would. Prior to ADO.NET, we used to maintain our own database connection pool and the application ran significantly faster. Same concept as thread pools. But yeah, I do agree with your point though, it might not be worth caching those objects.

Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro

Dave Kreskowiak21-Apr-05 2:19

21-Apr-05 2:19

Even though it's expensive to open a database connection, it's considered extremely poor practice to open a connection and hang onto it for the duration of the app. Since SQL Server connection licenses are ($)expensive, and there are a limited number of them compared to the number of users using the system, it's always good form to create the connection and hold it open only for as long as absolutely necessary.

Remember, the number of SQL connections available are not specific to one application or database, they're available for the entire server! So, depending on the situation, it's entirely possible to support 10,000 users on 500 licensed connections, using many different database applications. Think about it...How many user would be using the system at any one time? How many of them are going to be accessing the databases at exactly the same time? What kind of money would your customer like to spend? It's always as little as possible, correct? So why would your customer spend the money on 10,000 licenses when only about 1,000 of them, max, are going to be using the system at any one time?

Starting to see how "Grab it, use it, release it" is considered "best practice"?

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

S. Senthil Kumar21-Apr-05 4:59