jwcolby
jwcolby at colbyconsulting.com
Mon Feb 9 10:41:04 CST 2009
Max >Sinking and Uping (or whatever the reverse of sinking is) or WithEvents is not something I have ever got into and have never ever had a need for this Then you have never used Code Behind Forms because that is EXACTLY what you are doing when you write code behind a form, SINKING events and writing code to do something. The only difference is that Access hides the fact that you are doing it. And it was not my intent to single you out or insult you with the "so 1990s", but I thought I saw someone else mention tags. I just wanted to make it clear that classes provide a place to do stuff that is infinitely superior to tags. I used tags... before I discovered classes. I have never used one since. Well... that is not quite true, I use the subform control tag to this day (and I feel SOOOOOooo guilty ;-), but that is the ONLY tag I use. If you are a programmer, then you know that encapsulation is a good thing. If you use a function, you are encapsulating code, and often variables. If you use a module, you are encapsulating code (functions) and variables. Encapsulation simply means keeping together the things that belong together. Classes are just "the next level" of encapsulation. Classes allow you to encapsulate a "system", and load the variables as well as the code to manipulate those variables... AND the event sinks as well if you need them. Events simply allow you to move the sinking of events out of the form's class into a class for the object that you are sinking events for, whether that is a form or controls. It is "encapsulating" the variables, the code, and the events that cause the code to run, into a class specifically for that object. If you think about it, the class behind a form "belongs" to the form, it does not "belong" to the controls on the form. And yet the "average" programmer sinks all of the events for all the controls on his form in the form's class. If you have a complex SYSTEM for controls that means that you can have pages and pages of code in the form, that really doesn't belong to the form itself, it belongs to the controls on the form. Encapsulation moves that code out of the form class into a class for the control or controls that make up the "system" I understand "have never ever had a need for this", since I designed systems for about 6 or 7 years before my good friend Shamil finally managed to teach me events. The things I designed worked, but they were less than optimum, though of course I did not know that. In many cases classes and events make programs just incredibly easier. Let me give you one example of a "system" and how and why you would move such a system out into a class. This is just to get you thinking, but is a real life example. I wrote a call center for a Disability Insurance Claims processor. They had a set of rules, handed down to them by the insurance industry. A claim can be several of the following: Workman's compensation Auto Related Illness Accident/Injury Maternity But they cannot be ALL of those things! Remember that these catagories are designed by the industry and used everywhere. I do not get a choice to dispute the logic. If Workman's comp then Maternity = false If Maternity then Workman's comp = false If Auto Related then Accident = true If Accident then Illness = False If Illness then Accident = false If Maternity then Illness = true If Maternity then Accident = false As you can see, this is not just "if a check box is clicked then..." there are a WHOLE bunch of rules that interact. I have to set and clear other check boxes based on just a single check box being checked. A class allows me to ENCAPSULATE the code that does this, and it allows me to SINK the events from 5 different check boxes and automatically execute the correct code. Could I embed this directly in the form? Sure! Does it belong there? Of course not, it belongs in a class that deals with the SYSTEM of setting and clearing these checkboxes. If I need these check boxes in another form (and I have them in three different forms) then I just dim a variable for this class and load it, passing in the 5 check boxes. Voila, I am done. If I need to correct a bug I do so in the ONE class, not in X different forms. If you have never had to handle a SYSTEM of rules like this then you have never done very complex programming. I bet you have, but you just never knew how to use a class to encapsulate the variables, code and event sinks all in one place. John W. Colby www.ColbyConsulting.com Max Wanadoo wrote: > Ha! It was in the 1990's I wrote it <g>. I dont use tags now, but they > might be useful for some purposes - I can think of one but won't go into > that now. > > The aim was to demonstrate easily, the use of control looping with the > various control types and not the storage of variable values. > > I also use classes but I am not a devotee like you John. Sinking and Uping > (or whatever the reverse of sinking is) or WithEvents is not something I > have ever got into and have never ever had a need for this - I say that > because I have not come across anything that I cannot do without using > it/them. > > I would be interest to follow a thread though. > > Thanks > Max