Unknown Method in SOME STVs?

[tmiranda]

Gents,

I've run into a problem that I just can't figure out. I'm using one of pluckyhd's methods that is in his flux.jar file. (flux_api_HasPropertyElement()) When I use the method from one STV it works just fine. When I use it in another STV I get an unknown method error.

I checked spelling numerous times, I deleted the action widget and rekeyed it, and I even copied the action widget from the working STV to the non-working STV. Nothing helped.

Why, on the same server, would I get an unknown widget error from one STV but not another? I just don't know what else to try at this point.

Thanks,

Tom

[jphipps]

Are you passing the same parameter types in both cases? If for example a method is setup as method(String) and you call it with method(int), you will get a method not found.

Thanks,
Jeff

[tmiranda]

Jeff,

I looked at the parameters and they are the same

Tom

[tmiranda]

Jeff,

I looked at this again and you are correct. The method was expecting a string and I passed it an int. I thought the int would be converted but it was not.

How do I convert an int to a string? java_lang_String_toString() does not seem to be the answer.

Tom

[MeInMaui]

Try

Int + ""

This will convert the Int to a string.

Aloha,
Mike

[stuckless]

Originally Posted by tmiranda

Jeff,

How do I convert an int to a string? java_lang_String_toString() does not seem to be the answer.

You can also use, java_lang_String_valueOf(), which will convert a value (int, float, etc) to a string.... but Mike's way is a lot less typing

[GKusnick]

Originally Posted by stuckless

...but Mike's way is a lot less typing

Less typing is not the point. Good programming strives for clarity, not minimal keystrokes. A line of code gets typed just once, but read many times. So it's worth a little extra effort to make sure the meaning will be clear to the reader. The + "" shortcut does not (in my opinion) serve this goal, since you have to know how the trick works to understand what's going on.

The clearest and most direct way to convert an int to a String is with java_lang_Integer_toString(). It's pretty hard to mistake the meaning of that.

[MeInMaui]

Well I never said I was a good programmer.

[tmiranda]

Thanks to all for helping

[koan00]

You should be able to use the Integer object type as well:

java_lang_Integer.toString(int)

Conversions, widening, etc usually wont happen for numeric types to strings: http://java.sun.com/docs/books/jls/s...sions.doc.html

Autoboxing (1.5+): http://java.sun.com/j2se/1.5.0/docs/...utoboxing.html

[GKusnick]

Originally Posted by koan00

Conversions, widening, etc usually wont happen for numeric types to strings: http://java.sun.com/docs/books/jls/s...sions.doc.html

Yes, but we're talking Studio expression code here. Argument evaluation and conversion is done by the SageTV expression evaluator before the method is called, so the Java conversion rules don't come into play. Sage has its own rules for type conversion and method lookup, which is why the int + "" trick works.

[PLUCKYHD]

sEnse it I my coding I will comment. Gregs method is the way I would do it.

That being said do you need integers stored? If so I can add some overrides in java to accept your integer and return an integer so you don't have to convert it back and fourth in your stv.

Just let's me know sorry I was late to respond was away today.

[tmiranda]

I used the java_lang_Integer_toString and that worked just fine.

Plucky, I'm not sure what you mean. I'm using your flux_api_Has/Set/RemovePropertyElement methods to store a list of MediaFile IDs. I need to store data that allows me to uniquely identify specific MediaFiles and this seemed like the best way to do that.

If you have a better way to store data that identifies unique MediaFiles I'm open to suggestions.

Tom

[PLUCKYHD]

Originally Posted by tmiranda

I used the java_lang_Integer_toString and that worked just fine.

Plucky, I'm not sure what you mean. I'm using your flux_api_Has/Set/RemovePropertyElement methods to store a list of MediaFile IDs. I need to store data that allows me to uniquely identify specific MediaFiles and this seemed like the best way to do that.

If you have a better way to store data that identifies unique MediaFiles I'm open to suggestions.

Tom

are u using getmediafileid and getmediafileforid for storing and using the results. If so you would be better served by getting and storing integers instead of strings in the call of ours you are using. I was just offering to make that possible with the call vs having to do the conversions in studio.

[tmiranda]

Yes I am using those methods (GetMediaFileID and GetMediaFileForID) and I am using your api to store the ID values. The problem I ran into was your api's did not work when I tried to store the ID's directly (because the IDs are integers). Converting the IDs to strings and then storing them with your api's worked.

I am now looking into what happens when I read the values back in using your api's. I'm not sure if they will get converted automatically back to integers or if they will be strings and I need to use java_lang_Integer_decode() to turn them back into integers.

