Cross-machine text resolution

[mmehr2]

This has been discovered in actual test usage with Eric. With the test machines running the same screen resolution (I think), font, font size, and bold on, we looked at the file about to be scrolled (same on both ends), and he had 90 lines, while I had 88 only. That, and differences in how the text line flow was rendered, led to scrolling inaccuracies. The feature needs to keep the same words onscreen in the same positions on both ends. We verified that the lag is down to acceptable levels, but the synch of both ends with each other suffers when the line sizes and counts differ.

The tests were run today (3/18/2018) around 6pm (PDT) with his home machine (Win10) controlling my Win10 laptop. Both were Microsoft Surface Pros, but his was a 4 and mine a 2. I had dual monitors, but was using the small one for the tests. My screen res was 1920x1080, his was 1920x1200. We believe the other Windows screen settings were the same (150% on the Windows text etc sizes option). Usage stats will be monitored (we suspect a big difference between our intended usage and PN's recorded stats). I told Eric to shut down his computer after use, and I did the same. See #13 issue to track this.

[mmehr2]

I was scanning the MSW help file system today, trying to figure out how to build it. I noticed in the help that it was talking about Paragraph Alignment, and that there are three types of alignment: Scroll, Paragraph, and Printing. I now believe that the issue is Paragraph Alignment differences between the two machines.

Of course, this was never an issue on a single machine, since it would obey both settings and just work.

I believe the mx,y command sets the Scroll Alignment of the Secondary to be the same as the Primary. What we need to do is to add a NEW COMMAND, to transmit the Paragraph Alignment from Primary to Secondary machine and apply it on the Secondary. That way, the text should reflow the exact same way it is in the Primary machine, and scrolling can proceed normally.

On the Primary, this is set up BEFORE the RichEdit control is loaded (File Open time), but on the Secondary, we would have to somehow send these commands BEFORE the script is sent (or at least delay the text loading until after the paragraph margins are set).

[mmehr2]

See note at this date on issue #22 about how it is possible that the script transfer code may solve this issue as well, if the RTF contents of the richedit control actually contain the paragraph alignment info in the ruler bar.

One way to test is to look at the created MswScript.rtf files that are output by the Scroll mode startup code currently. If you get differences by changing the ruler and regenerating the file ONLY, then there's a good chance this will be sent.

It will probably be wise to check Steve's existing file transfer code for any additional code needed to adapt the imported file for loading into the richedit control on the receive end. I haven't located that part of his code or the libjingle calls needed, jut yet.

[mmehr2]

Some investigation shows that the upper ruler bar is the Scroll Margins, which is what we already send across the machines. The other ruler controls paragraph formatting of the current paragraph, and changing it sets the IsModified() flag on the CRichEditDoc object (AMswDoc) that is open, implying that it gets saved when the RichEdit contents are saved. There is a different paragraph format for every paragraph, so if this really were the issue we were seeing in tests, it would have had to have been set by one of us on our private copies. I don't remember if I manipulated this at all.

We could always try a few other machines and see what those say, but we did go to great lengths to make sure we had the same screen resolutions used and dialog unit sizes set at the Windows level.

I suspect we'll know more after the transfer code is working, anyway. But there may be some head-scratching time after that if they aren't identical after the transfer.

[mmehr2]

I guess the point about paragraph alignment is that there is one for each paragraph. Changing it sets the "dirty" flag so the data is modified. These settings should therefore be transferred via the code for issue #22 so until that is done, don't worry about doing extra for this.