Modular Programming...

**Robin Tucker** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

No - that would be overkill. Perhaps abstracting some functionality into a
"utility" module might make sense, depending on how similar the button
functions are. If they are all doing the same thing, then obviously
methods/subs should be constructed to take advantage of this.

Well, show us a couple of snippets of button code so we can make a better
judgement.

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> This is the scenario:
>
> I have a VB.Net project comprising of a few Forms. On Form1 I have more[/color]
than[color=blue]
> 20 buttons. There is a very lenghty code written in click event of each[/color]
and[color=blue]
> every button. Right now I haven't used any sub procedure. I mean to say I[/color]
am[color=blue]
> writing the code directly in the click event. So it's become very lengthy
> and therefore to figure out some problem or make any changes I have to
> scroll at lot. Also in addition to click event procedures there are may
> other events where code is written. It's kind of mess.
>
> My question is would it be good idea if I add 20 Modules and name them
> Button1Code, Button2Code etc.etc. and create one procedure in all of them
> which will contain the code of Button's click event. Then it would be[/color]
easier[color=blue]
> to quickly find out the code. For example I would know that if I have to
> make changes in the click event of Button1 then I have to go to[/color]
Button1Code[color=blue]
> Module (and check the procedure in it), and so on..
>
> Is this a good idea? What are your suggestions.
>
> Thanks in advance!
>
>[/color]

**Jay B. Harlow [MVP - Outlook]** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Don,
I tend to follow OOP programming over straight Modular programming. Where
code is broken out into different classes, where each class is its own "unit
of responsibility"

How similar is the code in each of the 20 buttons? If the code is largely
the same except for one or two values, or one or two sections. I would
consider creating a new button class that inherits from Button, the one or
two values that are unique per button I would make properties of this class.
The one or two sections I would make events. On the form I would use my new
button class, setting the properties per button that are unique, the form
would handle any unique events. The click event within the new class would
have all the common code, it would use either the events or the properties
for the distinct values per button.

If I have the "same" 20 buttons on multiple forms, then I would consider
create a class for each button, each form would get an instance of that
class. I don't use this one very often.

You can use #region within your form's code to help organize the event
handlers.

Generally I do not move a subroutine (event handler) from a form to a module
to organize my code as I rarely have routines so large that they make the
form's code unmanageable.

Hope this helps
Jay

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> This is the scenario:
>
> I have a VB.Net project comprising of a few Forms. On Form1 I have more[/color]
than[color=blue]
> 20 buttons. There is a very lenghty code written in click event of each[/color]
and[color=blue]
> every button. Right now I haven't used any sub procedure. I mean to say I[/color]
am[color=blue]
> writing the code directly in the click event. So it's become very lengthy
> and therefore to figure out some problem or make any changes I have to
> scroll at lot. Also in addition to click event procedures there are may
> other events where code is written. It's kind of mess.
>
> My question is would it be good idea if I add 20 Modules and name them
> Button1Code, Button2Code etc.etc. and create one procedure in all of them
> which will contain the code of Button's click event. Then it would be[/color]
easier[color=blue]
> to quickly find out the code. For example I would know that if I have to
> make changes in the click event of Button1 then I have to go to[/color]
Button1Code[color=blue]
> Module (and check the procedure in it), and so on..
>
> Is this a good idea? What are your suggestions.
>
> Thanks in advance!
>
>[/color]

**I_AM_DON_AND_YOU?** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

99% of code written in all the click event is different. Why you think it
would "overkill" ?

Thanks!

"Robin Tucker" <idontwanttobes pammedanymore@r eallyidont.com> wrote in
message news:bnbn9o$3eg $1$8302bc10@new s.demon.co.uk.. .[color=blue]
> No - that would be overkill. Perhaps abstracting some functionality into[/color]
a[color=blue]
> "utility" module might make sense, depending on how similar the button
> functions are. If they are all doing the same thing, then obviously
> methods/subs should be constructed to take advantage of this.
>
> Well, show us a couple of snippets of button code so we can make a better
> judgement.
>
>
> "I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
> news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=green]
> > This is the scenario:
> >
> > I have a VB.Net project comprising of a few Forms. On Form1 I have more[/color]
> than[color=green]
> > 20 buttons. There is a very lenghty code written in click event of each[/color]
> and[color=green]
> > every button. Right now I haven't used any sub procedure. I mean to say[/color][/color]
I[color=blue]
> am[color=green]
> > writing the code directly in the click event. So it's become very[/color][/color]
lengthy[color=blue][color=green]
> > and therefore to figure out some problem or make any changes I have to
> > scroll at lot. Also in addition to click event procedures there are may
> > other events where code is written. It's kind of mess.
> >
> > My question is would it be good idea if I add 20 Modules and name them
> > Button1Code, Button2Code etc.etc. and create one procedure in all of[/color][/color]
them[color=blue][color=green]
> > which will contain the code of Button's click event. Then it would be[/color]
> easier[color=green]
> > to quickly find out the code. For example I would know that if I have to
> > make changes in the click event of Button1 then I have to go to[/color]
> Button1Code[color=green]
> > Module (and check the procedure in it), and so on..
> >
> > Is this a good idea? What are your suggestions.
> >
> > Thanks in advance!
> >
> >[/color]
>
>[/color]