I hope that makes sense. In any case, your api's are easy to work with and do a great job. I just need to understand more about java. (I never would have guessed that passing a wrong parameter to a method would generate an "Unknown Method" error. That makes no sense at all to me.)

Tom

[PLUCKYHD]

Originally Posted by tmiranda

Yes I am using those methods (GetMediaFileID and GetMediaFileForID) and I am using your api to store the ID values. The problem I ran into was your api's did not work when I tried to store the ID's directly (because the IDs are integers). Converting the IDs to strings and then storing them with your api's worked.

I am now looking into what happens when I read the values back in using your api's. I'm not sure if they will get converted automatically back to integers or if they will be strings and I need to use java_lang_Integer_decode() to turn them back into integers.

I hope that makes sense. In any case, your api's are easy to work with and do a great job. I just need to understand more about java. (I never would have guessed that passing a wrong parameter to a method would generate an "Unknown Method" error. That makes no sense at all to me.)

Tom

They will be returned as strings and have to be reconverted to integers. That is why I was offering to modify the call to accept and return integers to make it easier on you

"Unkown Method" simply is because integers and strings are completely different and currently the java coding only accepts strings not integers.

[GKusnick]

Originally Posted by tmiranda

(I never would have guessed that passing a wrong parameter to a method would generate an "Unknown Method" error. That makes no sense at all to me.)

Java allows method overloading. You can have m(String) and m(int) and those are two different methods. It decides which one to invoke based on the argument type. So if all you have is m(String) and you try to pass in an int, it will tell you "unknown method" because it couldn't find a method called m that takes an int. It's not that you called m(String) with the wrong argument type; by definition that's not possible. What happened was you tried to call a method m(int) that doesn't exist.

[tmiranda]

Greg, Thanks for the explanation. That makes sense now. Is there anything special I need to do to use java_lang_Integer_decode() to convert a string to an int or is the method as straight forward as it seems?

Plucky, It would be great if you could make the calls accept integers or strings. (Or a new method for integers, whatever is easier.)

Thanks,

Tom

[stuckless]

Tom, it gets even more confusing.... using java_lang_integer_decode() will decode an integer into an Integer object, which is not an "int". Depending on your java version you could still end up with a method not found.

In phoenix, I will sometimes create the method signatures that accept an Object, then I determine the type inside the method. This is not ideal programming behaviour, but it saves me from creating a bunch of overloaded methods for each type, int, long, float, string, etc. This viloates greg's "Good programming strives for clarity" approach, but it makes the code more "user friendly" to non developers that don't want to deal with auto-unboxing and type conversions. And if you can read method paramters and/or javadoc, then you still get 'clarity'.

ie, a method that requires an int, might accept look something like this...

public String GetElementAt(Object index, String[] data) {
    int idx = TotInt(index); // assume you have a ToInt() utility method that return an int
    return data[idx];
}

Sometimes there's a fine line between striving for clarity and making an API that is just easy to use...

[PLUCKYHD]

Originally Posted by stuckless

Tom, it gets even more confusing.... using java_lang_integer_decode() will decode an integer into an Integer object, which is not an "int". Depending on your java version you could still end up with a method not found.

In phoenix, I will sometimes create the method signatures that accept an Object, then I determine the type inside the method. This is not ideal programming behaviour, but it saves me from creating a bunch of overloaded methods for each type, int, long, float, string, etc. This viloates greg's "Good programming strives for clarity" approach, but it makes the code more "user friendly" to non developers that don't want to deal with auto-unboxing and type conversions. And if you can read method paramters and/or javadoc, then you still get 'clarity'.

ie, a method that requires an int, might accept look something like this...

public String GetElementAt(Object index, String[] data) {
    int idx = TotInt(index); // assume you have a ToInt() utility method that return an int
    return data[idx];
}

Sometimes there's a fine line between striving for clarity and making an API that is just easy to use...

Sean,

Thanks for that idea never thought of doing it that way vs an overload. Have always used overloads...I agree it may not be ideal but would be loads easier to understand and like you said saves allot of coding.

Tom,

Sean is correct you don't want to integer_decode but rather java_lang_Integer_parseInt(String) to get it back to an integer.
I would also recommend a basics on java book or reading some of the great material sun has posted. It has helped me loads. Like Sean told me when I was starting out you got to at least know the basics and knowing that will extend your stvi's so much further, plus coding in a IDE like netbeans is loads easier than in studio for everything IMHO

Also I would load up the old flux api (has been merged with ortus) and add a integer method for you and send you the jar.