Operator/operand type mismatch on first run only

[audiopro]

I have this code in the click event of a button which errors but only on the first time it is run, after that it works just fine.
This is a cut down version of a much more complex DOCASE arrangement but errors in the same way as the full version
When run, Field - ITEM (chr 7) is checked first and then Field COST (float) is checked and the error occurs
I am sure there will be comments about the code but as it is holding the job up, I will risk the wrath of the code police

NUMOFCON = THISFORM.MAINCON.CONTROLCOUNT
TESTED = 0
PASSED = 0
N=''
TV=0
v=''
FAULT=''
THISFORM.CODEIS.VISIBLE = .F.
WEBTRIG=ALLTRIM(THISFORM.MAINCON.WEB1.VALUE)
W = IIF(LEN(WEBTRIG) > 0,'WEBON', 'WEBOFF')
FOR NWHICH = 1 TO NUMOFCON
	TESTED=TESTED+1
	IF THISFORM.MAINCON.CONTROLS(NWHICH).CLASS = 'Standardfield' OR THISFORM.MAINCON.CONTROLS(NWHICH).CLASS = 'Standardmemo'
		BX=THISFORM.MAINCON.CONTROLS(NWHICH)
		A = 'GOOD'
		N=UPPER(BX.NAME)
		DO CASE
			CASE N = 'ITEM'
				A = IIF(LEN(ALLTRIM(V)) > 0,'GT', 'BT')
			CASE N = 'COST'
*******************************************************************
* Error here
				A = IIF(BX.VALUE > 0,'GT', 'BT')
*******************************************************************
		ENDCASE
	ENDIF
NEXT

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

If that marked line errors, what error do you get? Is it 'Operator/operand type mismatch'? Is it 'Property Value is not found'? What is the error?

Bye, Olaf.

 

[Mike Lewis]

Keith,

At the time that the error occurs, what control is BX refering to? I suspect it's a control that does not have a Value property, such as a label or a shape. If that's so, that would explain the error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, I still would need to knwo the error number/message. It can also be a control WITH a Value porerty, but with another type than numeric. BX will be of class 'Standardfield' or 'Standardmemo', if those classes are not based on controls with a value, Mike of course has a vital point.

Bye, Olaf.

 

[Olaf Doschke]

For example, if the cost field is bound to the COST control (BX.NAME='COST') then it could still be NULL and cause the error.

Bye, Olaf.

 

[audiopro]

Error number is 107
This line causes the error.

A = IIF(BX.VALUE > 0,'GT', 'BT')

IF ISNULL(BX.VALUE) is ignored
IF ISALPHA(BX.VALUE) causes an error

Now I remember why I used to get frustrated with VFP


Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, and what is the value? If ISNULL doesn't react it's not NULL, but it's also not a numeric type. If ISALPHA errors, it's not character, start the debugger at that point and inspeact BX in the LOCALS windows, you can expand a treeview with properties of BX and check the value, you might also add BX.VALUE in the Watch window.

Or inspect VARTYPE(BX.VALUE)

Most important: If BX should be bound to a float field, but the control value is neither NULL or numeric, then double check, whether you set BX.Controlsource correctly to the COST field. A field can't be a type differing from it's core type or NULL, your control then is unbound.

Bye, Olaf.

 

[Olaf Doschke]

As a side note: Look at intellisense

ISALPHA() displays a tip text decribing the parameter you pass in as cExpression. The c here stands for character, no other type is allowed as parameter type of the ISALPHA function, IS... don't test a certain type, they test different things, but not a type, some of them expect variant/any type of parameter, like ISNULL(), which has the parameter of it defined as eExpression, and herre e stands for anything, it's an untyped expression. ISBLANK() also is for all types of parameters by the way, but neither NULL, ALPHA nor BLANK are types. ISBLANK checks the blank state of fields only, ISNULL checks for NULL only ISAPLHA checks, whether a character (and only the first character of a string) is in the alphabet (including language specific variants).

