Operator/operand type mismatch

[T17Rax]

Hi,

fulln = fullname[b]
spent = Totals(spent) + "fulln: "[/b]
eMessageText = "fulln: " + spent
totals = MESSAGEBOX(eMessageText)

The bold line is telling me there's the operand/operator type mismatch.

Fullname field is character.
Totals field is numeric.

(spent) is being called from another PRG which literally says:

PARAMETERS total
spent = total

.

I don't understand it at all.
The key of the code is trying to get two fields to display together in the messagebox.

Cheers Guys,

Vibrantseeker.


A conclusion is simply a place where you got tired of thinking.

 

[David Higgs]

Fullname field is character.
Totals field is numeric.

You can't add "character string" and a "numeric value", you need to convert the numeric to character and then add the two character strings.

Regards,
David

 

[Mike Lewis]

This is a very basic error. You clearly need to familiarise yourself with the fundamental facts about data types.

This specific error is caused by the fact that you are trying to concatenate a numeric value with a character string. You could fix it by doing the following instead:

[tt]Spent = TRANSFORM(Totals(spent)) + "fulln: "[/tt]

But be aware that, after executing the above line, Spent will itself be a character string. If you pass it to your Total function again, you will get an error if the function is expecting a numeric.

Rather than just copy and paste the above code blindly into your program, you would do better to read up on the basic concepts about data types. This is such a basic topic that you won't be able to go anywhere in VFP - or anyother programming language - until you understand it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[T17Rax]

I understand that it's a basic error as I have seen it many times before with REPLACE and SET FILTER TO queries and realised it was something to do with the type of data (hence mismatch) but it was trying to get the two types together into a message box, which was the problem. I had tried VAL() where the numeric field was, but it wasn't doing the task I wanted it to do. TRANSFORM() I hadn't tried I must admit but with plenty of Google searches to try and find out how to convert data types, I must say TRANSFORM() never showed up once.

I try not to copy and paste because Im eager to learn from others as much as I can. Copy & Paste is really just cheating if you don't understand code. I may as well ask you to write the prg otherwise lol.

I do agree with what you're saying mike but I'm trying to advance forward with ideas, teaching myself about the programming and how to program in VFP and unfortunately, I don't have much access to resources such as demonstrations and tuitions to show me where things go wrong and what you can and can't do with VFP. A lot, if not all of what I learn about vfp comes from experience and I've always said that the help I receive from people on here is greatly appreciated.
So I do apologise if what I post appears to come across as basic errors, I'm just trying to learn haha.

A conclusion is simply a place where you got tired of thinking.

 

[Mike Lewis]

VibrantSeeker,

I hope I didn't give the impression that this was in any way a "stupid" question, or that it is one you shouldn't have asked. That's certainly not the case. It's just that the problem goes deeper than this particular error message.

You said that your tried "plenty of Google searches to try and find out how to convert data types". I'd suggest that that is a bad approach. The chances are that all you found were forum posts by other people who had similar - or totally different - problems. Even if you found some specific code that you could use, just copying that code into your program does not help increase your understanding.

It would be much better if you spent some time with the VFP Help file. For example, you said that you tried using the VAL() function. A glance at the Help file would tell you that that function converts from a string to a number - the opposite of what you want to do. The "See also" section of the topic would have directed you to STR(), which does exactly what you want.

In this case, TRANSFORM() is an alternative to STR(). I admit that, if you didn't know the existence of that function, then you wouldn't have found it by looking up VAL(). But if you look at the topic named Functions, the second item is a list of data conversion functions, which include VAL(), STR(), TRANSFORM(), and several more.

Anyway, I hope this particular problem is solved now - and also that I haven't put you off posting these basic questions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Right, Mike.

For what it's worth, I almost never use Str() any more. My default is Transform() because it'll handle any data type you throw at it unless I need to enforce a specific length, in which case I'll use Padl(), Padr(), or Padc() for exactly the same reason. Str() is from a different era, when it was the only choice.

Str() actually caused many buggy applications back in the day because of the "optional" (not really) 3rd parameter. Everyone said "it defaults to a length of 10". That's OK, as far as it goes. What happens in an index expression where some values are longer than 10 and some aren't? It's an inconsistent key length, which caused flaky behavior.

These are the kinds of conceptual things a person needs to learn rather than "please fix this line of code".

 

[T17Rax]

Hi mike,

