The following warnings occurred:
Warning [2] Use of undefined constant SAPI_NAME - assumed 'SAPI_NAME' (this will throw an Error in a future version of PHP) - Line: 3388 - File: inc/functions.php PHP 7.4.33-nmm7 (Linux)
File Line Function
/inc/functions.php 3388 errorHandler->error
/showthread.php 116 build_archive_link
Warning [2] Use of undefined constant IN_ARCHIVE - assumed 'IN_ARCHIVE' (this will throw an Error in a future version of PHP) - Line: 3331 - File: inc/functions.php PHP 7.4.33-nmm7 (Linux)
File Line Function
/inc/functions.php 3331 errorHandler->error
/inc/functions.php 3324 build_forum_breadcrumb
/showthread.php 195 build_forum_breadcrumb
Warning [2] Use of undefined constant IN_ARCHIVE - assumed 'IN_ARCHIVE' (this will throw an Error in a future version of PHP) - Line: 3331 - File: inc/functions.php PHP 7.4.33-nmm7 (Linux)
File Line Function
/inc/functions.php 3331 errorHandler->error
/showthread.php 195 build_forum_breadcrumb






Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Function arguments and numbers
Author Message
Extreme
Grandmaster Poster
***

Posts: 1,141
Likes Given: 217
Likes Received: 90 in 77 posts
Joined: May 2012
Reputation: 20

SphereCommunity

Post: #11
RE: Function arguments and numbers
I didn't understand then...
What do you want to store and show?

STEPS BEFORE CREATE A THREAD
- Check the revisions log;
- Use the search button and use the keywords of your problem;
- Check the WIKI;
- Create a thread.
05-04-2014 10:40 AM
Find all posts by this user Like Post Quote this message in a reply
karma
Moderator
****

Posts: 178
Likes Given: 17
Likes Received: 32 in 29 posts
Joined: Jul 2012
Reputation: 3



Post: #12
RE: Function arguments and numbers
I solved the problem. I thought that a list of arguments, separated by commas, was auto-typized: if argument 1 is a string, <ARGV[0]> is treated as a string, if argument 2 is a number, <ARGV[1]> is treated as a number. So, if i passed as the second argument "12" and in the function i do SAY <ARGV[1]> it would show 0c instead of 12, because numbers are automatically parsed in hexadecimal.
Though, doing SAY <ARGV[1]> shows "12" and not "0c", so in this case argument is treated as a string and not as a number, i was wrong.
The problem lies in the LOCAL._TEXT=<ARGV[4]> in my function (5th argument is the text). If i assign the value of <ARGV[4]> to a local (tag, var, whatever), sphere automatically recognizes the type of the argument, and internally set the local to be a numeric variable, since i am passing "12". So, as numerical variables are parsed in hex, doing SAY <LOCAL._TEXT> will show "0c", both in the case i passed "12" (so it was like LOCAL._TEXT=12) and in the case i passed "0c" (like LOCAL._TEXT=0c).
On the contrary, SAY <ARGV[4]> shows "12" if the argument is "12" and "0c" if the argument is "0c". This because internally <ARGV[4]> is a string, so it have not been parsed in hex or in decimal.

To sum up, i was misled by the fact that:
Code:
[FUNCTION test]
SAY <ARGV[0]>

LOCAL._TEXT=<ARGV[0]>
SAY <LOCAL._TEXT>
.test 12 shows first 12, second 0c. The explaination is the one above.
It's like doing:
Code:
[FUNCTION test]
SAY <ARGS> //shows 12, because the argument is treated as a string and i print it out as i pass it
SAY <ARGN> //shows 0c, because the argument is treated as a number and sphere parses it in hexadecimal
I don't know if a number or a text will be passed to the function, so i cannot do SAY <EVAL <ARGN>> or SAY <HVAL <ARGN>>.

In my code i did:
Code:
LOCAL._TEXT=<ARGV[4]>
LOCAL._TEXT=<ASC <LOCAL._TEXT>>
And i got that problem, which i solved doing this:
Code:
LOCAL._TEXT=<ASC <ARGV[4]>>
(This post was last modified: 05-04-2014 07:33 PM by karma.)
05-04-2014 07:25 PM
Find all posts by this user Like Post Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)