AddProperty gives "Not a character expression" error 1

[anglepoise]

A VFP 8 application which I have been using for years and have not amended at all for nearly two months has today started throwing up Error 45 ("Not a character expression") on the following line:

= ADDPROPERTY (loObject, lcProperty, leValue)

Where lcProperty = 'aMRU[1]' and leValue = .F.

The error does not occur every time the command is executed with those parameters, but it does occur consistently at the same points within the program. It occurs both when running the code from within VFP and also when running the standalone EXE (even on another PC) even though the EXE has not changed and has never generated this error anytime prior to today.

Help!

 

[Mike Lewis]

Sounds very much as if aMRU has never received a value, so the first element will contain a logical .F.

Your best bet is to add some code to trap the error:

TRY
  ADDPROPERTY (loObject, lcProperty, leValue)
CATCH
  MESSAGEBOX(TRANSFORM(lcProperty) + " passed to AddProperty")
ENDTRY

That will tell you what the incorrect value is that's being passed. If that doesn't tell you how to solve the problem, the next thing is to set a breakpoint on lcProperty, to fire when it takes on the offending value.

Hope this helps.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[anglepoise]

Thanks Mike. Using the TRY ... CATCH ... ENDTRY method confirms that it is the value 'AMRU[1]' which produces the error.

Through google I have found a couple of instances of people having a similar problem but unfortunately no solution.

http://www.tek-tips.com/viewthread.cfm?qid=1019360

http://www.leafe.com/archives/showMsg/207157

It appears to be a bug in VFP, given that the same value is passed on several other occasions without any error. What really baffles me is the fact that the error is appearing not only when the application is run within VFP, but also when the standalone EXE is run, even though the EXE was compiled two months ago and has been in constant use since with no such errors prior to today.

I have tried running the application under VFP9 and the error does not occur so I guess the answer is to get on and migrate it (something I've been meaning to do for ages but haven't found the time!)

 

[Mike Lewis]

Anglepoise,

I'm glad my suggestion helped, but I have to say that I doubt it is a bug. The underlying problem is that the first element of the array is not set correctly. There must be some underlying reason for this. It's hard to believe that, if there was a bug which occasionally prevented a value being stored in an array element, it would not be better known. But I might be wrong about that.

Anyway, you seem to be moving forward, and if it encourages you to move to 9.0, your time won't have been wasted.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mreigler]

Perhaps modifying Mike's code slightly will provide the answer:

TRY
  ADDPROPERTY (loObject, lcProperty, leValue)
CATCH
  MESSAGEBOX("lcProperty is type " + VARTYPE(lcProperty))
ENDTRY

Mike Reigler
Melange Computer Services, Inc

 

[Olaf Doschke]

Hi,

how about the case, that this property was already added? Redefining the property might raise unexpected errors!?

IF VARTYPE(loObject)="O" AND VARTYPE(lcProperty)="C" AND PEMSTATUS(loObject,lcProperty,5)
   MESSAGEBOX("Property "+lcProperty+" already exists")
ELSE
   TRY
      ADDPROPERTY (loObject, lcProperty, leValue)
   CATCH
      MESSAGEBOX("lcProperty is type " + VARTYPE(lcProperty))
   ENDTRY
ENDIF

Bye, Olaf.

 

[mreigler]

Oops,
Now that I looked at this again, forget what I said before. Of course lcProperty is a character. It's equal to 'AMRU[1]'. Your adding an array to the object.

After a few tests in the command window setting aMRU[1] to .F., "test", 3, and not defining aMRU at all. AddProperty always worked because it just added the array aMRU as a property of the object (and it didn't seem to care if the property was already there).

I tried everything I could think of to make it fail with that error, but no luck.


Mike Reigler
Melange Computer Services, Inc

 

[anglepoise]

Thanks all for your replies - apologies for the delay in responding.

Once I discovered that the error no longer occurred under VFP9 I pretty much gave up trying to solve it and put all my effort into migrating it across (it is working fine now).

To respond to your suggestions and points: Olaf, thanks but the property had not already been added; and Mike Reigler, many thanks for trying, I am not surprised that you were unable to reproduce the error because even now the error does not occur everytime the procedure is run (with identical parameters) and it only started producing the error recently, even though the code had not been changed at all for months and the application was in constant use (I estimate that the code which now produces the error in VFP8 must be run around 1,000 times a day).

I remain baffled as to how an application which previously worked fine can suddenly start producing inexplicable errors when nothing has been changed, but as long as it works under VFP9 (albeit slower, strangely), I'm happy