I know nothing

[dunbarx]

New stack, new session. I made a field. I made a button. I put this in the button:

Code: Select all

on mouseup
   put "field 1" into tObject
   put the date into resDate
   convert resDate to short date

   --do "put" && resdate && "into" && tObject
   do "put" && quote & resdate & quote && "into" && tObject
end mouseup

If I run it as written, I get a date. if I run the commented line instead, I get a decimal value that relates to the value of the day of the month. I could probably find a relationship in that, if anyone is interested.

I am uneasy.

Craig Newman

[FourthWorld]

I think I'm missing something there. Why are you using "do"?

[dunbarx]

Richard.

This comes from another project where I am putting the date into the focusedObject, which can be one of many. I noticed the oddness while doing that. I cannot, with a variable resDate that contains a date:

put the focusedObject into tObject
put resDate into tObject

rather I have to:

put the focusedObject into tObject
--do "put" && resdate && "into" && tObject --gives decimal!!
do "put" && quote & resdate & quote && "into" && tObject -- works

which is not a problem. I am used to that sort of stuff. I am not used to getting a decimal where a date ought to be, and in the debugger, the variable resdate does indeed contain a date. At least until it the line where it is displayed in the field.

Can you duplicated this?

Craig

[FourthWorld]

Why not just set the object's text property, e.g.:

set the text of tObject to resDate

I've always felt sqeamish about using "do"; having property-driven methods in LC for avoiding it in most cases only made the transition from HC all the easier.

[sturgis]

Its turning into a decimal because its being evaluated as a division sequence. Quotes stop the eval.

5/2/2013 = .00reallylongdecimal

[dunbarx]

Sturgis,

Of course it is, the "do" forcing evaluation of every aspect of the line of code.

I even ran into this before, about 90 years ago. Thank you.

I have several different ways to do this. That was not the problem. It was just understanding the thing. So dumb.

Craig

[FourthWorld]

I have several different ways to do this. That was not the problem.

But it is, in that "do" requires much greater care with regard to evaluation of expressions than more direct methods.

I've used "do" and "value" from time to time, but only when no other method is available. It's not just the performance hit, but the murkiness that emerges with such dynamic compilation.

[sturgis]

^--- captain obvious
EDIT: Well then, seeing your response.. change the above to "CAPTAIN OBVIOUS TO THE RESCUE!" Excuse the cape and tights. Merely part of the persona.
XXSorry bout that!

Its turning into a decimal because its being evaluated as a division sequence. Quotes stop the eval.

5/2/2013 = .00reallylongdecimal

[dunbarx]

Sturgis.

NO, no.

I meant "Well how do you like that! Of COURSE it is". As in "duh".

I missed it, not you. Thank you.

Richard, I agree. Last resort for me too. But sometimes it is a lifesaver, especially with obliquely formed object or variable references that pop up now and then, and then it comes in really handy.

Craig