LiveCode Forums.

I have seen this rarely in v.6. But hourly in v.8

Now and then, and not reproducible, I find that while stepping through a handler I get an error at a particular line. Invariably, the error is "no such object..."

If I set a breakpoint beyond the offending line and run the handler, execution always stops at the breakpoint, which means that there was no error. And there should not have been; the control in question does indeed exist.

I am working around it, and as I said, upon migrating to v.8, I was not startled, having seen it in earlier versions. But it is far more common now, a time waster, and concerning.

Anyone else dealing with this?

Craig Newman

That is a new one on me, but, not surprising considering how relatively small my projects and knowledge are compared to yours (after all, I haven't figured out all I need to know to get into real trouble yet )

I got an error "no such object..." on a line that read something like this: This time I could not get passed it by running the routine again. I was able to fix this permanently by adding Never mind that many other lines of code containing references to other controls, all on the same card, all passed without incident on both sides of that particular line,.

I also am seeing, rather too often, handlers that fail while stepping through but work fine if run normally. I have seen this for decades, going back to HC, and that issue has been discussed off and on forever. I suspect the two are and always were related; the debugger, in single step mode, is not as well connected to the IDE as it is supposed to be. I can almost understand and forgive this if it happened now and then. But since I have been working with v.8, it happens all the time. This could be a deal killer for me.

Not sure if I am being a cryBaby or not. I should take a poll.

Craig

dunbarx wrote: ↑

Wed Nov 15, 2017 5:02 am

Not sure if I am being a cryBaby or not.

Well, I sure don't think so, jumping a complete revision into something else is a big deal, and the problems you point out may help others who wouldn't even know if it was a problem. I can remember a few of my posts about copying controls, code intact that was fairly generic, and while it worked initially, it didn't after being copied.

Puzzling and frustrating (and I still haven't figured out why), so you keep pointing out those oddities, if it gets fixed it makes for a better experience all round.

This sounds like the editor is losing track of the defaultstack. A lot of changes have happened to the script editor over the last few years, so I wouldn't be surprised if a bug crept in.

It's probably something to do with your current project, since I don't see this often. Something in that particular script is making the editor go off track.

You can save some editing if you add this to the handler that fails: set the defaultstack to the topstack. Then you won't have to edit each object reference.

Jacque.

Great minds think alike. As soon as I wrote that screed to Bogs, I peppered just that sort of thing all through my handlers whenever and wherever I navigated to substacks and back again.

So far, all today, I have not seen one instance. Happy again, at least so far.

Craig

Good to hear it works better now, but it would be great if you could pin down what caused it so LC could correct it. One theory, just a guess, is that your script calls a LC library which changes the defaultstack and the original stack never gets restored. I have nothing to base that on, of course.

Jacque.

No libraries at all. No stacks in use. No front or backScripts.

Craig

dunbarx wrote: ↑

Wed Nov 15, 2017 9:15 pm

No libraries at all. No stacks in use. No front or backScripts.

Nope...you have dozens of libraries in use. They're all in the IDE.

You fooled me. I thought you meant my own plug-ins or other gadgetry that was in the message path.

But standard IDE libraries would not be peculiar to my getup. I am concerned that not many others at all are seeing what I am.

Bogs doesn't count. He sees everything. Reminds me of the young Hermann.

Craig

dunbarx wrote: ↑

Thu Nov 16, 2017 1:05 am

Bogs doesn't count. He sees everything. Reminds me of the young Hermann.

More like Schultz from Hogan's Heroes...

Conversation in Klink's office wrote: Hockstetter - Vhat do you make of 'dis? (passes Schultz a button)
Schultz - Oh, it is a BUTTON !"
Hockstetter - I KNOW IT IS A BUTTON DUMKOFF! WHAT DOES IT SAY ?!?
Schultz - (holds button to catch the light, moves it farther away, finally puts on thick glasses...) Ah! It says "US"! (U.S.)
Hockstetter - (stares at Klink) How is he watching the prisoners with the 'eyes of an eagle' when he is blind as a BAT !

Filed report 20682.

But, as usual, am I the only one seeing this?

Craig

dunbarx wrote: ↑

Thu Nov 16, 2017 7:42 pm

...am I the only one seeing this?

I don't think your the only one seeing it, as ...

jacque wrote: ↑

Wed Nov 15, 2017 4:48 pm

It's probably something to do with your current project, since I don't see this often.

...which implies she does see it at least *sometimes*, and has even figured out (roughly) whats causing it. If she has seen it, I would think the implication is others have as well. Jacque just sees things faster sometimes

I've seen this sporadically (the actual error string varies) in all versions of LC. It usually happens when a script calls an IDE library and there is either a script error in the library or the context has been temporarily changed. In older versions of LC there were fewer libraries, but recently almost everything has been changed to script-only stacks which are a type of library. If one of those is misbehaving then you'd see the problem more often in newer versions of LC.

The usual workaround, which Craig used, is to place the breakpoint after the offending line which gives the library a chance to reset the context.

dunbarx wrote: ↑

Thu Nov 16, 2017 7:42 pm

Filed report 20682.

But, as usual, am I the only one seeing this?

Craig

I just added a comment to the bug report, I'm getting a similar issue on a particular project at the moment.