Sorry you haven't put me off posting anything further.
I'll take your advice in using the help file and not to research the internet as often for an answer to a particular problem. Many times before the results returned haven't done me any favours at all.

I apologise once again for the misunderstanding. But as I always say, I'm sure I'll be back!

Many Thanks,
Vibrantseeker.

A conclusion is simply a place where you got tired of thinking.

 

[Olaf Doschke]

Your funciton definition is not having a RETURN statement, therefore it returns .T., as that always is the implicit RETURN, if you don't program one:

PARAMETERS total
spent = total 
[COLOR=#888A85]RETURN .T.[/color]

I just added the RETURN .T. as "ghost line". If you don't have a return before it, that's what any function, procedure or also method and a whole prg file returns to a caller.

What this function does before returning .T. is setting a private variable spent, to whatever was passed in as parameter named total, and this spent variable is immediately released again, if it doesn't preexist before calling the function, so that is a prerequisite of using the function. Otherwise the function is very useless, though it doesn't error in that case. It then creates the private variable spent, as it doesn't exist, but immediately releases it, as it returns and at that stage all local variables and all private variables created at this stack level are released.

As a short test simply execute this:

? total(1)
? spent && will error!
spent=1
? total(2)
? spent
function total()
  parameters total
  spent=total

This will print .T. as the result of total(1), then error with Variable 'SPENT' is not found. Answer with IGNORE and it'll continue and print .T. once more for the second total() call and 2 for the spent variable. So you see what I said earlier, in the first call the spent variable shortly existed , but was released, before the test code printed it. In the second call it existed set to 1 and is set to 2, still exists and so was changed by the function.

This function does not total given values at all, it just echoes them in the specific variable spent, which must be predefined, though. I don't know who got this idea and how it should help you, but it's clear your usage fails, as it always returns .T. and you try to add .T.+"fulln:" and that errors, as you can't add a boolean/logical type value and a string. Even others failed to see this and said your erroring code line would add a numeric value to a string, no it doesn't. This just shows just reading code leads to wrong conclusions and even just executing code as it is doesn't give you a chance to see what is wrong. In case other code is called, you need to incorporate it and test it.

You can always see what some function does and returns by using it out of the context of non functioning lines, simply call it itself via some simple test code. As you do so you see this function returns .T. and you can most probably understand that a string can't be added to this, for example. Normally code is having much more lines and in that case it's best to even just execute it in "slow motion" line by line in the debugger. A break point or SET STEP ON will start the debugger and there you can use F8 to execute just one line or use some of the toolbar tools. In short: Learn how to use the debugger, it helps you understand code. It's most often some earlier code leading to an error and not just the line causing the error message.

Bye, Olaf.

 

[dmusicant]

This is interesting. I've been in the habit of using STR() but indeed it does get complicated in that you have to indicate how many decimal places you want, also how long a character string you want returned. I have seen the TRANSFORM() function used by others but never had a look at it until diving into this thread a few minutes ago. So, I played around with the command window entering the following:

?STR(10.125)
?TRANSFORM(10.125)
?TYPE(TRANSFORM(10.125))
?TRANSFORM(10.125)+' what a concept'

The answers were:
10
10.125
N
10.125 what a concept

What I don't understand is the N. Why isn't that C? I'm having trouble finding the TYPE() function in VFP help!

 

[Olaf Doschke]

Why having trouble finding the TYPE() function reference? If you search TYPE there is a large result list, but you can sort it by Title, then find "TYPE() function". Also the VFP language reference has tha main nodes of Functions and Commands. and TYPE() is a function, so you find it in that list. Googling "VFP TYPE()" has the help topic as first search result for me.

There is a big difference between TYPE(x) and VARTYPE(x). TYPE(x) is about the same as VARTYPE(EVAL(x)), so TYPE("10.125") is N. Type needs a cExpression parameter, if it would work as you think it would always return "C", as you can only pass in character values.

Bye, Olaf.

PS: Why I said "about the same":

Create Cursor crsTest (iID INT NULL)
Insert into crsTest Values (.NULL.)
? Type("iID"), Vartype(Evaluate("iID")), Vartype(iID)

So eg TYPE gives the type of a field, even if you check a record having .NULL. as it's value.
As a side note: Neither TYPE nor VARTYPE ever return "I", though. The point is, TYPE(x) does not literally do the same as VARTYPE(EVAL(x))

Bye, Olaf.