Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Mike Yearwood
  Where is Mike Yearwood?
 Toronto
 Canada
 Mike Yearwood
 To: Ilya Rabyy
  Where is Ilya Rabyy?
 Fountain Valley
 California - United States
 Ilya Rabyy
 Tags
Subject: RE: PUBl Vars Pro&Contra
Thread ID: 141897 Message ID: 142269 # Views: 31 # Ratings: 0
Version: Visual FoxPro 9 Category: General VFP Topics
Date: Thursday, August 16, 2007 3:01:29 AM         
   


> > When something crashes and dumps you to the command window, the ON SHUTDOWN remains in effect. If it is in main.prg and the program did a SET PROCEDURE TO to clear it, when you try to quit VFP you get an error. Then you have to remember to do ON SHUTDOWN yourself.
> >
> > Using a LOCAL variable to hold a class lets ON SHUTDOWN take care of itself when the app stops. I don't have to look after it manually.
> >

> Now, Mike, you lost me. Could you elaborate some more here? In particular - on the relationship between ON SHUTDOWN and "LOCAL variable to hold a class"? I have to admit I never desined classes in VFP myself, just used and modified the existing ones (does "Espia" ring any bells?) So, I fail to see how the ON SHUTDOWN can be issued in a custom class that is instantiated as an object with its handle stored in a LOCAL memvar (even if it's Main.Main)?

I remember Espia. You've never designed a class? Wow! This is going to take some explaining.

Well, you can make a class pretty easily, but why bother? I mean anybody can take two pieces of wire, run enough electricity to make a spark and ignite gasoline and probably get burned in the process. An engineer would know about something trivial like a spark plug. Teaching programmers to program without design patterns is like teaching kids about the internal combustion engine using wires, electricity and gasoline. It's potentially dangerous.

There's something out there to help us make "standardized" classes called design patterns. You know what a spark plug is? A spark plug is a standardized and safe way to use electricity to ignite gasoline.

In software rather than just using the raw commands to build something the client wants, much like using the wires, electricity and gas, one could recognize that most things programmers do is the same thing over and over and over. Since that's the case we should identify and name these designs. That work has been done already. Look up the Gang of Four and Design Patterns. Honestly it's a good thing, if only the pattern names were not so weird.

Build a class and it's like you've drawn a blueprint for a spark plug. Instantiate an object based on that class design and you've made a spark plug.

Now, if you're going to SET TALK ON, you should programmatically remember what it is before you change it. I believe most programmers do not do that, but it's a VERY GOOD PRACTICE. SET TALK is likely OFF, but not always. Some other part of the system could have turned it ON before a current piece of code executed. This remembering of information in order to put it back is called a memento design pattern. In fact, I want to use a memento pattern EVERY TIME I use the SET command. For example, with a private data session form, the form starts up with SET TALK OFF. I change it to ON, but technically I don't have to reset it back to OFF when the form closes. Consistency is a good thing, especially since my forms can change from private data session to default data session when they start. So I try to always use the memento design pattern.

Here's how to use the memento design pattern to create a memento class for a memento object to remember ON('SHUTDOWN').

Create a class based on custom and call it memento_On and save it in memento_On.vcx. Best practice is to subclass the VFP custom control to your own subclass first, at the very least. Why? Because if you don't you may have more work to do later, such as when you have several memento classes that should all have a new property or method.

In the property sheet for the class...
Add a custom property called icOnClause
Add another custom property call icRememberedValue
Set the default value for both of these to (None)

In the init method of this class, put something like this:
LPARAMETERS m.tcOnClause, m.tcNewCommand
THIS.icOnClause = ALLTRIM(m.tcOnClause)
THIS.icRememberedValue = ON(m.tcOnClause)
IF VARTYPE(m.tcNewCommand) = "C" ;
AND NOT EMPTY(m.tcNewCommand)
  LOCAL m.lcCommand
  m.lcCommand = "ON " + m.tcOnClause + " " + m.tcNewCommand
  &lcCommand.
ENDIF


That code means if you pass "SHUTDOWN" and "DO SHUTDOWN" the command executed will be

ON SHUTDOWN DO SHUTDOWN


In the destroy method, put this:

LOCAL m.lcCommand
m.lcCommand = "ON " + ;
     THIS.icOnClause + " " + ;
     THIS.icRememberedValue
&lcCommand.


That code means when the destroy fires - for any reason, the command will be...

ON SHUTDOWN < whatever it was before >


Now where you would normally setup ON SHUTDOWN for the app, do this

LOCAL m.loOnShutdown
m.loOnShutdown = NewObject('memento_On','memento_On.vcx',.F.,"SHUTDOWN","DO SHUTDOWN")


Yes. That's not as easy as doing ON SHUTDOWN DO SHUTDOWN. Anybody can do that. This will save you the annoyance of having to remember to reset ON SHUTDOWN.

You may not normally turn the ON SHUTDOWN DO SHUTDOWN back to what it was. I insist on it because when I get back to the command window I don't want it in my way.

So where you would normally turn off the ON SHUTDOWN...

wait for it... :)

