object is not defined but uncatchable

object is not defined but uncatchable

• Findekano

  Thanks, it is a neat idea but could you explain to me why my code does not work
  
  

• mkamka

  Why do I get an error message that SelectedItem does not evaluate to an object, then

  Because it is NULL. The error message is phrased badly.

  
  
  

• David_H

  Thanks, but

  "The TreeView's SelectedItem property is always an object reference" does not seem to be the case (in my case at least). Why do I get an error message that SelectedItem does not evaluate to an object, then

  
  
  

• gbabu17

  This action (search) needs TreeView.SelectedItem.Text

  Ammend your code as follows:

  LOCAL loNode

  *** see if we have a node selected

  loNode = Thisform.oTree.SelectedItem

  IF VARTYPE( loNode ) # 'O'

    SET PATH TO "C:\VFP_Projects\Forms\"

    DO FORM msgForm1 WITH 3,"","No DIRECTORY SELECTED","CLICK DIRECTORY BOX","","","sound20"

    RETURN

  ENDIF

   

  
  
  

• Paul Czywczynski

  Hi Alex

  >> Why do I get an error message that SelectedItem does not evaluate to an object, then

  Your original code was, I think,

  IF TYPE ("THIS.Parent.Parent.Ole_TreeView.SelectedItem") <> "O" OR ;
  TYPE ("THIS.Parent.Parent.Ole_TreeView.SelectedItem") == "U"
  exiting = .T.
  ENDIF

  The problem is that TYPE() returns "O" for an object reference, even after that reference is actually NULL. In other owrds once an object has been there, TYPE() assumes that it exists. The only way to avoid this problem is to either:

  Use VARTYPE() (as Marcia suggested) because that does diffferentiate. It returns "O" if the reference is a valid object, but "X" if it is a reference to a NULL.

  OR

  Use TYPE() but test for a specific property on the object ("Name" is a popular choice for this) rather than just the object itself. This way you will get "U" back if the object is NULL.

  OR

  Use ISNULL() to check that the object is not NULL - so the test becomes
  IF TYPE ("THIS.Parent.Parent.Ole_TreeView.SelectedItem") <> "O" AND NOT ISNULL(THIS.Parent.Parent.Ole_TreeView.SelectedItem)
  This was the 'recommended' method in VFP 3.0 and 5.0 and VARTYPE() was introduced specifically in VFP 6.0 to obviate this rather cumbersome test.

  
  
  

• Andrew XYZ

  but could you explain to me why my code does not work

  IF TYPE ("THIS.Parent.Parent.Ole_TreeView.SelectedItem") <> "O"

  This is always going to evaluate to true. The TreeView's SelectedItem property is always an object reference, therefore its type is always "O". However, when there is no item selected in the TreeView, its value is NULL.

  TYPE ("THIS.Parent.Parent.Ole_TreeView.SelectedItem") == "U"

  This will never evaluate to true. The TreeView DOES have a SelectedItem property, its type is "O".

  The code that I gave you uses the VARTYPE() function which also has the benfit of being faster than TYPE(). If the value of the property you are checking with VARTYPE() happens to be NULL, VARTYPE() returns "X", not "O".

   

   

   

  
  
  

• darth24_01

  ISNULL () finally solved the problem. It was the last successful test in a series of failures. EMPTY() did not work on an object that is .NULL. !! It is strange. I'll keep it in mind a possibility of testing for a specific property though in the future.

  Everything you both said about the properties appear to be correct but nothing worked until I started using ISNULL ().

  Thanks, Andy. I appreciate it. Now that part of my code is secured.

  Relief!

  
  
  

• labfox

  In Visual dBase I know for a fact if cVar = NULL EMPTY (cVar) always evaluates to .T. This is why I assumed that it would work. It seems to be different here.

  Thanks to Marcia and Dave for instructive comments.

  
  
  

• ireland

  EMPTY() did not work on an object that is .NULL. !! It is strange. I'll keep it in mind a possibility of testing for a specific property though in the future.

  That is because null and empty are two different things. You can think of null as meaning "I don't Know".

  So when you test to see if something that has a null value is empty, it is like you are saying

  Is "I don't Know" empty

  The answer is "I don't Know".

  Nulls propagate.

  What are the states in which a value can exist In Visual FoxPro there are now three conditions, the value can be equal to something (.T.) not equal to something (.F.) or be in a state where its value cannot be determined (NULL). Unless you specifically test for a NULL condition, the answer to any ‘question’ involving a NULL value is always NULL Consider the following:

  luVal = NULL

  luVal > 0

  luVal = "A CHARACTER STRING"

  luVal <= DATE()

  luVal = .T.

  The value returned in every case is actually NULL An exception to this rule is provided by the TYPE() function which invariably returns a type of “L” if the value was originally defined as NULL (as in this example:

  TYPE("luVal") && Returns ‘L’

  However if a value was defined as some other data type and has subsequently acquired a NULL value the TYPE() function returns the original data type - with potentially catastrophic results!

  lnTotal = 100

  luVal = 10

  TYPE( ‘luVal’ ) && Type = “N”

  luVal = IIF( luVal > 20, luVal, NULL )

  TYPE( ‘luVal’ ) && Value = NULL but Type = “N”

  lnTotal = lnTotal + luVal && lnTotal = NULL - not even 100!!!

  
  
  

• zhoang

  Just to add to what Marcia already said.
  

  When Summarizing data (using a Select\Group by for example) if there is even one null value in the sum, the Final value should be Null but its not! The Nulls are ignored!

  Same with Count() the nulls are not include in the Count, even if there is no where statement excuding them!
  

  Look at this..

  CREATE TABLE c:\fox\test  ( f1 n(5,0) null)
  APPEND BLANK
  REPLACE f1 WITH .null.
  APPEND BLANK
  REPLACE f1 WITH .null.
  
  SELECT f1,count(f1) FROM test GROUP BY f1

  Its an oxymoron!!
  Dave M.

  
  
  
• object is not defined but uncatchable