SCREEN 9 in a Win95 DOS box

[Davide Vecchi]

The below code runs in a Win95 DOS box without any PIF, so not full screen and with the "char size" listbox set to "Auto". This is what goes on; probably it' s normal, but i want to investigate if i can get it different.

The program sets SCREEN 0 and sleeps 3 secs, then sets SCREEN 9, draws a rectangle, sleeps 3 secs, then starts all over again.

DO

SCREEN 0
PRINT "Now in SCREEN 0"

PRINT "Now sleeping.."
SLEEP 3

SCREEN 9
PRINT "Now in SCREEN 9"

LINE (400,0) - (500,100), 2, BF

PRINT "Now sleeping.."
SLEEP 3

LOOP WHILE INKEY$ = ""

END

If one runs it, will probably see that when the program goes to SCREEN 9 the Win95 DOS box blows to full screen, when the program goes back to SCREEN 0 the Win95 DOS box is reset back to its original window size, and so on.
But, if one clicks outside the window (when it' s a window, i.e. when it' s in SCREEN 0), taking the focus off the window, now on, the SCREEN 9 no longer blows the DOS box to full screen, it just enlarges a little bit the SCREEN 0 window, and it draws the rectangle anyway, correctely (i love this).
Now what i' m trying to know is:
1) Can i get SCREEN 9 to always behave like when it hasn' t the focus (i.e. not blowing to full screen) ? My DOS charts have more appeal when automatically resized by the system.
2) The "new size" of the window (i.e. the size it assumes executing SCREEN 9 without the focus) is under the control of what? I mean, what do determines this size, that is not the same than SCREEN 0 (the original one) ?

Davide Vecchi
[email protected]

[Lance Edmonds]

The behavior is dependent on the driver and/or the graphics card. For example, on one of my Win95 systems, when the app has lost focus, Windows pops up a message saying the app cannot run windowed (running at 640x480/256 cols). On my Win2000 system, the app is automatically switched to fullscreen when screen 9 is selected and "windowed" mode is not restored when screen 0 is selected (1024x768/16-bit color).

I recall reading that it may be possible to use screen 9 windowed if Windows is running at 640x480/16 color, however, because the hardware and the driver determine the results, it is unlikely your app will execute predictably on any given PC. In other words, YMWV (your mileage will vary)! Has anyone else experimented with this?

-------------
Lance
PowerBASIC Support
( mailto:[email protected][email protected]</A> )

[Davide Vecchi]

<< "The behavior is dependent on the driver and/or the graphics card" >>

Thanks Lance, this really saved me lot of time i would have wasted for sure seeking who knows where... And thanks for having tested this on your systems, this info is much to me.

In the meantime, this issue, that was just a very appreciated "plus" for me, turned into a need, because people has been told about it (by me..) and now they want it, not just prefere (yes, i would need a customer care manager and shut up myself..).

My system is a Toshiba Satellite Pro 470CDT notebook, the Win95 screen settings are 800 x 600 x 64k colors, char dim is "small chars", the graphic card is Chips and Tech 65555 PCI, chip type F65555 rev 6, DAC type Internal, memory 2 MB, Features DirectDraw.

<< "however, because the hardware and the driver determine the results, it is unlikely your app will execute predictably on any given PC. In other words, YMWV (your mileage will vary)! " >>

