Some General Questions

[Clay Clear]

1) Is there any way to code an "asynchronous" sub/function to be
run in a PB/DOS program? The procedure could be either in the EXE
main source code, or if necessary, contained in an OBJ module.
If it is not natively possible (which I am sure is the case), would
ON TIMER be a suitable alternative? The whole purpose of the
procedure would be to monitor an SHARED/PUBLIC/EXTERNAL integer
to see if it is set to above zero by any of the OBJ modules'
procedures included in my code. If the procedure detects that it is
indeed set to above zero, then it would do an ERROR FlagError.
In this case, would it be necassry to reset the ON TIMER since the EXE
would immediately exit following the display of the error message?

2) this one is a suggestion to the R&D team at PB, Inc. It would appear
that print statements (PRINT, STDOUT) in one active page affect
the cursor position in other pages. Surely it would be possible to
have each page retain its own cursor position data?

Other questions will probably follow.

Thank you for any assistance.


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

[Clay Clear]

ADDED: ignore the first question. I just realized that I can
code a PUBLIC procedure in my EXE.INC, which is included
in ALL of my EXE main source files. Then, all the OBJ procedures
would have to do would be to call to that procedure.



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

[Michael Mattias]

Is there any way to code an "asynchronous" sub/function to be run in a PB/DOS program?
...
ignore the first question

That's good, because MS-DOS is a single-tasking O/S so there is no such thing as asynchronous.

Closest you can come is your ON TIMER thing; second-closest is a separate TSR program using POPUP TIMER.

[Tom Hanlin]

MS-DOS does support multitasking to some extent, as does PB/DOS.
ON TIMER and other events qualify as what Microsoft used to call
"cooperative multitasking" in Windows 3.x days. POPUP TIMER runs
a bit closer to genuine multitasking. To get all the way there,
you'd need to write your own interrupt handlers, which would have
to be done in assembly language. PB/DOS inline assembler is fully
capable of supporting this.

But, that's all complete overkill for the intended purpose. Clay's
second solution is much more to the point.

Different text pages maintain their own cursor state. Possibly, this
might not work for STDOUT, which doesn't explicitly do anything with
the cursor (the operating system directly handles standard output).
If you can show a case where there is cursor location bleed-through,
please post source code, or email mailto:[email protected][email protected]</A> .

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself

[Mel Bishop]

Another aspect to keep in mind is the basic TCC program. After
it's up and running, it "bounces" between the serial port and
the keyboard. This is multi-tasking in a very simple form.

Point being: It's easy to "multi-task" a DOS program if you have
a very narrowly defined set of parameters and take them all into
account when you structure your program.


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

[Clay Clear]

Tom,

It was by using STDOUT that I noticed the "cursor bleedthrough."
However, the only times I have EVER used more than one page
to write to has been when testing/debugging OBJ procedures
that I have written. I am not sure HOW, but it's possible that
some errant bug caused the unpredictable results. So, in that
respect, I apologize for making what is actually an untested/unproven
claim.


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

[Tom Hanlin]

No worries, Clay. It is worth knowing that the OS does not necessarily
know about multiple display pages-- really, the Microsoft command
processor is a fancy version of MS-DOS 2.0. It's clueless. But, if
you find anything weird, perhaps it is worth addressing in PB/DOS.
Let us know. We'll put it on file for PB/DOS 4.0, which is planned
for production.

STDOUT is very direct. The OS is entirely in charge of what happens
to the results. PRINT is much more complex and subtle and, if it isn't
working as expected, possibly, we need to address it. PRINT should
know about things like display pages. We made it that way.

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself

[Clay Clear]

$IF 0
OK, here's some simple code that illustrates my observations:
$ENDIF

    $IF 0
    STDOUT "Test # 1"
 
    DELAY 10
  
    SCREEN ,,2,2

    STDOUT "Test # 2" 'this does not get displayed - just get a blank console screen
   
    WHILE NOT INSTAT : WEND

    END(0)

    $ELSE
 
    PRINT "Test # 1"

    DELAY 10

    SCREEN ,,2,2

    PRINT "Test # 2" 'this gets displayed, but on the [b]2nd[/b] character line

    WHILE NOT INSTAT : WEND

    END(0)

    $ENDIF

$IF 0
Compiled with PB/DOS 3.5. Tested on WinXP Pro, SP 1a.
$ENDIF


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

[Michael Mattias]

Patient, raising right arm above head: Doctor, it hurts when I do this."

Doctor: "Then don't do that."

[Tom Hanlin]

Sho' nuff. That's just wrong. I'll put it on file.

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself