incorrect selectedChunk data

[monki]

So I have a selectedChunk call that's not returning the correct information. No matter the field insertion point, it always returns the same chunk data. This code is sent from an on tabDown command which doesn't pass the tabDown. The code is in a group script, and called from a field within that group.

Code: Select all

function findCursorPositon
   local tSelectedChunk
   put the selectedChunk into it -- just want to see what's happening
   put word 2 of the selectedChunk into tSelectedChunk
   return tSelectedChunk
end findCursorPositon

it var contains

Code: Select all

char 240 to 271 of field 2

which is the wrong character number, I have nothing selected, I just want the insertion point. However tSelectedChunk contains not "240" but

Code: Select all

273

Any ideas why this is happening? Does calling "the selectedChunk" move the insertion point?
Thanks

[Klaus]

Hi monki,

just made a test with LC 8.1.2 RC2 on my Mac.
A field and a button and your script in the group script.
Since there is no "tabdown" message in LC I used "on tabkey"!

I got the exspected correct results!?

What OS and LC version are you using?


Best

Klaus

[dunbarx]

Klaus makes a point:

Since there is no "tabdown" message in LC I used "on tabkey"!

You are saying that the same chunk is returned from your handler. I am wondering how that handler even ran.

Craig Newman

[FourthWorld]

Klaus is correct. When in doubt, consult the Dictionary. There is no tabDown message.

You may also want to check the Dictionary entry for selectedChunk, which explains why the value you're seeing is likely valid:

The return value reports the selected text: the startChar is the first character of the selection, and the endChar is the last character.

If no text is selected but the text insertion point is in a field, the startChar is the character after the insertion point, and the endChar is the character before the insertion point. In this case, the endChar is one less than the startChar.

If there is no insertion point or text selection, the selectedChunk function returns empty.

[monki]

Hi monki,

just made a test with LC 8.1.2 RC2 on my Mac.
A field and a button and your script in the group script.
Since there is no "tabdown" message in LC I used "on tabkey"!

I got the exspected correct results!?

What OS and LC version are you using?


Best

Klaus

My apologies, it is tabKey in the script not tabDown. I wrote a keyDown handler just before posting the message so that was stuck in my mind, but yeah, it's tabKey. I'm running LC 8.1.2 RC2 as well.

I changed the code to pull word 2 from "it" rather than re-run selectedChunk

Code: Select all

function findCursorPositon
   local tSelectedChunk
   put the selectedChunk into it
   put word 2 of it into tSelectedChunk
   return tSelectedChunk
end findCursorPositon

and got following variables

Code: Select all

it = char 226 to 257 of field 2
tSelectedChunk = 226

So selectedChunk is spitting out something new each time it's run from the same handler.

This is fun. I called the code from a button using "dispatch", it works fine. It's part of a handler that marks the insert position in the field, so I know it's correct. But I put a breakpoint at "findCursorPosition", it starts returning the wrong "char 226 to 257 of field 2" again, no matter where the insert is located in the field.

So I remove the breakpoint and run the whole script again using the button, including the method that calls "findCursorPosition". It somehow calls an unrelated handler which isn't part of anything it's working with, and fails there. Something's messed up. Maybe I should just delete LC, reinstall from a fresh download, and see if that fixes it.

[Klaus]

I avoid to use IT whenever possible, since IT may change when you least exspect IT!

Try this:

Code: Select all

function findCursorPositon
   return word 2 of the SelectedChunk
end findCursorPositon

In my test, I always received the correct result, not something new on every click!?

It somehow calls an unrelated handler which isn't part of anything it's working with, and fails there.
Something's messed up. Maybe I should just delete LC, reinstall from a fresh download, and see if that fixes it.

This is strange, but sometimes deleting the troublemaking object, the field in your case, and creating a new one fixes the error.
At least worth a try

[monki]

I avoid to use IT whenever possible, since IT may change when you least exspect IT!

Try this:

Code: Select all

function findCursorPositon
   return word 2 of the SelectedChunk
end findCursorPositon