More time saved.. But i really hate the word "unpredictable" (unless it' s spoken by myself, of course). If i was a guru i would face this hard.
I wanted to try also the 640x480/16 color setting you mentioned, but in the normal Win95 Screen Properties window i can set up to 16,8 millions colors, but not less than 256 (no comment).

Suppose one is in my hw/sw situation (i.e., if i never give the focus to the window, SCREEN 9 is wonderful), and listen what i' m available to do if it could work.

Before SCREEN 9 (or 8, it' s the same), my program would detect whether the window where it' s running in has the focus or not (i don' t know how to detect this but i bet it' s possible); if it has the focus... yes! prompts the user for him to take the focus off.. Then it waits for the focus to be lost and just then SCREEN 9. I' m a genius, it isn' t?
In the current economy of my app, this really horrible "tecnique" wouldn' t impact too much on the user' s life. Does anyone knows how a window-ran DOS EXE can detect whether it has the focus? And could it be possible to set / lose the focus from code?
Or does anyone have less rough ideas to have SCREEN 9 not blowing to full screen regardless of the focus?

Davide Vecchi
[email protected]

[Davide Vecchi]

On almost all of the PCs of the user' s LAN, the result of SCREEN 9 without the focus is the same: the DOS window doesn' t switch to full screen. So, if my PB program becomes able to give the focus away (even to a companion dummy Win app), i could go to SCREEN 9 without causing the window to switch to undesired full screen (on these systems).

Does anyone have some idea on how to give the focus away from a PB program under Win95?

Davide Vecchi
[email protected]

[Anton Lasich]

David - this is a late reply

You are witnessing why "we" call it Windoze...Although the 2k version
will probably do its housekeeping much better.

The easy way is to use PIF's. But there are excellent freebies outthere that
will allow you to manipulate the API so that your programme does
what it is supposed to do and basically tells win to get outtahere!

I know PBXTRA has it...I think.

I have a lib called WINLIB never used it yet as we run DR-DOS using Windoze
for DTP and banking (on networked but isolated machines). It is various
functions like setfocus etc.

Anton

[Davide Vecchi]

Anton, thank you for your suggestions. I' ll look at PB/Xtra. WINLIB sound interesting too. (I forgot to mention that this is related to PB/DOS).

I have seen another thing: when an exe running in a DOS box withouth the focus BEEPs or PLAYs, the first tone is played and stays on until the window gets the focus; now, if it was a BEEP, the execution continues while the tone stays on, and if it was a PLAY the execution is suspended. This is even more annoying than blowing to full screen, above all when the execution is suspended. I don' t know if this can be fixed through PIFs, i wasn' t able to.
Running this program and making it lose the focus shown me this. The PLAY "A" line should be changed into BEEP.

DIM Start AS SINGLE, SecWait AS SINGLE

SecWait = 2

CLS

DO

PLAY "A"

Start = TIMER

DO WHILE TIMER - Start < SecWait
IF INSTAT THEN EXIT DO
LOCATE 5,5
PRINT TIMER;
LOOP

IF INSTAT THEN EXIT DO

LOOP

END

This seems related to the focus as well, so being able to manage the focus would be still more useful.

Davide Vecchi
[email protected]

-------------

[Lance Edmonds]

This is another of the effects of preemptive multi-tasking on a DOS application. Windows gived the DOS app a tiny time slice of the processor, and moves on to the next process (effectively halting or freezing the DOS app). Eventually, Windows gives the DOS app another time slice and repeats the whole thing over again.

The problem is that a note is expected to play for a particular duration, say 500mSec. That 500mSec only expires once Windows has given the DOS app more than 500mSec of the processor, but to accumulate that much time may take more than 30 seconds of real-time. These are just values I've picked out of the air, therefore YMMV.

WINLIB is a small collection of freeware/PD routines for PB/DOS app's that allow the DOS app to take a small amount of control. For example, there is a routine that starts and stops a "Critical Section", permitting the DOS app to take almost 100% of the CPU for a short period of time, preventing multitasking and background app execution during that interval. Interestingly (and off topic), a Critical Section for a DOS app is not the same as a Critical Section in a Windows app!

There was another routine in WINLIB that allowed a DOS app to switch to full screen (unfortunately, it is impossible for a DOS app to reverse this process without help of a Windows app).

While this is quite interesting, there is a much more advanced way of performing these and other feats (provided the DOS app is running under at least Windows 95)... the answer is PB/CC. For example, using PB/CC you to write a small app that plays a WAV file (a few lines of code only) and then you can SHELL to the PB/CC app from the DOS app... the result is perfect playback of the WAV file. This can be extended to printing, graphics, etc... the limit is the Windows API, and it can be harnessed to provide all sorts of new features to DOS applications.

I try to avoid mixing Tech Support with my personal stuff, but on this occasion I'll make an exception... my DOSPRINT utility is (I think) a great example of harnessing the power of Windows, and wrapping it up for use with a DOS application. Anyone interested can take a look at http://www.amerimports.com/dosprint



-------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Davide Vecchi]

Can anyone tell me where i get WINLIB? I tried some search engine with no luck.

Davide Vecchi
[email protected]