Modular Programming...

[I_AM_DON_AND_YOU?]

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than
20 buttons. There is a very lenghty code written in click event of each and
every button. Right now I haven't used any sub procedure. I mean to say I am
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 easier
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 Button1Code
Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[Robin Tucker]

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than 20 buttons. There is a very lenghty code written in click event of each and every button. Right now I haven't used any sub procedure. I mean to say I am 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 easier 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 Button1Code Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[Jay B. Harlow [MVP - Outlook]]

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than 20 buttons. There is a very lenghty code written in click event of each and every button. Right now I haven't used any sub procedure. I mean to say I am 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 easier 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 Button1Code Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[I_AM_DON_AND_YOU?]

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

Thanks!

"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:bn*******************@news.demon.co.uk...

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than

20 buttons. There is a very lenghty code written in click event of each

and

every button. Right now I haven't used any sub procedure. I mean to say I am

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

easier

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

Button1Code

Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[I_AM_DON_AND_YOU?]

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

Thanks

"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:u9**************@TK2MSFTNGP11.phx.gbl...

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than

20 buttons. There is a very lenghty code written in click event of each

and

every button. Right now I haven't used any sub procedure. I mean to say I am

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

easier

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

Button1Code

Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[Jay B. Harlow [MVP - Outlook]]

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

Hope this helps
Jay

"I_AM_DON_AND_YOU?" <us**@domain.com> wrote in message
news:eD*************@TK2MSFTNGP10.phx.gbl...

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

Thanks

"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message news:u9**************@TK2MSFTNGP11.phx.gbl...

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more

than

20 buttons. There is a very lenghty code written in click event of

each and

every button. Right now I haven't used any sub procedure. I mean to

say I

am

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

easier

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

Button1Code

Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[Robin Tucker]

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_YOU?" <us**@domain.com> wrote in message
news:OO**************@TK2MSFTNGP11.phx.gbl...

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

Thanks!

"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:bn*******************@news.demon.co.uk...

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more

than

20 buttons. There is a very lenghty code written in click event of

each and

every button. Right now I haven't used any sub procedure. I mean to

say I

am

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

easier

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

Button1Code

Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[I_AM_DON_AND_YOU?]

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]

"I_AM_DON_AND_YOU?" <us**@domain.com> wrote...

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

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#Code" 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?]

Could you tell what you mean to say by this:

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

Thanks!

[Robin Tucker]

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Could you tell what you mean to say by this:

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

Thanks!

[Jay B. Harlow [MVP - Outlook]]

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_Click(...) Handles menuFileClose.Click
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_YOU?" <us**@domain.com> wrote in message
news:Oj**************@TK2MSFTNGP11.phx.gbl...

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!

[Jay B. Harlow [MVP - Outlook]]

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.

http://www.refactoring.com/catalog/r...hodObject.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 Form1Button2Code
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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than 20 buttons. There is a very lenghty code written in click event of each and every button. Right now I haven't used any sub procedure. I mean to say I am 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 easier 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 Button1Code Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

[I_AM_DON_AND_YOU?]

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" <id*************************@reallyidont.com> wrote in
message news:bn*******************@news.demon.co.uk...

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_YOU?" <us**@domain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Could you tell what you mean to say by this:

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

Thanks!

[I_AM_DON_AND_YOU?]

Thanks. I will use this "Region...End Region.." structure.

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

"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:ui**************@TK2MSFTNGP12.phx.gbl...

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_Click(...) Handles menuFileClose.Click
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_YOU?" <us**@domain.com> wrote in message
news:Oj**************@TK2MSFTNGP11.phx.gbl...

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!

[Jay B. Harlow [MVP - Outlook]]

Don,
As I mentioned, I find smaller routines are better. Rather then have one
long routine, I tend to have many smaller routines. With smaller routines in
most cases you will probably have better code reuse.

With smaller routines, you don't need to hide code within the routine
itself, using the options on the outlining menu, you can hide or unhide the
routine bodies...

Hope this helps
Jay

"I_AM_DON_AND_YOU?" <us**@domain.com> wrote in message
news:eC****************@TK2MSFTNGP11.phx.gbl...

Thanks. I will use this "Region...End Region.." structure.

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

"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message news:ui**************@TK2MSFTNGP12.phx.gbl...

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_Click(...) Handles menuFileClose.Click
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_YOU?" <us**@domain.com> wrote in message
news:Oj**************@TK2MSFTNGP11.phx.gbl...

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!

[Cor]

Hi Jay B,

Lets start with, we totaly agree. But I have a question. I am of course from
an old fashion time.

What I have always thought was that modulair programming was to divide your
project in managable structures, with reusable code in all parts of your
project.

The best way to do that is in my eyes is using OOP techniques.

