I had mentioned in my last post about the last line missing under Windows 7 sometimes. Well I have investigated it more and here is what I have found. I compiled the same program using compiler 184.108.40.206 with VS2010 and VS2013. Then I ran them both on a Windows 7 machine and the one compiled using VS2010 functions normally. The one compiled using VS2013 does not. It has a slightly smaller window with the bottom and side sliders barely showing and the last output line is always missing. On Windows 10 both programs function and look the same. So why does it matter which version of VS is used on how the output of the compiled program functions? Does the compiler rely on routines within each version of VS?
See the attachments. They are titled by program name, VS version, compiler version. The first one is the VS2010, the second one is VS2013 both with version 16 compiler and the last is VS2013 with version 17 compiler.
Possibly a Visual C++ difference, though it seems odd. Intel Fortran doesn't care. There are no "routines within VS".
This is a QuickWin application, yes?
This was the reason I wanted VS2010 working again as I stated in my post the other day. Our company still uses Windows 7 on most of our computers so to get some of the programs to display correctly they still have to be compiled under VS2010 and IVF version 16 since IVF 17 does not support VS2010. It seems odd that the version of VS would have any affect on the outcome of the compile, but it certainly seems to on Windows 7 systems.
Opening the two images in Paint.exe, the difference seems to be an extra 10 pixel gap at the top of the offending image, like an extra blank line was inserted for some reason. I thought at first the difference might be due to scaling, but the images have the same overall size (624X597) and scale it would seem, so if you can just get control of that initial blank line somehow that might be a workaround for your problem.
>>the difference seems to be an extra 10 pixel gap at the top of the offending image, like an extra blank line was inserted for some reason.
This may be a case of the choice of the DLL's. Can you compile using VS2013 + IVF17 on system A, then copy the .exe to System B that has never had VS 2013 installed (or its redistributables), nor IVF 17 installed (or its redistributables).
I was thinking more along the lines of the possibility that the QuickWin code that drew those windows might possibly be counting on an initial text position that might actually be undefined. In that case starting out with SETTEXTPOSITION(1,1) or whatever the command is in QuickWin to reposition the cursor to the upper left of the window might solve the problem by fixing with certainty the initial text position. I know nothing about QuickWin so this is a total guess.
I did run the different compiled versions on a Windows 7 system without any version of VS installed. The line missing issue did not occur, the only difference I saw was the width of the window on VS2013 compiled versions was smaller by about 1/2 the width of the right scroll bar. So Jim you were correct. The lines worked normally. So please explain to me what is causing this and how is it corrected?
Don't blame the messenger. (I'm not privy to the internals of MS product development).
From my experience, the usual issue with the elevator it that it shortens the number of characters per line by 1 character. The symptom normally does not insert a blank line at the top of the screen. Would you by chance be clearing the screen by writing line width number of blank lines? IOW last blanked out line writes into margin causing line index to appear at top.
Have you tried the SETTEXTPOSITION(1,1) before displaying your 1st line?
That failing SETTEXTPOSITION(0,0)
The first line space is put there by the first format statement by design. When the bottom line is reached it scrolls, but on a rerun the screen is cleared, lines scrolled to the top of the window and the top line again is left blank by the first format.
After you PRINT each line, insert a SLEEPQQ(1000). See if you notice anything unexpected (screen indexing/clearing/other). This may lead you to a work-around.
Have you experimented with OPEN-ing the console up in stream mode? In Stream mode, you can write without the CRLF (and insert them where you want). Note, you may also need to FLUSH the console unit to force out the text.
So then is it just as simple as the fact that the number of lines that the console can hold is 1 less on the problem machine(s)?
what do you see if you call GetConsoleScreenBufferInfo and look at the size returned?
From my past experience, the issue I had was the width reported was what was expected, but writing that last character caused a line index _before_ displaying the character. I suspect that the display function computed the number of pixels wide the character was and thought it would not fit thus inserted a newline. In Ken's case, I suspect it is a similar situation with the bottom border. In my case, windows created with the vertical scroll bar seemed to cause this symptom. I hadn't checked to see if a similar situation occurs when you have a window with a horizontal scroll bar.
Ken, can you setup a test of your program with the bottom (horizontal) scroll bar removed?