|
|
Post by mueh on Nov 14, 2021 12:07:41 GMT -5
George : Since V10.2 if you have lines with length of screen size -1 and you scroll in file the blank in last column on screen is either * or last character on screen for next line . * is from bottom line . To recreate use following file . Can't show you screen shot after error since it is validated by screen shot . After scroll with Mouse down and up and down blank in col 68 is either * or E . You can also repeat the lines to see the problem with full screen scroll . No problem in V8.5 and V10.0  |
|
|
|
Post by George on Nov 16, 2021 11:59:04 GMT -5
MUEH: OK, found in the DoPrint routine. Corrected. Thanks for spotting it.
George
|
|
|
|
Post by mueh on Nov 16, 2021 16:20:00 GMT -5
George: Thanks for 21320 Beta .
There is now a problem when you insert lines with data at col 1 into empty file .
Data at col 1 is not shown on previous line .
Thanks
|
|
|
|
Post by George on Nov 16, 2021 16:30:14 GMT -5
MUEH: Wow! That's amazingly weird. Off to check it out.
George
[UPDATE]
Debugging stuff in the screen display routine is SO difficult as you can't use normal breakpoints, they trigger Windows into a Refresh call and things go rapidly downhill.
And this one was also very subtle, after all the code was working 99% of the time. But it was a typical dumb error, turned out to be a > that should have been a >=
But even after finding it, I still could not explain the effect my 1st attempt had on how column 1 was being treated. Yes, printing colorized text is not straightforward, but nothing explained what was happening.
Anyway, I think it's fine now. (Fingers crossed)
[/UPDATE]
|
|
|
|
Post by mueh on Nov 17, 2021 14:19:54 GMT -5
George: Thanks for 21321 . Problem is fixed . There is another concern on this version in FM . The colouring is now different . In FM Quick Launch Bar there is now a white space after txt followed by Bar Color . Clicking on this Bar Color (without txt) activates previous entry . For active entry in BG2 colour it's followed by Scheme Txt Lo Intensity Color . Also the white space in Cmd Dir Name+ line is confusing . I'm not shure if caused by this fix or any enhacement you made .  |
|
|
|
Post by George on Nov 17, 2021 15:26:25 GMT -5
MUEH: I already spotted this. Aaarrrgggh!! That DoPrint routine is driving me nuts. But I just saw your message when I was coming back to the forum to post yet another Beta. As I said before "I think this one is OK"
What is infuriating is that I've been tweaking the code repetitively to try and correct this, and the latest version, I swear, is exactly the same as the way it was when you first reported the display problem at end of line.
But I did a compare, and yes, there is a correction in 1 line.
I'll update the Beta, it will still have the same version number, so make sure you download it after 15:30 EST.
George
|
|
|
|
Post by mueh on Nov 18, 2021 2:36:28 GMT -5
George: Thanks for your new version . There is still a problem when you repeat a line with size of Screen width -1 . Last column shows now last screen character of next line . See png file after line 1 is repeated . Line length is 101 and e at col 102 is residual data . If you do scroll right to RightScrn_Col = line length+1 you also get residual data in last col . Is following line correct ? IF oPtr < tLen THEN ' Pad needed  |
|
|
|
Post by George on Nov 18, 2021 10:58:19 GMT -5
MUEH: I must be going nuts. I tested all the different failing scenarious yesterday before posting 21321. All worked just fine.
Tried this morning, and your bug is back!
Yes, the line you pointed out is one of the culprits, it should read <= rather than just <. But when I corrected that as my first attempt as fixing this, it triggered the weird problems at Column 1. That's why this has been so difficult for such a tiny fix, I've gone round and round playing with that line and another which was incorrect.
00055 ----- cPtr = LEN(@ptxt) + 1: oPtr += j ' Force loop exit
+++++ 00056 cPtr += LEN(@ptxt): oPtr += j ' Force loop exit
So I corrected the < <= line once more and, again, screenwith stuff looks OK, but FM Quick bar is bad. I simply can't figure out how my tests yesterday afternoon all worked correctly.
As I've said, I'm losing it. New Beta coming up once I properly get a version that solves ALL the weird items. But then I've already said that twice now..
George
|
|
|
|
Post by George on Nov 18, 2021 13:10:20 GMT -5
Robert: We'll have to disagree on this. I think adding a flag variable to provide a 2nd method to exit the loop is 'clutter code'.
In this case the variables still need to be set for the code that follows the DO/LOOP. Now we add the new variable definition, setting it before the loop and then toggling it inside the loop along with the setting of the original variables. What does it all buy us? Clutter.
George
|
|
|
|
Post by mueh on Nov 19, 2021 3:52:40 GMT -5
George: Thanks for 21322 . It solved all the problems . There is only a small cosmetic concern . After last column you see a small part of next column (yellow) in ERH% blue cols lines . if you do a scroll down/up this part is propagated to lines smaller then RightScrn_Col . If possible could you Pad an additional white space ? ( if it doesn't cause other problems ) Thanks for your effort .  |
|
|
|
Post by George on Nov 19, 2021 11:53:30 GMT -5
MUEH: I couldn't see it at first, I had to switch to an old CFG file you sent me and fiddle with font sizes, but it does show up.
It appears to be triggered when the screen size is altered and the new text area is calculated from H x W (in font size units). It can leave a small dialog background strip showing. But I'm not clear how anything gets displayed in there because it's outside the graphic window in which all the text is displayed.
I'm afraid I can't even just try 'padding' by 1 more column. The routine has to be able to 'print' a specific length field without altering the current contents on either side.
I think this is a 'live with it' item, unless I can think of how the data is getting into that area.
George
|
|
|
|
Post by George on Nov 19, 2021 12:53:47 GMT -5
Robert: The problems I had getting this corrected had nothing whatsoever to do with how that loop is managed, it's just a plain complicated piece of logic. If it had been written 'correctly' according to your guidelines, it would have not helped the solution one bit.
If I had coded that line as:
cPtr += LEN(@pTxt) + 1: oPtr += j: EXIT LOOP ' Adjust pointers
would you have even noticed? Maybe you would have because EXIT LOOP is another of those no-no's that we're not supposed to use, like BREAK, ITERATE, CONTINUE, GOTO etc. (I'm told they're a crutch for sloppy or lazy programming).
BTW I didn't code EXIT LOOP because it's simply not needed, the DO/LOOP condition handles it quite well.
As I said, lets agree to disagree. You know how 'stuck' I am in the way I work and the way I program. At my age, it ain't going to change.
George
|
|
|
|
Post by George on Nov 20, 2021 15:00:15 GMT -5
MUEH: Kept looking at the cosmetic problem, it wasn't what I thought was happening, so I managed to poke it into submission. In the process I re-wrote a big chunk of the DoPrint routine, which I obviously now understand a lot better after staring at it over the last few days.
I'll post a 21324 Beta, let me know if it looks better to you as well.
George
|
|
|
|
Post by mueh on Nov 21, 2021 4:10:19 GMT -5
Thanks George for 21324 . There is no change in the symptom . If you zoom into the png file there are 2 additional dot rows shown which are propagated to other lines during scroll . The black dots's are in this case fron "2" . you acan also use "M" to get more black dot's as shown in this png file .  |
|
|
|
Post by George on Nov 21, 2021 12:39:06 GMT -5
MUEH: I'm totally at a loss. Using your CFG file I was originally able to duplicate the bug.
It was caused by simply printing the last part of the text line with a GRAPHIC PRINT command, even if there were more characters than were needed to fill the line, GRAPHIC PRINT just 'throws away' excess that doesn't fit the area. However, if the screen size was just right, and a few extra pixels are available (not enough for a full column), probably what is appearing iis the left edge of the next character.
So I altered the code to just print the actual length needed, no excess characters. Problem disappeared. And it is still 'disappeared' on my system, I cannot repeat the failure. So just in case, I added debug code to display the lengths of the lines as they were printed. All is correct, only the needed length is printed. It doesn't make sense.
My last try is to adjust how the window sizes are done and reduce the right Pad amount, and I'll post another version attempt. But after that, I'm out of ideas.
George
|
|
