Is this a bug?

Doing this in an empty project:

  dim myIntProperty as integer
  dim myStrProperty as string = str(myProperty, 0) // wrong, it should be str(myProperty, "0")

now this should be a syntax error or mismatching parameter, butXojo (2014r3.2) says:

There is more than one item with this name and it's not clear to which this refers.

Recently I’ve seen this error a lot, often in places where it doesn’t seem to apply (like your example). I think something must have changed in the compiler because the usefulness of the error messages has decreased when there are problems with function signatures.

See, I believe the opposite is true, in general. The error messages have been more instructive in the new releases. In this case, however, it is less than helpful. What we don’t know is if there are some internal methods for str that use two integer parameters. If there is, then the message is 100% legit.

In all my years of Xojo experience I always use the Format function rather than use str with the format. Frankly I was surprised it had this ability. Anyway, using Format is definitely more explicit when reading it than using Str and passing in the format. Just my two cents for reading my other peoples code for years.

FWIW, I would submit this very example via Feedback. Perhaps there is a bug in the compiler feedback mechanism that can tighten down this sort of ambiguity. If you don’t submit it via Feedback it may never be changed.

I just got that message because I was going to pass asc(string) to msgbox, instead of str(asc(string)).

Previously, it would have said “Parameters are not compatible with that function”. Much clearer.

I have gotten this when I cut/paste a method signature and end up with

FUNCTION myfunction(x as integer, assigns y as integer) as integer

where the return value should not have been there… this happens when I overload a function to make it similar to GET/SET

FUNCTION myfunction(x as integer, assigns y as integer)
FUNCTION myfunction(x as integer) as integer

would be the correct signatures

Using Str may be better than Format when you want to save formatted number values without them also being localized, such as when storing an internal value in a database column. The ability to provide a format with Str was added in 2011 Release 1.

FWIW, Str with a format string is essential for interacting with the web framework because javascript expects periods as the decimal separator. If you use format, errors abound.

[quote=165157:@Bob Keeney] What we don’t know is if there are some internal methods for str that use two integer parameters. If there is, then the message is 100% legit.
[/quote]

I’d say that if str() had an overloaded version I should be able to use it. And if I can’t use it, it should not get confused.

I don’t disagree with that. :slight_smile:

Building an example project for feedback, I found another weirdness with str()

// This wrongly compile and set myStrProperty to “myIntProperty”
dim myStrProperty as string = str(“myIntProperty”) // wrong, it should be str(myIntProperty)

<https://xojo.com/issue/38113>

[quote=166023:@Massimo Valle]Building an example project for feedback, I found another weirdness with str()

// This wrongly compile and set myStrProperty to “myIntProperty”
dim myStrProperty as string = str(“myIntProperty”) // wrong, it should be str(myIntProperty)

<https://xojo.com/issue/38113>[/quote]
That has always worked. Calling str() on a string is allowed and basically doesn’t do anything (that I can tell).

Str takes a variant as its first parameter
So passing a string is perfectly legal although maybe not sensible

[quote=166104:@Norman Palardy]Str takes a variant as its first parameter
So passing a string is perfectly legal although maybe not sensible[/quote]

Would be nice to have this written in the LR.
It actually says “Numeric, Boolean, Date, or Color” and this lead to think there are overloaded methods.
Also, the hint given by the IDE it’s limited to suggesting the first form, when there are overloaded methods.