Application Suggestions for a eVB programmer

  • Thread starter Thread starter Srinivas R. Loka
  • Start date Start date
S

Srinivas R. Loka

I am a Powerbuilder programmer(hence very familiar with OOP). Thanks to
Chris Tacke's book and this newsgroup, I wrote a complex eVB app that now
needs to be ported to C# (No, not VB.Net ).

I need some suggestions regarding the suggested or common practice for .Net
Windows App programming. I already realized that the programming style has
to change(I cannot refer to open forms and its controls and properties like
I am used to). I am getting this book "The .NET languages : a quick
translation guide by Bisch" - might help.
Please bear with me as I am new to this style of programming (e.g. waiting
on a form to close in Main function).
Some questions that arise are

1) Should I have a GLOBAL connection object, just like I used to in eVB ?
2) Now I can actually close(read unload) forms - right ? Please say yes.
3) What are the main memory intensive objects I should be careful with (not
to overuse)
4) Is it ok or normal to have global variables of each form and to set them
in the constructor of that form so that they can be used to manipulate
objects(explicitly will convert these to public) within a form ? Or is there
any recommended or accepted OO approach.

More to come as I keep exploring this ocean of .Net

Any kind of suggestions, hints and links are appreciated.

Thank You
 
Inline....
Srinivas R. Loka said:
I am a Powerbuilder programmer(hence very familiar with OOP). Thanks to
Chris Tacke's book and this newsgroup, I wrote a complex eVB app that now
needs to be ported to C# (No, not VB.Net ).
Click to expand...

Why not VB.NET? You're already familiar with VB syntax, why learn 2 things
at once?
1) Should I have a GLOBAL connection object, just like I used to in eVB ?
Click to expand...

No. Create and use it on an as-needed basis.
2) Now I can actually close(read unload) forms - right ? Please say yes.
Absolutely.

3) What are the main memory intensive objects I should be careful with (not
to overuse)
Click to expand...

Anything the exposes a Dispose() method is probably resource intensive -
graphics stuff especially. Don't worry about overuse, just make sure you
clean up after yourself.
4) Is it ok or normal to have global variables of each form and to set them
in the constructor of that form so that they can be used to manipulate
objects(explicitly will convert these to public) within a form ? Or is there
any recommended or accepted OO approach.
Click to expand...

It's more appropriate to have a private variable accessible through a
property.
Any kind of suggestions, hints and links are appreciated.
Click to expand...

www.OpenNETCF.org

-Chris
 
"Why not VB.NET? You're already familiar with VB syntax, why learn 2 things
at once?"

Company policy. Everything is gonna be C#.

The connection object will be connecting to a local SQLServerCE database.
Wouldn't it be faster to have one connection and use it all over ? Wouldn't
a create, connect, destroy as needed be slow , especially the connect ?

Thanks
 
It really depends on app architecture. The "proper" way is probably to make
the app n-tier with a data access layer that does pooling so it does
maintain and reuse connections. Again, only you know the app architecture
and requirements enough to know how exactly to handle this to get the best
performance.

-Chris
 
Srinivas,

1. You can create a global variable in C# by putting it in a storage class,
such as

public class GlobalVars {
public static Int32 myGVar = 1;
}

then access it as GlobalVars.myGVar = 1 (or similar). If you _were_ to use
VB.NET - you can still use the module for global variables which has global
scope. Although, doing this will violate good OOP practices.

3. The only concern you need to have about objects - is the fact that memory
is allocated for them when they are instantiated... which means X^n for load
time... or in other words - the more controls you have on a form the slower
the form will load. Like Chris mentioned - the dispose method is our
friend.

For your other concerns with globals... see #1.

Rick Winscot
rickly@zyche dot com
 
Back
Top