**I_AM_DON_AND_YOU?** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

99% of code written in all the click event is different.

Thanks

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow@ema il.msn.com> wrote in message
news:u9$tESlmDH A.3504@TK2MSFTN GP11.phx.gbl...[color=blue]
> Don,
> I tend to follow OOP programming over straight Modular programming. Where
> code is broken out into different classes, where each class is its own[/color]
"unit[color=blue]
> of responsibility"
>
> How similar is the code in each of the 20 buttons? If the code is largely
> the same except for one or two values, or one or two sections. I would
> consider creating a new button class that inherits from Button, the one or
> two values that are unique per button I would make properties of this[/color]
class.[color=blue]
> The one or two sections I would make events. On the form I would use my[/color]
new[color=blue]
> button class, setting the properties per button that are unique, the form
> would handle any unique events. The click event within the new class would
> have all the common code, it would use either the events or the properties
> for the distinct values per button.
>
> If I have the "same" 20 buttons on multiple forms, then I would consider
> create a class for each button, each form would get an instance of that
> class. I don't use this one very often.
>
> You can use #region within your form's code to help organize the event
> handlers.
>
> Generally I do not move a subroutine (event handler) from a form to a[/color]
module[color=blue]
> to organize my code as I rarely have routines so large that they make the
> form's code unmanageable.
>
> Hope this helps
> Jay
>
> "I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
> news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=green]
> > This is the scenario:
> >
> > I have a VB.Net project comprising of a few Forms. On Form1 I have more[/color]
> than[color=green]
> > 20 buttons. There is a very lenghty code written in click event of each[/color]
> and[color=green]
> > every button. Right now I haven't used any sub procedure. I mean to say[/color][/color]
I[color=blue]
> am[color=green]
> > writing the code directly in the click event. So it's become very[/color][/color]
lengthy[color=blue][color=green]
> > and therefore to figure out some problem or make any changes I have to
> > scroll at lot. Also in addition to click event procedures there are may
> > other events where code is written. It's kind of mess.
> >
> > My question is would it be good idea if I add 20 Modules and name them
> > Button1Code, Button2Code etc.etc. and create one procedure in all of[/color][/color]
them[color=blue][color=green]
> > which will contain the code of Button's click event. Then it would be[/color]
> easier[color=green]
> > to quickly find out the code. For example I would know that if I have to
> > make changes in the click event of Button1 then I have to go to[/color]
> Button1Code[color=green]
> > Module (and check the procedure in it), and so on..
> >
> > Is this a good idea? What are your suggestions.
> >
> > Thanks in advance!
> >
> >[/color]
>
>[/color]

**Jay B. Harlow [MVP - Outlook]** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Don,
Did you read the COMPLETE message, did the other two comments help?

