Strange change of behaviour, executing daughter programs in
in [Fortran]
|
Prev: RECL
Next: 'undefined reference to' compilation problem
From: Kurt Kallblad on 10 Apr 2008 12:49 "Gary Scott" <garylscott(a)sbcglobal.net> wrote in message news:YlqLj.4508$IF7.809(a)newssvr25.news.prodigy.net... > Kurt Kallblad wrote: >> >> "Terence" <tbwright(a)cantv.net> wrote in message >> news:5203a4cb-cdbf-47f9-87b2-d2c90595039a(a)s13g2000prd.googlegroups.com... >> >>> Sorry about that! >>> Google seems to use short lines and does not discard trailing >>> blanks. >>> Here is a replacement! >>> >>> A little more detail. >> >> <snip> >> >>> The SCR-OUTSTR and SCR-SETPOS routines mentioned internally ARE >>> working. >>> >>> So the suspects seem to be:- >>> >>> The SCR-INPC routine, which is as follows. >>> >>> INTEGER*2 FUNCTION SCR_INPUTC(IWAIT) >> >> <snip> >> >>> INTEGER*2 FUNCTION SCR_EDTSTR(IATT2,IROW2,ICOL2,LENG,STRNG) >> >> <snip> >> >> I don't think your problem is in those routines. >> DVF's online manual says: "However, PEEKCHARQQ does not work under >> Fortran QuickWin applications, since QuickWin has no console buffer >> to accept unsolicited input." > > Quickwin doesn't have an associated console buffer, that's true, but > it could easily be extended to accept such keyboard input via > peekcharqq. There's nothing really special about consoles, they're > just another GUI window with some special handling procedures > associated. You can freely mix console windows and "normal" GUI > windows. The OS doesn't care. > I don't follow you. As I read your comment it's easy to extend QuickWin to eccept keyboard input via peekcharqq. The manual says that the routine doesn't work under QuickWin. I have not done anything to extend the use of the routine but still it works in my examples. Why??? May main idea was to eliminate the OP's focus on the two functions if there was no problem with them and your comment seems to improve my own conclusion. >> >> However, I tested your functions with two small programs: >> !------------------ >> program xp ! 3 ways to start another program >> use dflib >> use dfport >> i = runqq('c:\...\xq.exe', ' ') >> i = system('c:\...\xq.exe') >> i = systemqq('c:\...\xq.exe') >> end program xp >> !------------------ >> program xq ! simple test of your routines >> integer*2 :: i >> integer*2 :: iatt2 = 1 >> integer*2 :: irow2 = 1 >> integer*2 :: icol2 = 5 >> integer*2 :: leng = 8 >> integer*2 :: SCR_INPUTC >> integer*2 :: SCR_EDTSTR >> character(len=8) :: strng = '1' >> i = 1 >> print *, SCR_INPUTC(i) >> i = 0 >> print *, SCR_INPUTC(i) >> i = SCR_EDTSTR(iatt2, irow2, icol2, leng, strng) >> end program xq >> !------------------ >> In your SCR_OUTSTR I replaced the use of OUTSTR with print *,strng >> and I comment out the use of SCR_SETPOS. >> >> Both programs were built as console and QuickWin applications >> with DVF6.6C and run under WinXP. All 4 combinations worked as >> expected which might indicate that the problem is somewhere else. >> >> Kurt > > > -- > > Gary Scott > mailto:garylscott(a)sbcglobal dot net > > Fortran Library: http://www.fortranlib.com > > Support the Original G95 Project: http://www.g95.org > -OR- > Support the GNU GFortran Project: > http://gcc.gnu.org/fortran/index.html > > If you want to do the impossible, don't hire an expert because he > knows it can't be done. > > -- Henry Ford
From: Gary Scott on 10 Apr 2008 13:00 Kurt Kallblad wrote: > > "Gary Scott" <garylscott(a)sbcglobal.net> wrote in message > news:YlqLj.4508$IF7.809(a)newssvr25.news.prodigy.net... > >> Kurt Kallblad wrote: >> >>> >>> "Terence" <tbwright(a)cantv.net> wrote in message >>> news:5203a4cb-cdbf-47f9-87b2-d2c90595039a(a)s13g2000prd.googlegroups.com... >>> >>> >>>> Sorry about that! >>>> Google seems to use short lines and does not discard trailing blanks. >>>> Here is a replacement! >>>> >>>> A little more detail. >>> >>> >>> <snip> >>> >>>> The SCR-OUTSTR and SCR-SETPOS routines mentioned internally ARE >>>> working. >>>> >>>> So the suspects seem to be:- >>>> >>>> The SCR-INPC routine, which is as follows. >>>> >>>> INTEGER*2 FUNCTION SCR_INPUTC(IWAIT) >>> >>> >>> <snip> >>> >>>> INTEGER*2 FUNCTION SCR_EDTSTR(IATT2,IROW2,ICOL2,LENG,STRNG) >>> >>> >>> <snip> >>> >>> I don't think your problem is in those routines. >>> DVF's online manual says: "However, PEEKCHARQQ does not work under >>> Fortran QuickWin applications, since QuickWin has no console buffer >>> to accept unsolicited input." >> >> >> Quickwin doesn't have an associated console buffer, that's true, but >> it could easily be extended to accept such keyboard input via >> peekcharqq. There's nothing really special about consoles, they're >> just another GUI window with some special handling procedures >> associated. You can freely mix console windows and "normal" GUI >> windows. The OS doesn't care. >> > > I don't follow you. As I read your comment it's easy to extend QuickWin > to eccept keyboard input via peekcharqq. The manual says that the routine > doesn't work under QuickWin. I have not done anything to extend the use of > the routine but still it works in my examples. Why??? I'm sorry, I was assuming that the manual description was correct and that peekcharqq did not work. I was intending to say that I don't know of any "good" reason for it not to work other than the implementors of Quickwin chose not to support it. In reality, any program can capture any keyboard input destined for any window/console if it chooses to. If peekcharqq doesn't support it, then you may need to go to a direct API route. And I was making a general, non-helpful in this case commentary. > > May main idea was to eliminate the OP's focus on the two functions if there > was no problem with them and your comment seems to improve my own > conclusion. > >>> >>> However, I tested your functions with two small programs: >>> !------------------ >>> program xp ! 3 ways to start another program >>> use dflib >>> use dfport >>> i = runqq('c:\...\xq.exe', ' ') >>> i = system('c:\...\xq.exe') >>> i = systemqq('c:\...\xq.exe') >>> end program xp >>> !------------------ >>> program xq ! simple test of your routines >>> integer*2 :: i >>> integer*2 :: iatt2 = 1 >>> integer*2 :: irow2 = 1 >>> integer*2 :: icol2 = 5 >>> integer*2 :: leng = 8 >>> integer*2 :: SCR_INPUTC >>> integer*2 :: SCR_EDTSTR >>> character(len=8) :: strng = '1' >>> i = 1 >>> print *, SCR_INPUTC(i) >>> i = 0 >>> print *, SCR_INPUTC(i) >>> i = SCR_EDTSTR(iatt2, irow2, icol2, leng, strng) >>> end program xq >>> !------------------ >>> In your SCR_OUTSTR I replaced the use of OUTSTR with print *,strng >>> and I comment out the use of SCR_SETPOS. >>> >>> Both programs were built as console and QuickWin applications >>> with DVF6.6C and run under WinXP. All 4 combinations worked as >>> expected which might indicate that the problem is somewhere else. >>> >>> Kurt >> >> >> >> -- >> >> Gary Scott >> mailto:garylscott(a)sbcglobal dot net >> >> Fortran Library: http://www.fortranlib.com >> >> Support the Original G95 Project: http://www.g95.org >> -OR- >> Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html >> >> If you want to do the impossible, don't hire an expert because he >> knows it can't be done. >> >> -- Henry Ford > > -- Gary Scott mailto:garylscott(a)sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford
From: Terence on 10 Apr 2008 18:49 I don't use quickwin in DVF, only the console program offer. The menu program and the posted TUI interface modules are from 2004 and worked then and have never bben changed or recompiled. All the DOS modules were called and executed correctly in 2004/2005. These same modules STILL work correctly today on all tested Windows O/ S as DOS-in-Windows programs (otherwisw I would be flooeded with complaints form users). It's just the Menu program that ias suddendly found to not work in Windows 2000 professional (so far). I suppose I must now test the same in XP (where it worked too) to see if there's a major problem with MS updates. Sigh! And then there's "vista" coming along. If only they still made the good old AT!.... Humans can only type so fast after all; the AT was always yawning.
From: Gary Scott on 10 Apr 2008 20:49
Terence wrote: > I don't use quickwin in DVF, only the console program offer. > > The menu program and the posted TUI interface modules are from 2004 > and worked then and have never bben changed or recompiled. > > All the DOS modules were called and executed correctly in 2004/2005. > > These same modules STILL work correctly today on all tested Windows O/ > S as DOS-in-Windows programs (otherwisw I would be flooeded with > complaints form users). > > It's just the Menu program that ias suddendly found to not work in > Windows 2000 professional (so far). > I suppose I must now test the same in XP (where it worked too) to see > if there's a major problem with MS updates. > Sigh! And then there's "vista" coming along. > > If only they still made the good old AT!.... > Humans can only type so fast after all; the AT was always yawning. I maybe shouldn't be too much of a surprise. There were rumors that Vista would do away with console support entirely. -- Gary Scott mailto:garylscott(a)sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford |