How to tell what a function is returning

[jacque]

I concede this is confusing at first. Both examples include a reference to a field. There are quotes around the stack path in the first example because all URLs need to be quoted (or put into a variable) since a slash is the division operator. Without the quotes, which force a string evaluation, LC may try to do division on the text and would throw an error.

That aside, both examples reference a field and should behave the same way. "Line 3 of fld 1" is the same as

Code: Select all

line 3 of fld id 1003 of group id 1008 of card id 1002 of stack "/home/bogs/LC-Projects..."

Long field references and short ones behave the same, assuming there's a field 1 on the current card.

But I don't think this addresses your real question. "The selectedLine" returns a chunk expression -- i.e., text -- and any operations on it will use the text in that chunk expression. This is a common way to identify which line or which field is selected, though there are specific functions for that. "The mouseloc" returns two integers, but since everything under the hood is really text, you could treat it that way and "get item 1 of the mouseloc". Some functions are specific in what they return so you don't have to parse them yourself. Check the differences between clickChunk and clickText.

This is true of selectedLine as well. If you want the actual text, you can either include the "text of" or you can use a specific function that does it for you: either "the selection" or "the selectedText".

Code: Select all

put the selection
put the selectedText

Or for mouseLoc (item 1 of the mouseLoc, item 2 of the mouseLoc):

Code: Select all

the mouseH
the mouseV

For fields (word 4 of the selectedLine):

Code: Select all

the selectedField

You might still wonder how you'd know. I think basically you need to look in the dictionary to see if the function returns a descriptive (chunk) expression or not.

[bogs]

I concede this is confusing at first. Both examples include a reference to a field. There are quotes around the stack path in the first example because all URLs need to be quoted (or put into a variable) since a slash is the division operator. Without the quotes, which force a string evaluation, LC may try to do division on the text and would throw an error.

This is exactly the problem I'm having understanding how to tell what you should be getting back. I was told the selectedLine returns a quoted value, so you can not just say, for instance,

Code: Select all

put word 3 of the selectedLine

and get the actual word (chunk) the selectedLine points out. Instead, if you use that code, you will get "of", which is what is in the text returned from the function.

I actually *did* expect the chunk to be returned from that statement, but it isn't, and as you point out in a few lines, you *do* get the chunks from other versions of selected such as the selectedText or the selection.

I haven't tested either of those yet (but will this morning) because I don't believe it will work in this situation. Here is the goal I am trying to achieve (and have already solved in a completely different manner by shunning things I obviously have a miserable ability to understand).

1. you have a field someone is typing in, which contains the caret.
2. you want to check if the word previous to the caret is part of one of several groups of words while the person typing is still typing.

If the selectedLine worked as I expected it too, this would be childs play. I should add, btw, it was still childs play the way I finally arrived at, but, not quite as simple.

That aside, both examples reference a field and should behave the same way. "Line 3 of fld 1" is the same as

Code: Select all

line 3 of fld id 1003 of group id 1008 of card id 1002 of stack "/home/bogs/LC-Projects..."

Long field references and short ones behave the same, assuming there's a field 1 on the current card.

But I don't think this addresses your real question.

Well, that (in bold) is the problem, really. If I looked in the debugger returns, and saw the selectedLine return (in quotes) "line 3 of field 1", I would immediately have known I would need to put "the value of " or similar to get what it is supposedly pointing too. Instead, all you see is

line 3 of field 1

in the debugger, which looks just exactly as it would if you typed it out yourself long hand in code. Why would you not expect to be able to use it as a short cut to typing it out long hand? I dunno, to me it seems a loss.

The selectedText does not work this way, you get whatever is selected returned, in other words, you get the chunk expression. This is what I expected to see from the selectedLine, the chunk expression, i.e. the last word of the selectedLine, not the last word of what is returned from issuing the command.

You might still wonder how you'd know. I think basically you need to look in the dictionary to see if the function returns a descriptive (chunk) expression or not.