Hope this helps
Jay

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:eDlkdXlmDH A.964@TK2MSFTNG P10.phx.gbl...[color=blue]
> 99% of code written in all the click event is different.
>
> Thanks
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow@ema il.msn.com> wrote in[/color]
message[color=blue]
> news:u9$tESlmDH A.3504@TK2MSFTN GP11.phx.gbl...[color=green]
> > Don,
> > I tend to follow OOP programming over straight Modular programming.[/color][/color]
Where[color=blue][color=green]
> > code is broken out into different classes, where each class is its own[/color]
> "unit[color=green]
> > of responsibility"
> >
> > How similar is the code in each of the 20 buttons? If the code is[/color][/color]
largely[color=blue][color=green]
> > the same except for one or two values, or one or two sections. I would
> > consider creating a new button class that inherits from Button, the one[/color][/color]
or[color=blue][color=green]
> > two values that are unique per button I would make properties of this[/color]
> class.[color=green]
> > The one or two sections I would make events. On the form I would use my[/color]
> new[color=green]
> > button class, setting the properties per button that are unique, the[/color][/color]
form[color=blue][color=green]
> > would handle any unique events. The click event within the new class[/color][/color]
would[color=blue][color=green]
> > have all the common code, it would use either the events or the[/color][/color]
properties[color=blue][color=green]
> > for the distinct values per button.
> >
> > If I have the "same" 20 buttons on multiple forms, then I would consider
> > create a class for each button, each form would get an instance of that
> > class. I don't use this one very often.
> >
> > You can use #region within your form's code to help organize the event
> > handlers.
> >
> > Generally I do not move a subroutine (event handler) from a form to a[/color]
> module[color=green]
> > to organize my code as I rarely have routines so large that they make[/color][/color]
the[color=blue][color=green]
> > form's code unmanageable.
> >
> > Hope this helps
> > Jay
> >
> > "I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
> > news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
> > > This is the scenario:
> > >
> > > I have a VB.Net project comprising of a few Forms. On Form1 I have[/color][/color][/color]
more[color=blue][color=green]
> > than[color=darkred]
> > > 20 buttons. There is a very lenghty code written in click event of[/color][/color][/color]
each[color=blue][color=green]
> > and[color=darkred]
> > > every button. Right now I haven't used any sub procedure. I mean to[/color][/color][/color]
say[color=blue]
> I[color=green]
> > am[color=darkred]
> > > writing the code directly in the click event. So it's become very[/color][/color]
> lengthy[color=green][color=darkred]
> > > and therefore to figure out some problem or make any changes I have to
> > > scroll at lot. Also in addition to click event procedures there are[/color][/color][/color]
may[color=blue][color=green][color=darkred]
> > > other events where code is written. It's kind of mess.
> > >
> > > My question is would it be good idea if I add 20 Modules and name them
> > > Button1Code, Button2Code etc.etc. and create one procedure in all of[/color][/color]
> them[color=green][color=darkred]
> > > which will contain the code of Button's click event. Then it would be[/color]
> > easier[color=darkred]
> > > to quickly find out the code. For example I would know that if I have[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > make changes in the click event of Button1 then I have to go to[/color]
> > Button1Code[color=darkred]
> > > Module (and check the procedure in it), and so on..
> > >
> > > Is this a good idea? What are your suggestions.
> > >
> > > Thanks in advance!
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Robin Tucker** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Like I say, its difficult to judge based on what you have told us.

For example, if you are writing code to handle 20 different types of image
file - one for each type, I would not have a problem breaking it into 20
different classes (21!) with a base class and derived classes. But there is
little point making modules - you might as well #region each button.

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:OOji9SlmDH A.2364@TK2MSFTN GP11.phx.gbl...[color=blue]
> 99% of code written in all the click event is different. Why you think it
> would "overkill" ?
>
> Thanks!
>
> "Robin Tucker" <idontwanttobes pammedanymore@r eallyidont.com> wrote in
> message news:bnbn9o$3eg $1$8302bc10@new s.demon.co.uk.. .[color=green]
> > No - that would be overkill. Perhaps abstracting some functionality[/color][/color]
into[color=blue]
> a[color=green]
> > "utility" module might make sense, depending on how similar the button
> > functions are. If they are all doing the same thing, then obviously
> > methods/subs should be constructed to take advantage of this.
> >
> > Well, show us a couple of snippets of button code so we can make a[/color][/color]
better[color=blue][color=green]
> > judgement.
> >
> >
> > "I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
> > news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
> > > This is the scenario:
> > >
> > > I have a VB.Net project comprising of a few Forms. On Form1 I have[/color][/color][/color]
more[color=blue][color=green]
> > than[color=darkred]
> > > 20 buttons. There is a very lenghty code written in click event of[/color][/color][/color]
each[color=blue][color=green]
> > and[color=darkred]
> > > every button. Right now I haven't used any sub procedure. I mean to[/color][/color][/color]
say[color=blue]
> I[color=green]
> > am[color=darkred]
> > > writing the code directly in the click event. So it's become very[/color][/color]
> lengthy[color=green][color=darkred]
> > > and therefore to figure out some problem or make any changes I have to
> > > scroll at lot. Also in addition to click event procedures there are[/color][/color][/color]
may[color=blue][color=green][color=darkred]
> > > other events where code is written. It's kind of mess.
> > >
> > > My question is would it be good idea if I add 20 Modules and name them
> > > Button1Code, Button2Code etc.etc. and create one procedure in all of[/color][/color]
> them[color=green][color=darkred]
> > > which will contain the code of Button's click event. Then it would be[/color]
> > easier[color=darkred]
> > > to quickly find out the code. For example I would know that if I have[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > make changes in the click event of Button1 then I have to go to[/color]
> > Button1Code[color=darkred]
> > > Module (and check the procedure in it), and so on..
> > >
> > > Is this a good idea? What are your suggestions.
> > >
> > > Thanks in advance!
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**I_AM_DON_AND_YOU?** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

You wrote:
".............. You can use #region within your form's code to help organize
the event handlers....."

Could you tell me how it helps us to organize event handlers.

Thanks!

**Tom Leylan** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote...
[color=blue]
> My question is would it be good idea if I add 20 Modules and name them
> Button1Code, Button2Code etc.etc. and create one procedure in all of them[/color]

As was pointed out by someone else when they used the term "overkill". .. you
are basically trading one long relatively unmanageable form for 20 small but
still relatively unmanageable modules. Extremes in either direction are
usually a bad thing. It wouldn't be easy (for instance) if all your books
were on one long bookshelf... the alternative needn't be a single bookshelf
for every book however.

As an alternative you could add a single module that contained 20
procedures. That way you've divided the mess into two parts rather than 21
parts. Additionally you should avoid naming any module "Button#Cod e" as a
button is simply a UI component. It happens to be the way you designed the
operation to be run but it isn't what the operation "does." If Button #2
happened to be labeled "Save Customer" then the subroutine could be called
SaveCustomer but never Button2Routine.

All things being equal however, you can just try your idea out. Make 20
modules and cut and paste the code. I don't think you will find it easier,
I'll guess most people believe you will find it harder... on the other hand
if you find it easier then who's to argue?

**I_AM_DON_AND_YOU?** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Could you tell what you mean to say by this:

".....you might as well #region each button...."

Thanks!

**Robin Tucker** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Well its a simple little trick to maybe reduce the amount of scrolling you
have to do:

#region "Button 1"
' code for button 1
#end region

#region "Button 2"
' code for button 2
#end region

Then, you will be able to "expand/collapse" the regions. I do this with a
rather heavy form I have, breaking it down into various handler subgroup
regions. Just makes it easier to see structure thats all.

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:%23UEVxjlm DHA.2676@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> Could you tell what you mean to say by this:
>
> ".....you might as well #region each button...."
>
> Thanks!
>
>
>[/color]

**Jay B. Harlow [MVP - Outlook]** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Don,
You can use #regions to group related handlers into collapsible sections of
code.

For example in the form I have open right now. I have

#Region " File menu support "

Private Sub menuFileClose_C lick(...) Handles menuFileClose.C lick
me.Close()
End Sub

...

#End Region

#Region " View menu support "
...

#End Region

Where the first region has all the event handlers for the file menu, while
the second region has all the event handlers for the view menu.

When I open the above form in Code view, both of the above sections are
collapsed by default. If I need to work on the File Menu I open that
section, if I need to work on the View menu I open that section.

You could put your button click handlers into similar sections. Either a
single section, individual sections or grouped logically.

Also, "Edit - Outlining" has a number of options to show or hide routines. I
use "Collapse to Definitions" and "Toggle all Outlining" on the "Edit -
Outlining" routinely, to help find which routine I want to work on, then I
manually expand that one routine.

Hope this helps
Jay

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:OjfkBflmDH A.1244@TK2MSFTN GP11.phx.gbl...[color=blue]
> You wrote:
> ".............. You can use #region within your form's code to help[/color]
organize[color=blue]
> the event handlers....."
>
> Could you tell me how it helps us to organize event handlers.
>
> Thanks!
>
>
>
>
>[/color]

**Jay B. Harlow [MVP - Outlook]** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Don,
I should add that there is a Refactoring http://www.refactoring.com where
you can replace a Method with a Method Object. The Method Object is a class
that contains the code for the method.

Replace Function with Command

http://www.refactoring.com/catalog/replaceMethodWithMethodObject.html

The parameters to the method become parameters to the objects Constructor,
while the class has a single method (initially) that is the body of the
original method. The intent is then to refactor this method into smaller
more manageable methods.

However I am concerned that you are heading toward what Tom has stated, "you
are basically trading one long relatively unmanageable form for 20 small but
still relatively unmanageable modules" along with an unmanageable form.

As I stated in my other post I tend to follow OOP, and I tend to follow the
smaller routines are better routines rule.

If you do go the 20 module route, I would strongly suggest 20 classes, where
the procedure in each class is declared as Shared.

Public NotInheritable Class Form1Button2Cod e
Private Sub New()
End Sub

Public Shared Sub Button2Click()
End Sub

End Class

This requires you to use the class name to call the procedure, helping to
encapsulate the method better. Also I included the name of the form with the
name of the class, to better identify that the code really belongs to the
form. Encapsulation is another OOP term. Its better to Encapsulate the
button handlers in the form, as then all the code for the form is with the
form.

Note the NotInheritable on the class prevents others from deriving from the
class, the Private Sub New prevents instances from being created, which is
effectively what a Module does. However a Module you can call its routines
without giving the module name, you then have no real idea where the routine
came from. With using a class as above you at least know the routine came
from the above class.

Hope this helps
Jay

"I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
news:%23JBaWGlm DHA.2200@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> This is the scenario:
>
> I have a VB.Net project comprising of a few Forms. On Form1 I have more[/color]
than[color=blue]
> 20 buttons. There is a very lenghty code written in click event of each[/color]
and[color=blue]
> every button. Right now I haven't used any sub procedure. I mean to say I[/color]
am[color=blue]
> writing the code directly in the click event. So it's become very lengthy
> and therefore to figure out some problem or make any changes I have to
> scroll at lot. Also in addition to click event procedures there are may
> other events where code is written. It's kind of mess.
>
> My question is would it be good idea if I add 20 Modules and name them
> Button1Code, Button2Code etc.etc. and create one procedure in all of them
> which will contain the code of Button's click event. Then it would be[/color]
easier[color=blue]
> to quickly find out the code. For example I would know that if I have to
> make changes in the click event of Button1 then I have to go to[/color]
Button1Code[color=blue]
> Module (and check the procedure in it), and so on..
>
> Is this a good idea? What are your suggestions.
>
> Thanks in advance!
>
>[/color]

**I_AM_DON_AND_YOU?** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Thanks. It's new thing for me. It would have been good if we could able to
insert Region WITHIN a click event also.

"Robin Tucker" <idontwanttobes pammedanymore@r eallyidont.com> wrote in
message news:bnbq5l$4qi $1$8300dec7@new s.demon.co.uk.. .[color=blue]
> Well its a simple little trick to maybe reduce the amount of scrolling you
> have to do:
>
> #region "Button 1"
> ' code for button 1
> #end region
>
> #region "Button 2"
> ' code for button 2
> #end region
>
> Then, you will be able to "expand/collapse" the regions. I do this with a
> rather heavy form I have, breaking it down into various handler subgroup
> regions. Just makes it easier to see structure thats all.
>
>
>
>
> "I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
> news:%23UEVxjlm DHA.2676@TK2MSF TNGP11.phx.gbl. ..[color=green]
> > Could you tell what you mean to say by this:
> >
> > ".....you might as well #region each button...."
> >
> > Thanks!
> >
> >
> >[/color]
>
>[/color]

**I_AM_DON_AND_YOU?** · Nov 20 '05, 05:08 AM

Re: Modular Programming...

Thanks. I will use this "Region...E nd Region.." structure.

Also, do you have any (similar) idea to hide/unhide the code within one
procedure.

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow@ema il.msn.com> wrote in message
news:ui8wRqlmDH A.2000@TK2MSFTN GP12.phx.gbl...[color=blue]
> Don,
> You can use #regions to group related handlers into collapsible sections[/color]
of[color=blue]
> code.
>
> For example in the form I have open right now. I have
>
> #Region " File menu support "
>
> Private Sub menuFileClose_C lick(...) Handles menuFileClose.C lick
> me.Close()
> End Sub
>
> ...
>
> #End Region
>
> #Region " View menu support "
> ...
>
> #End Region
>
> Where the first region has all the event handlers for the file menu, while
> the second region has all the event handlers for the view menu.
>
> When I open the above form in Code view, both of the above sections are
> collapsed by default. If I need to work on the File Menu I open that
> section, if I need to work on the View menu I open that section.
>
> You could put your button click handlers into similar sections. Either a
> single section, individual sections or grouped logically.
>
> Also, "Edit - Outlining" has a number of options to show or hide routines.[/color]
I[color=blue]
> use "Collapse to Definitions" and "Toggle all Outlining" on the "Edit -
> Outlining" routinely, to help find which routine I want to work on, then I
> manually expand that one routine.
>
> Hope this helps
> Jay
>
> "I_AM_DON_AND_Y OU?" <user@domain.co m> wrote in message
> news:OjfkBflmDH A.1244@TK2MSFTN GP11.phx.gbl...[color=green]
> > You wrote:
> > ".............. You can use #region within your form's code to help[/color]
> organize[color=green]
> > the event handlers....."
> >
> > Could you tell me how it helps us to organize event handlers.
> >
> > Thanks!
> >
> >
> >
> >
> >[/color]
>
>[/color]

Modular Programming...

Modular Programming...

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment