Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Difference in Window size- same compiler- using different VS

Ken2
Beginner
740 Views

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 16.0.4.246 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.

 

0 Kudos
15 Replies
Steve_Lionel
Honored Contributor III
740 Views

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?

0 Kudos
Ken2
Beginner
740 Views

Yes, it is.

0 Kudos
Ken2
Beginner
740 Views

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. 

0 Kudos
JVanB
Valued Contributor II
740 Views

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.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
740 Views

>>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).

Jim Dempsey

0 Kudos
JVanB
Valued Contributor II
740 Views

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.

 

0 Kudos
Ken2
Beginner
740 Views

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?

0 Kudos
jimdempseyatthecove
Honored Contributor III
740 Views

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)

Jim Dempsey

0 Kudos
Ken2
Beginner
740 Views

I'm not sure how you read that I am blaming you, but I assure you, I am not.  Yes, I already use SETTEXTPOSITION(1,1)​.  Thanks for your help.

0 Kudos
andrew_4619
Honored Contributor II
740 Views

Is the "line space" at the top of the screen there from the start or does everything shunt down a line at a later point?

0 Kudos
Ken2
Beginner
740 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
740 Views

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.

Jim Dempsey

0 Kudos
Ken2
Beginner
740 Views

I am not familiar with using the console in streaming mode. 

0 Kudos
andrew_4619
Honored Contributor II
740 Views

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?

0 Kudos
jimdempseyatthecove
Honored Contributor III
740 Views

Andrew,

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?

Jim Dempsey

0 Kudos
Reply