I did, and it says in there that the selectedLine returns a chunk as you point out, which is what I would have thought (at least, what I think based on reading the description of chunks here, or even in the glossary), but it does not in fact return a chunk unless you modify it with a pre-qualifier or descriptor, or unless you use specific items of the return such as writing it like this

put the last word of line (word 2 of the selectedLine) of field "this field"

which seems really redundant to me, as the selectedLine has all the information you already need returned but in an unusable format for direct manipulation, none of which you need for the selectedText, for instance, which returns the actual selected text, which is what I would have expected it to do.

Like I said earlier, I probably just expect WAY too much.

[jacque]

I was told the selectedLine returns a quoted value, so you can not just say, for instance,

put word 3 of the selectedLine

and get the actual word (chunk) the selectedLine points out. Instead, if you use that code, you will get "of", which is what is in the text returned from the function.

I actually *did* expect the chunk to be returned from that statement, but it isn't

I'm not sure who said the the selectedLine would be quoted; it isn't, though it's a string. Just to clarify, the "chunk expression" refers to the format of the return value, not the text of the field. Whenever the dictionary refers to a chunk value, it means the format of the returned value. If it meant you'd get the text of the target, it would say the return value is text.

I do understand the confusion though. I guess it's just something we all have to learn and it does stick eventually. Knowning that many of these chunk values also have companion text functions helps.

[bogs]

I'm not sure who said the the selectedLine would be quoted; it isn't, though it's a string.

My bad, I confused one of SparkOut's answers and translated it (in my feeble brain) as 'quoted'. What a doofus I can be!

I've only been at this a little over 3 years now, I guess I thought I would be farther along by now in my understanding of how it *should* work. Man this is depressing.

I might as well also ask, is there anyway to turn a string into a string literal? If everything the functions return are strings, and you know you want the string to be interpreted as code, for instance, is there a way to do that? Or is "value" the way that is handled most of the time (evaluating the return).

[SparkOut]

Not a doofus, I didn't word it well enough. I was trying to explain the difference in how the engine sees the returned value, ie as if it were a quoted literal string, but didn't state properly that it actually was not returned with quotes and all. Sorry.

I think you can extract the text of such returned values with "the text of" quite readily, which may be the evaluation that works sometimes, especially if you are making a constructed statement with "do". But "value" is probably the most comprehensive and reliable method to resolve a given piece of ambiguous data into its evaluated, er, value. I think other languages have some similar functions, like "eval".
The engine does do an admirable job of evaluating and resolving variables and contructed strings, sometimes helped along just by wrapping in parentheses, but I don't think that's quite the same scenario.

[bogs]

You worded it fine, this was solely a case of "oculos habent, et non vident, aures et non auditis "

I've re-read both threads now, and while I can't say I understand the logic behind returning something that can't be used as it sits, at least I (think) I understand how to work around it in a consistent way.

Thanks all (who replied) for your answers.

[dunbarx]

Bogs.

I think we are near closure on this, but,

I can't say I understand the logic behind returning something that can't be used as it sits,

It CAN be used as it sits. It just can't be used as you initially interpreted it, requiring additional gadgetry to do so. The only reason I am still at this is because you misread what that function returned. Remember that it is a function, and returns an explicit value, That value simply did not quite contain the pathway forward you expected.

I know you know this, but it is not LC, or the selectedLine function itself that is somehow lacking. For me, I would simply embellish it, perhaps to the extent of a library function that I can use forever. I have a bunch of those.



Craig

[bogs]

I know I shouldn't but, what the heck hee hee.

It CAN be used as it sits. It just can't be used as you initially interpreted it, requiring additional gadgetry to do so.

I'll script this one -

Code: Select all

if (the return) requires additional wording["gadgetry"] then
	"used as sits" = false
else
	"works as advertised" = true
end if

The mouseLoc = true
The selectedLine = false

Just so you don't think the thread(s) were a complete waste, I used them as the basis for making (possibly) the simplest order of calculations calculator ever. I was so pleased with how it turned out, it will be {part of} an upcoming tutorial