When I reads this kinds of threads I always think. Modulair programming is
translated as using old fashion VB modules, which have in my eyes nothing to
do with modulair programming.

What is it what I see wrong?

Cor

[Road Warrior]

well your syntax really sux for one.
"Cor" <no*@non.com> wrote in message
news:uJ**************@tk2msftngp13.phx.gbl...

Hi Jay B,

Lets start with, we totaly agree. But I have a question. I am of course from an old fashion time.

What I have always thought was that modulair programming was to divide your project in managable structures, with reusable code in all parts of your
project.

The best way to do that is in my eyes is using OOP techniques.

When I reads this kinds of threads I always think. Modulair programming is
translated as using old fashion VB modules, which have in my eyes nothing to do with modulair programming.

What is it what I see wrong?

Cor

[Jay B. Harlow [MVP - Outlook]]

Cor,
Its one of those things that it is both. :-)

The way I view it is, in the simplest sense Modular program is breaking your
problem into individual modules. This can be applied to almost all
programming languages, including languages that do not support Object
Oriented Programming. For example on the AS400 (iSeries) I can apply modular
programming to an RPG or COBOL program, by breaking my RPG or COBOL program
in to manageable modules.

OOP definitely encompasses modular programming as you group (divide) your
project into manageable structures or classes...

Hope this helps
Jay

"Cor" <no*@non.com> wrote in message
news:uJ**************@tk2msftngp13.phx.gbl...

Hi Jay B,

Lets start with, we totaly agree. But I have a question. I am of course from an old fashion time.

What I have always thought was that modulair programming was to divide your project in managable structures, with reusable code in all parts of your
project.

The best way to do that is in my eyes is using OOP techniques.

When I reads this kinds of threads I always think. Modulair programming is
translated as using old fashion VB modules, which have in my eyes nothing to do with modulair programming.

What is it what I see wrong?

Cor

[Tom Leylan]

"Cor" <no*@non.com> wrote...

When I reads this kinds of threads I always think. Modulair programming is
translated as using old fashion VB modules, which have in my eyes nothing to do with modulair programming.

What is it what I see wrong?

I'll jump in and suggest you have it correct. People seem to be mistaking
"modules" with modular programming. Writing modularly is a logical
consideration which promotes code re-use while reducing maintenance
headaches. Modules are physical things and are little more than a storage
mechanism.

It is quite possible to write a "modular" program in a single physical
program file or to write a completely non-modular program which is stored in
a dozen or two module files. I wrote a short article named "Function
Reusability and Contracts" which attempted to illustrate the idea... it
ended with "remember, a dumb function is a smart function."

Meaning of course that anything it needs to know is passed in and any
results are passed back. It isn't typically considered modular if the
routine relies on some public variables being present and it isn't
considered modular if the function you devise to calculate the cubed root
automatically displays the result in a textbox.

[I_AM_DON_AND_YOU?]

Can we read your article?

[Cor]

Jay B,
Thanks for your answer
I think we agree even more now.
Cor

[Cor]

Tom,
Thanks for your answer, gives me more courage to tackle some arguing.
Cor

[Tom Leylan]

"I_AM_DON_AND_YOU?" <us**@domain.com> wrote...

Can we read your article?

There are a few of them on-line, choose the "Clipper" link at:
http://www.leylan.com

They were written about a DOS-based compiler but I think you will find that
they are generic enough to be of value in a Windows world. Personally I was
really happy with "Look Towards the Past" which dredged up old programming
samples and applied them to the present.

[I_AM_DON_AND_YOU?]

Thanks.

"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:%v*******************@twister.nyc.rr.com...

"I_AM_DON_AND_YOU?" <us**@domain.com> wrote...

Can we read your article?
There are a few of them on-line, choose the "Clipper" link at:
http://www.leylan.com

They were written about a DOS-based compiler but I think you will find

that they are generic enough to be of value in a Windows world. Personally I was really happy with "Look Towards the Past" which dredged up old programming
samples and applied them to the present.

[Fergus Cooney]

Hi Jesse,

You deserved a ROFL with a couple of pots in a different context. Those
were OT and OTT threads in which any old rubbish was 'appropriate'.

Here in the useful stream, a comment like that is of no use to anyone.

Regards,
Fergus

[Fergus Cooney]

Hi Don,

If you would like - don't laugh - to send me a zip - sorry, ROFL - of
your Form, ROFL.

Let's start again.

If you send me a zip of your Form then I will be quite happy to show you
how to apply the ideas that have been put forward here. I have no objection to
the zip being attached here but it might be appropriate, at this time, to send
it to me by email. I'll only need the source files - Form and .resx. No obj or
bin directories this time, eh? ;-)

Regards,
Fergus

ps. In case you missed it in the other thread. Button1.ContextMenu = Nothing
worked fine when I tried it.