DON'T DO ANYTHING. You don't have to. This is like magic instead of mere programming! This class has more brains than a spark plug.

When the app finishes and you return to the command window, the destroy event will fire. The object will return ON SHUTDOWN to the previous state all by itself.

If you need to make it restore the previous state on demand, you can though. Just do this...
m.loOnShutdown = .NULL.
RELEASE m.loOnShutdown

It gets better. Since this is a pattern, ALL commands that take the form ON xxxxx command
can magically reset themselves.

Imagine having your error handler reset itself like magic?

LOCAL m.loOnError
m.loOnError = NewObject('memento_On','memento_On.vcx',.F.,"ERROR","DO ERRORHANDLER")


Now this relates to PUBLIC and LOCAL because if I used a public variable instead of a local, when the app exited, the ON SHUTDOWN would not reset until I did CLEAR ALL or RELEASE loOnShutdown. Since that's just as tedious as typing ON SHUTDOWN, why should I want to do that? :)

Visual MaxFrame has a set of mementos, but they're not called that, which is a shame. One of them is much like the one I just showed you, except it does not accept the new command and support for ON KEY LABELS was IMO unfortunately shoe-horned in.

I did an even fancier memento which is still part of Visual MaxFrame. A simpler version of it is here:

http://foxridgesoftware.com/Blogs/tabid/84/EntryID/2/Default.aspx

I'll be writing up another memento design for FoxPro Advisor magazine soon too. I might include the one above too.

Mike Yearwood
www.foxridgesoftware.com
President: Toronto Ontario FoxPro User's Group

COMPLETE THREAD

PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/13/2007 12:08:05 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/13/2007 12:14:19 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/13/2007 12:57:40 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/13/2007 2:32:12 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/13/2007 3:11:49 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/13/2007 7:56:45 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 11:44:08 AM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 12:45:58 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 3:29:09 PM
RE: PUBl Vars Pro&Contra Posted by Tamar Granor @ 8/14/2007 11:01:24 PM
RE: PUBl Vars Pro&Contra Posted by Don Higgins @ 8/14/2007 6:08:45 PM
RE: PUBl Vars Pro&Contra Posted by Borislav Borissov @ 8/13/2007 8:06:04 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 11:29:35 AM
RE: PUBl Vars Pro&Contra Posted by Borislav Borissov @ 8/14/2007 11:52:47 AM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 3:32:44 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/13/2007 8:47:49 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 11:33:59 AM
RE: PUBl Vars Pro&Contra Posted by Hugo Ranea @ 8/14/2007 7:16:32 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/13/2007 9:24:07 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 1:56:56 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 3:53:24 PM
RE: PUBl Vars Pro&Contra Posted by Pamela Thalacker @ 8/14/2007 5:10:35 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 5:23:21 PM
RE: PUBl Vars Pro&Contra Posted by Pamela Thalacker @ 8/14/2007 5:50:03 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 6:33:05 PM
RE: PUBl Vars Pro&Contra Posted by Pamela Thalacker @ 8/14/2007 9:30:16 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 11:13:19 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 5:33:08 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/14/2007 5:51:13 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 9:10:42 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/14/2007 9:23:26 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 9:03:19 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 9:08:02 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 8:04:15 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 8:21:41 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 9:00:41 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 11:17:07 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/14/2007 5:42:39 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 6:36:33 PM
RE: PUBl Vars Pro&Contra Posted by Hugo Ranea @ 8/14/2007 7:28:15 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 7:57:11 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/14/2007 7:46:56 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 8:11:04 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/14/2007 8:31:23 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 8:37:53 PM
RE: PUBl Vars Pro&Contra Posted by Tamar Granor @ 8/14/2007 11:10:39 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 8:00:32 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/14/2007 9:05:56 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/14/2007 9:32:30 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/14/2007 11:40:11 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/15/2007 5:29:29 PM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/15/2007 8:36:16 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/16/2007 12:26:42 AM
RE: PUBl Vars Pro&Contra Posted by Mike Yearwood @ 8/16/2007 3:01:29 AM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/17/2007 5:12:06 PM
RE: PUBl Vars Pro&Contra Posted by Tamar Granor @ 8/14/2007 11:07:01 PM
RE: PUBl Vars Pro&Contra Posted by Tamar Granor @ 8/14/2007 10:58:35 PM
RE: PUBl Vars Pro&Contra Posted by Ilya Rabyy @ 8/15/2007 5:09:16 PM
RE: PUBl Vars Pro&Contra Posted by Vincent Byrne @ 8/14/2007 9:55:05 PM
RE: PUBl Vars Pro&Contra Posted by Andy Kramek @ 8/14/2007 11:17:48 PM
RE: PUBl Vars Pro&Contra Posted by Vincent Byrne @ 8/15/2007 8:10:06 PM
RE: PUBl Vars Pro&Contra Posted by Thomas Bähr @ 8/15/2007 10:50:53 AM