How to tell what a function is returning

[bogs]

In a recent topic I posted about the 'selectedLine', I found out that the information returned is in the form of a string (for which I thank the contributors very much!!).

What I would like to know is, how do you tell if what is being returned is a string, vs. not a string heh.

*Edit - I couldn't see any way to differentiate for instance stepping through a handler and looking at the return in the variables.

[FourthWorld]

Most values in LC are strings. The only exception i can think of offhand is an array, which can be tested with "...is an array".

[richmond62]

Code: Select all

on mouseUp
   put cheese (123) into ABC
   if ABC is not an integer then
      put "string"
      else
      put "numeric"
   end if
end mouseUp

function cheese XYZ
   return "He's a sausage"
end cheese

[bogs]

Hmm. I'll live with being a cheesey sausage, but for instance, if I set the loc of something to the mouseLoc, it will go to that location without needing something like 'the value of ' or like that.

I guess what I'm trying to understand is, how come certain functions can be treated like that, where others can not be?

To compare apples to apples in this context, the selectedChunk can be used directly, the selectedLine can not. How do you tell the difference in your script between the two?

[richmond62]

the selectedChunk can be used directly, the selectedLine can not

Well . . . as both a selectedChunk and a selectedLine can contain text then playing around with integer is not going to help much.

So, surely, the way to tell them apart is to see whether they can be used directly (but, I do not understand what you mean by "used directly").

-
This silly little stack contains a text field above a scrolling list field. The text field has this in its script:

Code: Select all

on mouseUp
   put the selectedChunk into fld "fOUTPUT"
end mouseUp

and NOTHING ends up in fld "fOUTPUT"

The scrolling list field has this in its script:

Code: Select all

on mouseUp
   put the selectedLIne into fld "fOUTPUT"
end mouseUp

and, as you can see from the screenshot, something does end up in the fld "fOUTPUT".

That might be sufficient to differentiate selectedChunk from selectedLine: although, as those are dependent on the type of field
that the user mucks around in I cannot see why that is necessary.

[richmond62]

Of course you could use my earlier 'integer' bit of rocket science to work out if a selectedLine contains "Yakketty-Yak" or "987654321".

[bogs]

Well . . . as both a selectedChunk and a selectedLine can contain text then playing around with integer is not going to help much.

I must not be very clear in what I am asking, and for that I apologize.

The selectedLine returns a format : line x[lineNumber] of field y[fieldNumber].
The selctedChunk returns a format : startCharacter, endCharacter, or, alternately, it reports the insertion point location. As an example, the selectedChunk in the following:

Code: Select all

put the functionNames  into field 2 |

would be

Code: Select all

char 37 to 36 of field 1

When I say you can use that directly, I mean that it can be referenced as is, where as if you wrote:

Code: Select all

put the last word of the selectedLine

you would see the field number as the last word, instead of the last word of the line the selectedLine is referencing. Does that make it any clearer?

Some selected functions seem to work one way, others completely differently, and since Richard says the vast majority of them return strings, I am trying to understand how to tell which of the two returns your getting without trying to memorize every function in Lc.

[bogs]

Mark W. actually put one part of it better than I did in a bug report -

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. 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

Just like the qualifier telling you where to look (of field, of text), some of these need a pre-qualifier (like the text of, or the value of), while others don't and I am finding that hard to figure out.

[dunbarx]

Bogs.

Earlier, you either forgot, or did not know that if you had a field 1 with a selection, and you asked for:

Code: Select all

the last word of the selectedLine

you got the last word of the string that comprised the result of that function, an integer. But I think you wanted:

Code: Select all

the last word of line (word 2 of the selectedLIne) of fld 1

the last word of the line selected in the field.

So is the issue understanding the rather important difference between those two statements? If you read what the selectedLine actually returns, you can see that it gets its result from examining the field, but does not get anything "out" of the text of that field. For that you need to deconstruct what the selectedLine really gives you, and wrap other stuff around it and use that data to access certain contents of the field itself.

I hope I did not make this worse.

Craig

[bogs]

