|
Post by Stefan on Dec 9, 2022 13:52:07 GMT -5
Stefan: OK, now that I'm getting to this, it's going into "Silly Mary Ellen" mode because Daddy's watching. I can't get it to fail, either the latest Beta or the Production version. Do you have a consistent failure example? George
Yep, turns out I was unintentionally unhelpful - apologies.
I did some more testing on v 2.7.22340 and it does work...... just not always!
It depends on whether the LOCATE command takes you to a later 'page' or an earlier 'page' in respect of the FIRST occurence that was CHANGEd.
CHANGE ABC DEF ALL ; LOCATE TOP nnn
Say the top line of the current 'page' is line number 120.
If I specify an 'nnn' value of 120 or greater, it works.
If I specify an 'nnn' value of, say 12, it doesn't work.
In the 'not working' scenario, the display is re-positioned to the FIRST occurence that was changed (in my case this happend to be on line 22). My display has 54 lines to a 'page' so positioning the display to line 12 as requested would still leave the FIRST changed occurence (line 22) on the requested 'page'. This discrepency is what lead me to conclude that the LOCATE command was ignored. Without it's presence, line 22 is excact where I would have expected to end up.
Hope this makes senese and helps.
|
|
|
Post by George on Dec 9, 2022 13:53:01 GMT -5
Robert: The :tag is just MUEH's shortcut way of telling us where to enter the :T line commands (Lines 2, 6, and 10)
Our messages crossed, so I tried your scenario, multiple times. I get no truncation, no problems at all.
Not sure where that leaves us.
George
|
|
|
Post by George on Dec 9, 2022 14:05:56 GMT -5
Stefan: Yes, what I found is affected by 'where' the C/F command puts the cursor in relation to 'where' the LOCATE wants it.
And it comes down to whatever is lower down - wins. It's a very old bug, not something we've introduced recently, and can account for a lot of cursor positioning weirdness we have seen. Especially when stacked commands are used. Get to the latest Beta and see how it looks.
George
|
|
|
Post by George on Dec 9, 2022 14:10:10 GMT -5
Robert: Send me your CFG file. You may be able to trigger this fine, but everything here works just fine, even your simple 5 empty line example.
George
|
|
|
Post by George on Dec 9, 2022 15:10:50 GMT -5
Robert: OK, with your CFG I managed to get it to fail. But I'm d*mned if I can see any real difference in the CFGs that makes a difference.
Regardless, I think I have found (and fixed) it (hopefully)
I'll post a new Beta. Lets see how it goes.
George
|
|
|
Post by George on Dec 9, 2022 16:43:35 GMT -5
Yeah, but that "What's the difference" is still worrying. What I found was in no way related to any CFG setting.
This is getting (to me at least) a bit ridiculous, I'm getting to the "let's stop poking this thing stage". I've been wanting to actually put out a real release, but it seems every bloody day some 'new' bug shows up. Really? For months on end, nothing new reported, and then all of a sudden it's like vitamin pills - one-a-day. This has to stop.
George
|
|
|
Post by George on Dec 10, 2022 9:58:54 GMT -5
Robert: Reaching 80? Hmmm, nothing planned other than a dinner at my favorite restaurant, unless it's being kept from me.
Bugs? I'll always try and fix them. It's just lately I've been trying to wrap up the Doc. etc. and tidy up for a release, and every day somebody pops up with a new diversion. Maddening! Especially when many of the latest batch are long term bugs, they've been around in some cases for many years. It's like lately everyone has developed eagle-eyes in bug spotting.
George
|
|
|
Post by George on Dec 10, 2022 11:02:38 GMT -5
My thought as well, there's quite an accumulation. I was just sort of waiting for maybe 1-2 days without a report.
Mainly because whenever a new release goes out, it is invariably followed by a flurry of new bug reports as a bunch of users move up and experience the new code.
But you're right, push it out and establish a new base line, there's a whole bunch of bug fixes in there.
George
|
|
|
Post by Stefan on Dec 11, 2022 7:17:11 GMT -5
Stefan: Yes, what I found is affected by 'where' the C/F command puts the cursor in relation to 'where' the LOCATE wants it. And it comes down to whatever is lower down - wins. It's a very old bug, not something we've introduced recently, and can account for a lot of cursor positioning weirdness we have seen. Especially when stacked commands are used. Get to the latest Beta and see how it looks. George
Hi George,
It looks fine in v22344.
Thank you
|
|