I have an issue that looks like it started in 2014 Release 3. I have a project with two modules (and classes) that each overload the str() method with arguments specific to each class. Within these overloaded methods there are regular calls to str() with integer and float arguments. In release 3, these calls are calling the overloaded method instead of the internal method causing a circular calling situation resulting in a stack overflow. Release 2 and prior releases seem to work as I intended. Could this be a bug introduced with release 3 due to operator_convert changes?
To be sure that I am explaining this correctly, I have the following methods:
str(apmint) and
str(apmfloat)
where apmint and apmfloat are two classes for two new numeric types.
In the two above methods there are calls to str() with XOJO float and integer arguments.
It appears that in release 3 the str() calls with float and integer arguments are calling the str(apmfloat) overloaded method. This did not happen in release 2 and prior.
Joe, I filed a bug report. Not sure that I explained it right in the bug report but I did include a slimmed down project that exhibits the problem in release 3 and not prior versions.
Joe, when I change the offending str() methods to Global.Str() in the sample project I get “this item does not exist errors”. Is there another change needed?
Having looked at the project attached to the case, I’m a little surprised at the answer here.
The function…
[code]Function str(num as apmfloat_module.apmfloat) As string
// convert an apmfloat to a string and format it to make it more manageable (breaking it into lines of fixed length)
Return num.to_string()
End Function[/code]
… clearly has a very different signature to what is defined for REALbasic.Str().
According to the docs REALbasic.Str() takes a value param of “Numeric, Boolean, Date, or Color”, the usage of Str() within apmfloat class is definitely passing a numeric rather than apmfloat to Str() so surely the only signature match is the version of Str() outside of William’s apmfloat_module?
Is it maybe the case the framework version of Str() actually accepts more than just “Numeric, Boolean, Date, or Color” and there is simply a doc bug?
I’m certain the issue here is that it has to do with the use of STR and that there is an operator convert that takes a variant
in operator_convert there are two lines
d = num.DoubleValue
s = str(d) // <<<<<<<<<<<<<<
and
i = num.Int64Value
s = str(i) // <<<<<<<<<<<<<<<
that end up calling the modules STR since
s = str(d)
ends up being interpretted as meaning
s = Str( apmFloat.operator_convert( double ) )
and the same for the other
So when you run and press the button you end up with a stack overflow because it perpetually calls itself doing the converts etc quite dutifully & calling str which calls convert and so on …
disambiguating the use of REALbasic.Str fixes that ambiguity
Joe, Norm, thanks for the help! I changed all the instances of str() with Realbasic.str() for all cases with XOJO integer and float arguments and all is well now.
BTW, I tried to look up the Realbasic keyword in the language reference and did not find it. It this an undocumented feature or did I miss it.
Its existed for … 7 or 8 years
One of the first namespaces in the framework … hence the name
Funny - its existed so long I never even noticed its NOT mentioned in the language reference on the modules page
Go figure
[quote=152954:@Norman Palardy]Its existed for … 7 or 8 years
One of the first namespaces in the framework … hence the name
Funny - its existed so long I never even noticed its NOT mentioned in the language reference on the modules page
Go figure[/quote]
Interesting, that notion of Realbasic.str() vs str(). Where can I find out more about the Reabasic namespace methods ?