Sie sind auf Seite 1von 2

Print Article

Seite 1 von 2

Issue Date: FoxTalk January 1998

SYS(1270): Object Location


Jim Booth jbooth@jamesbooth.com

Help only takes you so far. How does Visual FoxPro really work? What do you need to know about the internals of each command and function -- the dirt on how to use Visual FoxPro as only a hands-on developer can tell you. In this new feature, Jim Booth will take you past the syntax and explain how to really use a piece of Visual FoxPro each month.
I was chatting with Whil Hentzen one day, and he proposed that I write a column for FoxTalk . I asked, "Well, what would it be about?" Whil, in his usual manner, said, "Visual FoxPro." After a little bit more digging, he explained that there are 837 functions, properties, events, and methods in VFP 5.0, and it might be fun to explore how some of these things actually work. So here we go -- a behind-the-scenes look at the tips, tricks, and traps of the tools that VFP's language gives us. This month, I'm going to explore one of my favorite SYS functions. The help file lists the syntax for this function as follows, where nxCoord and nyCoord are horizontal and vertical coordinates. It says that the function will return an object reference to the object that's at those coordinates, or a logical .F. if there's no object at that location. SYS (1270 [, nxCoord, nyCoord] ) So far this sounds okay, but the real utility of this function is when you don't supply the coordinates. In that case, it returns the object reference for the object that's currently under the mouse pointer (or .F. if no object is under the mouse). This can be very useful when debugging an application. I often want to investigate the properties of a particular object during debugging. Sometimes I find it rather time-consuming to navigate through the containership in the Locals window of the debugger to get to the particular object of interest. I have taken to setting up an ON KEY LABEL command in the command window before running my application. It looks like this: OX=.NULL. ON KEY LABEL F12 OX = SYS(1270) Then, during the application, I place my mouse over the object of interest and press F12. From there I can use OX to refer to the object and start looking at the various properties. There are two ways to conduct this investigation. I can use the LOCALS window and drill down through the object's hierarchy if I just want to look at the properties. On the other hand, I might want to change the values of properties for one reason or another. In this case, I have to have the Command Window available during the running of the application. The startup program for my application looks like this: LPARAMETERS plDevMode * Set up environment * Now create the application IF plDevMode * Development mode * oApp is declared public so that it will * exist after this program ends. PUBLIC oApp oApp = CreateObject( ; "ApplicationObject",plDevMode, @llFailed) ELSE * User mode llFailed = .F. oApp = CreateObject( ; "ApplicationObject",plDevMode, @llFailed) IF NOT llFailed READ EVENTS ENDIF SET SYSMENU TO DEFAULT CLOSE ALL

http://foxtalknewsletter.com/ME2/Audiences/Segments/Publications/Print.asp?Module=... 07.02.06

Print Article

Seite 2 von 2

CLEAR ALL ENDIF This code will issue a READ EVENTS if the logical parameter is not passed to it. If the value of .T. is passed, then the program will create the application object, but it won't issue a READ EVENTS. By not issuing a READ EVENTS, control is returned to the Command Window, and my ON KEY LABEL can be used to investigate and modify any objects I choose. For example, if I'm debugging a situation involving a particular form and I suspect that a certain control has an improper value for one of its properties, all I have to do is run the application and pass .T. as the argument. Then I run the form in question, place the mouse over the control, and press F12. In the Command Window, I can then determine values with calls like the following and see the result displayed on screen: ? Ox.MyProperty I can even change the value, then let the form continue to see what happens: ox.MyProperty = "The right value" SYS(1270) can be a very valuable tool for testing and debugging your applications. By the way, using a startup program like the preceding one allows me to do a lot of things while the app is running. I can edit forms and classes while the app is running and then rerun them to see the effect immediately. There are some limits to this, but if I encounter them I just exit the app and do it the old-fashioned way.

http://foxtalknewsletter.com/ME2/Audiences/Segments/Publications/Print.asp?Module=... 07.02.06

Das könnte Ihnen auch gefallen