I did remember Craig, I think I must just be phrasing my question really poorly heh.

If I pull the information of a function, I (generally) expect to be able to use that information directly. For instance, if I pull the mouseLoc, and I want to set the loc of something to it, I would type:

Code: Select all

set the loc of [myObject] to the mouseLoc

I sure would not have even thought about writing that in this manner:

Code: Select all

set the loc of [myObject] to (item 1, item 2 of the mouseLoc)

Some of the functions appear to work just like that, or how I would expect them too. Others (like the selectedLine) do not appear to work that way at all, and in fact from the previous thread, I get that they do not, so the real question here is how do you tell when a return from a function is going to work like the mouseLoc, and when it is going to act like the selectedLine ?

Another way to put it might be, how do you tell when you are going to have to use a pre-qualifier, like:

Code: Select all

get the text of the selectedLine; put the last word of it into myVar

and when you don't need to use a pre-qualifier...

Code: Select all

set the loc of [myObject] to the mouseLoc

[dunbarx]

Bogs.

OK, I see.

I guess you just have to be conversant with the precise "wording"of the result of those functions. The "selectedLine" does NOT return

Code: Select all

the text of line x of fld y

it basically, as you said, only returns

Code: Select all

line x of fld y

Why there is not a Bogs-enhanced selectedLine function, "theValueOfTheSelectedLine" is another issue. Why not write one?

Craig

[dunbarx]

Just for laughs, if you see that there is not enough information in what the "selectedLine" give back, you can force a level of evaluation with:

Code: Select all

on mouseUp
   do "answer the last word of" && the selectedLine
   end mouseUp

I asked you not to mention "do".

Anyway, if you think through this, the selectedLine is now integrated and attached to "the last word of", to create a string which LC will see exactly the same as all those "text" and "value" inclusions.

Craig

[bogs]

I guess you just have to be conversant with the precise "wording"of the result of those functions.

...and that was exactly the answer I was hoping I wouldn't get heh. Oh well, I've been disappointed before, I'm sure I will be again

Why there is not a Bogs-enhanced selectedLine function, "theValueOfTheSelectedLine" is another issue. Why not write one?

I gave up on the evil selectedLine and it's ilk, and did exactly that, wrote my own function. To make it even worse, it is a repeat loop function!! ICK!!
but that is for this particular case, and of course, not having 20 years in this language is going to be a disadvantage if there isn't any way to tell what your getting back from a function, as I am sure I will hit this stumbling block over and over and over and...

BTW, I am not looking for a new feature to be added to this language, and changing it now would I am sure break decades of apps that came before, but holy cats it would be nice to have one thing work like the next so you could apply what you learn one time over and over and over and...

I asked you not to mention "do".

I also had already done the "do", the problem being that I may wind up with too many "do do do do do" in this if I kept along that trail

[jacque]

I've been using the language for so long that I never think about it, but on reflection I think I'd look at what the function returns. Virtually everything in LC script is a string and the engine manages variable typing for you if it can tell otherwise. If it recognizes integers it will use them as such, and the mouseloc is a list of two integers. The selected line is a combination of integers and text and so remains a string in its internal typing.

Of course I'm guessing, I have no idea what goes on under the hood.

[bogs]

Yes, I agree with what you've said. I guess what I was / am trying to figure out is why different returns act so differently. Consider these two pictures -



I am pretty sure I could use 'the selectedField' directly, but here is what throws me off. Part of it (where 'no quotes' is) I wouldn't consider a string because the variable doesn't show quotes around it, the second part (the long stack name) *does* have quotes around it, and they are clearly shown, so I'd consider that a string.

The bottom picture shows the return of the selectedLine just like the first part of the picture above it, looking at it, I would never suspect it is a quoted string.

I was hoping to learn how anyone would know? Is there some variable set in the engine that tells you what your getting? If so, it would be nice to be able to test for it, and then be able to handle it correctly. I admire anyone that been using anything so long they never even have to think about it, but for anyone coming in, it can be quite a gotcha if your expecting one thing and get something completely different, and can't even test for it.

Least, thats how it seems to me.