Possibly, I remember this from the time that the help system was delivered on chiseled stone tablets, but I believe that the compiler cannot evaluate all elements in a compound if statement because to do so would be too daunting a task. Chief among the problems is that VFP will evaluate function calls in the statement and it also allows for screwy logic like
if foo1() or foo2() etc,,,, where foo1() may actually create or alter memvars used by foo2(). Isn't there also an issue re short circuit logic? Possibly this is a system setting, but if short circuit prevails and foo1() returns .f. , there's no reason to evaluate foo2(). OTOH, it's also possible to write poor code that requires foo2() if fire for the same reasons cited above. On Thu, Sep 13, 2012 at 9:35 PM, Ken Dibble <[email protected]> wrote: > VFP 9 SP 1 > > I ran across this oddment today: > > Consider an SCX form containing a textbox, a command button, and a method > called ProcessIt(). If you press the command button, THISFORM.ProcessIt() > is called. > > ProcessIt() > > LOCAL thelastname > > thelastname = "" > > IF NOT EMPTY(THISFORM.Text1.Value) > thelastname = ALLTRIM(THISFORM.Text1.Value) > > IF [?] $ thelastname OR [/] $ thelastname ; > OR [\] $ thelastname OR [(] $ thelastname ; > OR [)] && Obvious error here (unless you're tired and didn't > catch it...) > MESSAGEBOX("Invalid input.") > ENDIF > ENDIF > > * Just for grins... > IF ")" > MESSAGEBOX("Invalid input.") > ENDIF > > If you type this code into the method and save the form, the auto-compile > feature won't complain. But this is obviously bad syntax, as you can find > out if you try to run the code in the command window. You'll get a data > type mismatch error. > > I'm used to auto-compile not detecting errors in .prg-based code unless I > go through the contortions necessary to invoke Intellisense. I've come to > expect better behavior in SCX and VCX methods though. > > Still, I was aware that even in an SCX form the auto-compile can't detect > data-type mismatches involving the unambiguously-defined contents of > variables--though that surprises me since the command window will do so. > > But I didn't realize the auto-compile can't detect a data-type mismatch on > a comparison expression involving a string literal. > > Nor will the full compile of an executable containing this error. > > This little oddment cost me three hours of debugging. It's weird enough > that it caused the obliteration of several levels of stack trace in my > executable at run time. The stack trace data from ASTACKINFO() didn't show > up in my error handler's log output until it was well past the point of the > error and into my shutdown routine. Took me forever to find the source of > the error. > > Any comments? > > Thanks. > > Ken Dibble > www.stic-cil.org > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAFuU78fXwvaYG+gsD_DWdYfV=CdzQ=mjd2ul_qhx3muq+-o...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
