Me again, (or, why me?)

[dunbarx]

Anyone.

I have, all of a sudden, a handler that will not place a value into a variable if that variable is named one specific way:

Code: Select all

global tLineNumber

on mouseDown
   put word 2 of the clickLine into tLineNumberxxx
   put word 2 of the clickLine into tLineNumber
   put word 2 of the clickLine into tLineNumberzzz
   

Nothing appears in "tLineNumber", but the line clicked upon settles nicely in "tLineNumberzzz" and "tLineNumberxxx". In fact ANY STRING but "tLineNumber" will do.

Is "tLineNumber" a special double-secret reserved word that has been kept from me? And this because I am so special? Anyone guess how long it took me to find this?

I restarted LC. Nada. I did not shoot my Mac.

Craig

[Klaus]

Hi Craig,

works here for me with a LISTFIELD, unlocked fields only react to a RIGHT-CLICK.
This works on an unlocked/editable field:

Code: Select all

on mouseDown tButton
   if tButton = 3 then
      put word 2 of the clickLine into tLineNumberxxx
      put word 2 of the clickLine into tLineNumber
      put word 2 of the clickLine into tLineNumberzzz
   end if
   breakpoint
end mousedown

What did you test with, locked or unlocked field?
LC 9.6.11, macOS 12.7.3

Best

Klaus

[stam]

What Klaus said:

Code: Select all

on mouseDown
    put the clickLine
end mouseDown

only works with right-click in unlocked fields or on any mouseUp in locked fields

"Normal" unlocked fields don't respond to left-clicks (necessarily, but occasionally annoying...)

[dunbarx]

Thanks, Klaus and Stam, but this is not my first rodeo. The field is locked; I should have included that information for sure.

And anyway, I would not have posted in such a whiney, pouting way if the issue was not that one particular string of chars will not work. It is not that I was having problems with handling the message per se.

So I changed the variable name. All is well. But WHY is it well?

Craig

[stam]

Can’t replicate the issue.
tLinenumber worked fine for me.

Can I check - do u use strict compilation? Could it have been a typo?

[Klaus]

Can’t replicate the issue.
tLinenumber worked fine for me.

Yes, same here.

[dunbarx]

All.

It must be that other factors particular to this field are the issue. In a small test stack, using that string as a variable, works just fine.

The field in question has all sorts of other gadgetry, a selection field pops up at the clickLoc upon mouseUp, the backColor of the clicked line changes, that sort of thing. But I still do not understand it at all, since the loading of the variable is the very first line in the mouseDown handler, and all the other later stuff works fine, until, that is, I call upon the contents of tLineNumber in order to do anything.

I will work around it. Thank you both...

Craig

[dunbarx]

Also, I never use strict compilation, but would that matter?

Craig

[dunbarx]

And, since I like whining, know that after changing the variable to another, which worked fine, I tried going back to the original.

Guess what happened...

A Marvin the Android said, "Gremlins, don't talk to me about gremlins"

Craig

[stam]

Also, I never use strict compilation, but would that matter?

Craig

It doesn't matter as such - but its value is catching typos.

If you did use it, a typo would be very unlikely to be the issue.
Not using it makes code subject to difficult-to-trace errors from the smallest deviation in spelling that can evade the eye.

I personally value this because the mental and code overhead of adding a 1-line variable declaration is next to nothing but protects me from silly errors...

The fact that the issue resolved when you changed the name and changed it back suggests it probably was a typo...

[dunbarx]

Stam.

I am SO aware that a typo can cause all sorts of travail. And I know that you are only suggesting ideas that make sense.

But you will have to trust me about the typo thing. The reason I know that is true, is that once again, even with another variable, I am finding that the loading of word 2 of the clickLine has failed again, though differently. This time the variable is not empty, but rather contains the full result of that function.

This makes it harder to reference the particular line of original interest, as you can imagine.

It is peculiar to the stack I am working on. A new stack has no issues. Watch this space...

Craig

[stam]

Craig,

if you have isolated an issue -and it sounds like you may have - why not share a stack that shows this?
If it's the same issue for everyone, it probably needs reporting. If it's only you, then there's probably something wrong with your installation...

[FourthWorld]

Only one of those variables is declared as global. What happens if you comment the global declaration?