In my test, I always received the correct result, not something new on every click!?

It somehow calls an unrelated handler which isn't part of anything it's working with, and fails there.
Something's messed up. Maybe I should just delete LC, reinstall from a fresh download, and see if that fixes it.

This is strange, but sometimes deleting the troublemaking object, the field in your case, and creating a new one fixes the error.
At least worth a try

That's how the code started out But after it failed, I needed to break it out and see what was happening with the various bits. I didn't want to create a bunch of temps just to look at what was in selectedChunk. It's not the "it", selectedChunk is wrong when run from a tabKey that isn't passed. It was wrong in the it-less single line version as well. I don't know. It's just being weird whether "it" is there or not.

[Klaus]

Since I'm runnig out of ideas, I was just guessing...

[dunbarx]

I bet it is not LC.

Have you tried taking the pertinent handlers and trying them in a new stack with whatever fields and buttons are the minimum needed to recreate the process?

And just to be sure, right now are you getting a couple of new values for the tSelectedChunk, and then it stabilizes? I just wonder if the insertion point is moving, perhaps to the end of the field after your handler runs.

Craig

[monki]

I bet it is not LC.

Have you tried taking the pertinent handlers and trying them in a new stack with whatever fields and buttons are the minimum needed to recreate the process?

And just to be sure, right now are you getting a couple of new values for the tSelectedChunk, and then it stabilizes? I just wonder if the insertion point is moving, perhaps to the end of the field after your handler runs.

Craig

Not yet, but I figured I would copy the scripts out, then rebuild the app in a new stack a section at a time. Make sure it works. I don't think the insertion is moving. It returns different data when called more than once from within the same handler. So if tab was moving the insert, which it's not, it might not match the location I put it, but it should match the location it moved to, and match it each time its measured. Unless the measurement is affecting movement. But I don't think this app is working on the quantum level quite yet It's an odd duck. Really the only time I've had a problem like this.

[jacque]

What are the tab settings in the field? Do the discrepancies match them? If so then it sounds like LC is calculating the jump between the original insertion point and the next tab.

If that's true then you might have better luck using rawKeyDown and checking for the tab key. That message runs before any text properties are actually updated. TabKey is sent after the text is updated.

[monki]

What are the tab settings in the field? Do the discrepancies match them? If so then it sounds like LC is calculating the jump between the original insertion point and the next tab...

tabKey is trapped. But I did fix the problem, or the two separate problems.

1. a couple of fields in different groups have the same name, so that was causing some of my problems. I wasn't quite searching for what I thought I was As I intend to duplicate this group and use it in several locations, switched to referring to controls by ID. So that's fixed

2. But the selectedChunk thing has something to do with setting the breakpoints. If I set breakpoints and look at the variables selectedChunk and selectedLine, odd numbers are returned. selectedLine will return "155" when the field only has 6 lines for example. I remove the breakpoints, it works fine.

Turns out measurement (my observation of the data) was having an effect: quantum spookiness... Maybe I should write a paper.

Thanks for the ideas guys.

[dunbarx]

I do not want to just let this go.

Do remember that names are fond of causing mayhem, and to manage them carefully from the start. The usual issue is when does not to name controls at all, and they all end up with the default name.

But to say that you are getting selectedLine results that go beyond the number of available lines cannot stand. Are you sure that a test line:

Code: Select all

answer the number of lines of ...

placed right before you query the selectedChunk, will return 6, and not something above 155?. That sort of thing. I do this all the time, and invariably find that the enemy is me.

Craig

[jacque]

But the selectedChunk thing has something to do with setting the breakpoints. If I set breakpoints and look at the variables selectedChunk and selectedLine, odd numbers are returned.

Right. That's because when you break into the script editor, the selected field is the script. You are no longer measuring the field you think you are. If you set a breakpoint after the measurement you should see what you expect.

[dunbarx]

Aha.

Jacque is saying this: "All gadgets in LC are stacks".

That is both wonderful, in that one can manipulate the IDE, and disconcerting now and then, because, well, all gadgetry are stacks.

Craig