inlinecalc.livecode.zip

Maybe the simplest calculator ever? I dunno...

(1.96 KiB) Downloaded 166 times

As a side note, I'm going to start using 'do' more

[dunbarx]

Bogs.

Since you are such a nice guy, I will only say that each function works as advertised, so caveat emptor.

You have no problem accepting that the result of a function like "the mouseLoc", which returns something like "100,100", can be used "as it sits". Well, it can indeed, as long as the task it is set requires, explicitly, two numbers separated by a comma.

But the string returned from a function like the selectedLine does not. It is descriptive of the selectedLine, but really could care less about the contents of that line. It still sits just fine. You simply read, into the name of the function itself, more than that function was designed to deliver.

I assume your beef is that you assert this is inconsistent at best, and stingy at worst.

Craig

[jacque]

As a side note, I'm going to start using 'do' more

You aren't allowed to do that until you can succesfully parse and understand the following.

Be careful! There are some things you can do with 'do' but can't send with
'send'. Also, as I recall, not all you can 'call' can lend itself to 'send'.
I've seen things that 'do' did but sent d'n't. Also, a sending pending is not
the same as a do doing since a pending sending is not done as is a done 'do'.
So, unless I need pending, I do do instead of sending a send.

-- Dar Scott
6/14/16

[bogs]

Since you are such a nice guy...

Whoa, what ?! Who told you that? they were LYING!@

I assume your beef is that you assert this is inconsistent at best, and stingy at worst.

Wheres the beef ?

I have no beef, per se, I just see no consistency in the way returns get evaluated.

As you say, the return of 'the mouseLoc' works as it sits because you can use the 2 integers separated by a comma to determine where the mouseLoc is.

as long as the task it is set requires, explicitly, two numbers separated by a comma.

Well yah, I sure wouldn't be looking for information about 'the absolute file path' from the mouseLoc heh. Lets go another way, though, since you seem to believe my hangup is numbers.

If I wrote

Code: Select all

put the files into field 1

I'm not going to get a description of the location of the files, I'll get a list of the files.

On the other hand, even though 'the selectedLine' gives you a description that comes in exactly as you would write it out in code, you can't use it directly as it sits. I'm sorry, to me, that is the definition of inconsistent.

P.s., I'd only use the files if I were looking for a list of the files (in the defaultFolder, which I would change the location of if I needed the files from a different folder )

I think I said it earlier (pretty sure, but damn this all-the-timers) but it sure would be nice if you learn one thing, and could then use it on the next thing. This is more like you learn one thing, then sit scratching your head and rubbing your tummy to get to another thing, which apparently doesn't work anything like the previous thing.

Now I'm beginning to feel like someone else, I think I'll stop at this point.

P.s.s. - I actually came across that one a while back Jaque, and I actually grokked it's meaning, Dar did a good job with it

[dunbarx]

Bogs.

So now, and no kidding, tell me the difference between what "the selectedLine" returns, and what "the text of the selectedLine" returns.

What you are on about is that there is no single native function for #2. It is not, however, that something is wrong with #1. In fact, if we from the beginning had only #2, we would really, really sorely miss #1, and have been wailing in anguish for decades.

You can get #2 from #1, but not the other way around. #1 has immense power. #2 is merely convenient. See?

You can try to persuade the team to add #2 to the vocabulary, but they likely will not, since it is so easy to write and use your own.

Craig

[bogs]

Craig, seriously, if I haven't been clear enough about where I see the problem to be, then I don't know how better to explain it.

The selectedLine isn't the problem, it is just an example of the problem.

As far as #1 and #2 go, I frankly don't see a lot of advantage to #1, please kindly point out the immense power it gives me that #2 does not? I'm expecting the selectedLine to return the line of the field the insertion point is in so that an operation can be carried out using the returned information instead of my having to write my own function to do the same.

It *does* give me returned info that is exactly how I would write it in hard code. The problem in that you can't use that information to get the information your looking for translated to code, unlike the many examples given throughout this thread of other functions that do exactly that.

