Is it common practice to sublass all the windows controls

  • Thread starter Thread starter Phillip
  • Start date Start date
P

Phillip

In order to maintain consistency thru a project.

Our development team is getting ready to start a new project in converting
all the foxpro apps to VB/SQL Server. We don't have the luxury of training
so hopefully our F1 training won't cause us any major problems or future
headaches.

Are there any guides out there that might have the basic fundementals of a
windows application.

Is a startup main the best way to begin, default error handling, how to
handle daily updates...

I hope I am not to confusing.

I have already wrote one dot net app in framwork 1.0 to scrub edi data and
then rewrote it one 1.1 came out but it just doesn't seem right.

Calling a stored procedure randomly times out. When it doesn't, it takes
about 20 seconds. There isn't much data and it is a dual proc server. So
perhaps my code or how i call the procedure is'nt "By the textbook".

Thanks,
Phillip
 
It is not common to subclass all the windows controls. You do this when you
want to add a feature to the control itself that isn't natively available,
or add a behaviour to all controls of a particular type without having to
code for each instance separately.

Rest is inline...

Phillip said:
In order to maintain consistency thru a project.

Our development team is getting ready to start a new project in converting
all the foxpro apps to VB/SQL Server. We don't have the luxury of training
so hopefully our F1 training won't cause us any major problems or future
headaches.

Are there any guides out there that might have the basic fundementals of a
windows application.

Is a startup main the best way to begin, default error handling, how to
handle daily updates...
Click to expand...

I find that setting startup to Main is best. It allows you the luxury of
running code before any form is instantiated.

Error handling is best done on a local level. Each function should "expect"
that certain possible errors will happen based on methods that it calls.
Unexpected errors can then be handled either generically, or bubbled up to
an application-level (global) exception handler. There are a number of
articles on the web and on MSDN with regards to different approaches on
exception handling. While there are certain best-practices concepts in
dealing with exceptions, no one can honestly say there is one "best" way of
handling exceptions. Here's one place to start:
http://msdn.microsoft.com/library/en-us/dnbda/html/exceptdotnet.asp?frame=true

Updates to application components depend on what type of application you are
writing and how it is distributed. If it's an app that lives on one (or a
small number of) server(s), simply copying updated private assembly files
will suffice. However, if it is installed to many user stations, you might
want to consider something like the Microsoft Updater Application Block
(search for that phrase in MSDN).
I hope I am not to confusing.

I have already wrote one dot net app in framwork 1.0 to scrub edi data and
then rewrote it one 1.1 came out but it just doesn't seem right.

Calling a stored procedure randomly times out. When it doesn't, it takes
about 20 seconds. There isn't much data and it is a dual proc server. So
perhaps my code or how i call the procedure is'nt "By the textbook".
Click to expand...

There is a possibility the SQL statements might be inefficient - for
example, you might be using SQL statements that lock a table rather than a
row, or select data from the same table without using a NOLOCK hint. You'll
have to address that outside the context of .NET, as it pertains to database
syntax.

However, it's also possible you're running into issues of having improperly
handled database connections (for example, ones that aren't closed out
properly). Try using the Microsoft Data Access Application Block. I'm not a
huge fan of this application block, because you can definitely write far
more efficient code than some of its methods, but it does deal properly with
database resource managment. It can also serve as a good guide to dealing
with ADO.NET objects.

-Rob Teixeira [MVP]
 
I agree with Rob - do not subclass them if your not going to add extra functionality

Can you post your code for calling your store procedure?

Cheers,
Rickard
 
Back
Top