Operators like > or = or $ work on same type on both sides only, and that doesn't differ in VFP from vary many other languages.

your code has no error, as it expects a float type value, you have to find out why the value of the COST control is not numeric nevertheless. The error is somewhere else in table design, controlsource setting or anything else making the value a not allowed type for checking against >0.

Bye, Olaf.

 

[JRB-Bldr]

Have you put a SET STEP ON (or Breakpoint) at the point where you get your: * Error here so that you might actually 'catch' the problem on the First Run?

If so, then you would be able to examine the BX.VALUE (either by doing an Interactive Browse through your Command Window or using the Debug Window to display the value) to see what is causing the problem.

Then you would have to 'back-track' into your code to find out where this value was coming from.

Or you could do the same just before your: FOR NWHICH = 1 TO NUMOFCON and single step through the Loop and watch BX be populated to see if that might be the problem.

Good Luck,
JRB-Bldr

 

[audiopro]

This does not make any sense!
I have spent ages doing all the basic checking stuff and this is the confusing conclusion

Trace window says bx.value is a character = ""

wait window bx.value

throws an error

wait window str(bx.value) timeout 1

displays 0 so it must be numeric

A = IIF(BX.VALUE > 0,'GT', 'BT')

throws an error so it isn't numeric.




Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Keith,

Sorry if this sounds obvious, but are you sure you're putting your Wait windows inside the correct CASE branch (that is, in CASE N = 'COST')? In general, tracing the code is more satisfactory than using Wait windows, because you can see the value at the precise position in the code, and watch it as it changes.

Also, I'd still like to know what type of control BX is. You referred to it in your first post as a field, but it is in fact a control. The point is that the Value property behaves differently in different types of control.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

The way you are showing approaching your debug, we have no idea what BX is at the time of the error.

Maybe when the error is thrown, it has NO VALUE and is therefore "expression could not be evaluated"

If you use one of the suggested Interactive Debug methods you will have better 'visibility' of what is being populated with what and how it is being evaluated at each step of the code.

Good Luck,
JRB-Bldr

 

[audiopro]

Solved it, sorry for dragging you round the houses guys.
The field type of COST was set to text in the sample table I am using, when I scattere the memvars the field's value was set to "" and I was then checking to see if "" was > than 0. The other float fields are correctly set so worked no problem.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Glad you got it, that's what I was suspecting. Something was wrong with the controlsource, though only in the widest sense of the field being the wrong type.

Nevertheless about your debugging session:

1. wait window bx.value
That does error? though bx.value was type string? Where did you do that?

a) In the watch window? The Watch Window cannot run commands, it only evaluates expressions.

or

b) In the command window? In the same VFP session that is suspeended? bx.value and other variables and even THIS can run in the command window, but only in the context of the debugger suspending code.

2. wait window str(bx.value) timeout 1 displays 0.
Again: Where did you do that, did bx.value change already because you changed it in the debugger?

3. A = IIF(BX.VALUE > 0,'GT', 'BT') throws an error of course for type string.

It won't matter much for this fixed bug, but you should learn a bit more about debugger ussage. If you play around during suspend, use the datasession windows, switch the active workarea for example, that can already influence bx.value, as it's still the live value of that control.

Bye, Olaf.

 

[audiopro]

All the wait windows were within the faulty case statement.
With hindsight, the value of BX.VALUE as "", in the trace window, was wrong and I should have spotted that it wasn't numeric. Also once it has been assigned a numeric value all was well, again more clues which I should have spotted. Fixing bugs is easy once you know what the bug is.

It hasn't been the easiest of weeks as in addition to the day job, I have also been wrestling with a new computer with WIN8 on it. All kinds of things have been happening and distracting me from the job in hand. Glad to say all appears to be working now and adding additional RAM to the box has made a real difference.

Keith

http://www.studiosoft.co.uk