It isn't the only function, btw, that (using the term lightly) 'works' like that, even among the very narrow selected family of functions.

I pointed this out before as pointed out by others who have found it similarly prickly to reason around. As this is my last (and I mean it) post on the topic, I will quote some of those others, you can ponder what they had to say about it.

As for changing it or what it returns, that was never my intention AGAIN, as I said before, my goal was simply to find out the most consistent way of dealing with the returns of ALL functions so that I am going to have a result I can understand and deal with without trying to memorize which return what.

Some other peoples opinions on the topic you may have missed -

[1.]Some object selectors need the qualifier "of something" while others don't. The
selectors that don't need the qualifier just ignore it if it's supplied. [2.]This
creates confusion not just among new rev developers, but also among seasoned
developers who have to remember which commands work which way. It would be useful
if all the selectors accepted an object qualifier; or secondly if the compiler
would at least give a compile-time error if the qualifier is supplied but would be ignored.

Commands that require an object qualifier:
the selectedText of...
the hilitedLine of...

Commands that ignore the object qualifier:
the selectedLine
the clickLine
the foundLine
the mouseLine
the selectedChunk
the selectedField

1. is what I am talking about.
2. I am one of those, not sure if I'm lightly salted or not, but sure am confused when it happens. Here are a few others that were as well.

[reply] [−] Description Mark 2008-08-22 12:06:31 EDT
This doesn't work:

Code: Select all

  delete the selectedLine of fld "Start Menu"

It works fine in HyperCard, but not in Revolution.

[reply] [−] Comment 1 Neil Clennan 2009-04-21 22:02:51 EDT
I am having this issue as well with Studio version 3.5.0 build 860 on the Macintosh OS X (10.5.6). Here are some additional details.
The field is a scrolling field with "list behavior" turned on.

In the message box...

Code: Select all

select line 2 of fld 2

highlights the second line of the field.

Code: Select all

put the selectedLine of fld 2

returns line 2 of field 2

Code: Select all

delete the selectedLine of fld 2

returns the error
Message execution error:
Error description: Handler: can't find handler

while

Code: Select all

delete line 2 of fld 2

deletes the second line of the field.

[3.][reply] [−] Comment 2 LiveCode QCC 2014-09-25 17:25:10 EDT
Hi Mark
thank you for logging this bug report.
I have confirmed your observations. We will keep you updated as the status of this bug report changes.

Kind Regards,

Hanson

[reply] [−] Comment 3 Sam Norris 2017-04-21 11:58:49 EDT
Bug still present in 8.1.3
While "delete the selectedline of fld x" doesn't work, just "delete the selectedline" does.
"put the selectedline of fld x" and "put the selectedline" yield the same result, provided fld x is the one with the selected line.

[3.] Hmm, I dunno about you, but it seems to me this is not the way it is supposed to work at all.

Lastly, I'd really suggest you read this bug report - https://quality.livecode.com/show_bug.cgi?id=21219

I expect to not understand a LOT of things, but I'm pretty sure the guys in this report *do* understand what it is, how it should work, how to use it, etc. You tell me, you think they are just missing the point?

[dunbarx]

Bogs.

My last one as well.

If "the selectedLine" only gave the contents of the, er, selectedLine, how would you find out which line (not the contents of that line) was selected? In other words, if you had the insertion point in line 3, how could you get the "3" back? The immense power comes from learning about "3".

If you then want some information about line 3, it text, its length, its textFont, whatever, you do a little more work. But the "3" is the core information. #1 is fundamental. #2 builds on, relies upon, #1.

Anyway, I do not see this as a bug of any kind. We can agree to disagree.

Craig

[bogs]

LOL! Craig, I don't know what to tell you, you seem to not understand what I am pointing out, which means I am obviously not expressing myself clearly enough.

You keep referring to the text of the selected line, which is not what I am talking about at ALL. Your right on one thing though, as long as we keep talking at cross purposes, we are going to agree to disagree.