No announcement yet.

Cursor for INKEY$

  • Filter
  • Time
  • Show
Clear All
new posts

  • Cursor for INKEY$

    I am inquiring if there is anyone who knows of a routine simular
    to INKEY$ that will accept one character at a time, echo it to
    the screen and has a cursor over the spot where the next character
    should go. I would like it to not echo backspace, any of the arrow
    keys or carriage returns, but to move to the new spot when one of
    them is used.
    When I programmed my Commadore64 years ago, the origional GET
    statement didn't have a cursor, then some Commodore programmers
    came up with a routine that provided a cursor.


  • #2
    The LineInput function works but if you need to use INKEY$, try
    using the following example:

    Row = 12
    Col = 30
    locate row,col
    color 22,1 'Set to blinking
    print;chr$(95); 'Underscore character
    color 6,1 'Back to normal color mode
    locate row,col

    if inkey$ = {something} then exit loop

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3

      Here's another Example, maybe you can use.

      DECLARE SUB GetKey(Keynumber%, char$)

      Enter = 13
      SpaceBar = 32
      Escape = 27
      BackSpace = 8
      RightArrow = 19712
      LeftArrow = 19200
      Downarrow = 20480
      UpArrow = 18432
      Row% = 1
      Column% = 1
      Locate Row%,Column%,5

      GetKey Keynumber%, char$

      Select Case Keynumber%

      CASE Escape
      EXIT DO

      CASE SpaceBar
      INCR Column%
      Locate Row%, Column%
      PRINT CHR$(32);

      CASE Enter
      Column% = 1
      INCR Row%

      CASE BackSpace
      DECR Column%
      Locate Row%, Column%
      PRINT CHR$(32);

      CASE LeftArrow
      DECR Column%

      CASE RightArrow
      INCR Column%

      CASE DownArrow
      INCR Row%

      CASE UpArrow
      DECR Row%

      PRINT Char$;
      INCR Column%


      IF Column% > 80 Then INCR Row% : Column% = 1
      IF Row% > 25 then Beep : row% = 25
      Locate Row%, Column%


      SUB GetKey(Keynumber%, char$)
      char$ = "": Keynumber% = 0
      char$ = INKEY$
      IF char$ <> "" THEN EXIT DO
      Keynumber% = CVI(char$ + CHR$(0))
      END SUB


      If you want to see the Keynumbers% that each Key generates
      put PRINT Keynumber% somewhere in your code.

      This is one example, I'm sure there is more and better ones
      out there somewhere. ABC has a bunch of Basic Code snippets
      that might include some more examples. Their address is
      If you search, you might find a few here.

      I hope this helps.......Jerry


      [This message has been edited by Jerry Fielden (edited July 06, 2000).]


      • #4
        There is one thing that may be useful to all of you in this discussion
        that you may want to think about in making up loops with INKEY$.

        INKEY$, as well as the SLEEP function, by themselves, are terrible
        problems in multi-tasking environments, as provided by PB-DOS 3.5.
        At least my experience with them is. What they are doing is to
        constantly go around again and again asking, "is there anything
        waiting at the keyboard for me now?" If the DOS PB-3.5 program is
        being written for only pure DOS and that is the only application
        that is to be run on the CPU at one time, this is fine.

        Nowdays, however, more and more you will find programs which may be
        in DOS, but are winding up being run on WIN-95, WIN-98, WIN-NT in
        a DOS-EMU for LINUX and OS/2. Those programs, with the pure INKEY$
        loops that are developing and being suggested here .. will tear a
        CPU operation all to Hades polling them, demanding attention, while
        the CPU really needs to be shared with perhaps many different
        processes. For example, as I write this, there are two PB 3.5 DOS
        applications running constantly looking for input on my OS/2 box
        in separate DOS-VDM sessions. However, they don't *NORMALLY* do that
        with INKEY$ .. they are muzzled.

        First, maybe you don't think this is too important. What can one
        or two applications cost at a time. It isn't that simple. As I
        write this there are currently ... ONE HUNDRED SEVENTY ONE (171!)
        actually threads running on this computer and CPU in SEVENTEEN (17)
        actual separate applications on this CPU as I write this!

        More important, including the *TWO* PB 3.5 apps running, the total
        processor CPU load on the whole 350Mhz unit is less than 3% of its
        total available load level! Thank you OS/2, but that's only part
        of the story. The rest is terribly important here.

        First, there are commercially available and shareware and even some
        freeware utilities whose function is to break up polling applications
        like this INKEY$ loop deal stuff. They force the program, no matter
        how, normally, it is written, to give up time slices to the CPU so
        that other things can be effectively done in modern systems. That
        is true even though the basic program may have been written with,
        say keyboard, or COM port, timer polling, whatever. MOST of the time
        they can help. Examples of the are TAME320, OSTSR, which are commonly
        used to help..

        On the other hand there are programs that are so well written to smash
        the CPU, that no possible combination of time-slice relief utility
        that I can find can quiet them. PB 3.5 in the IDE development mode
        happens to be one of these that I can find absolutely *NO* way to
        keep it from totally trashing the CPU when it is in the IDE mode
        part itself!

        On the other end of the scale, for INKEY$ and SLEEP and ON TIMER
        and so on, it becomes necessary to employ some trickery to keep them
        from trashing the system as well.

        As a general suggestion, the only way that I have found that one can
        keep INKEY$ from trashing the CPU, is to embed a small Assembly
        in-line routine in the INKEY$ loop. Remember, we are looking for
        letter-text rate keyboard I/O here, folks, not joystick response
        for games and so on. This is a simple text I/O routine as such.

        The way that I have found that one can break this up in WIN-98 an
        OS/2 sessions that use PB 3.5 keyboard I/O is to simply use the
        following addition to the "loop":

                 REG %AX, &H8600 '                      Function $AH68in AH
                 REG %CX, &H00 '                        Less than 1000 MS delay
                 REG %DX, &HFF00 '                      Try this for a delay
                 CALL INTERRUPT &H15 '                  Call Interrupt 15H timer
                 Z0$ = INKEY$ '                         Now look at keyboard!
        It may be all wrong to do this somehow and someone else has a better way
        to get this done. However in over ten years of this game, this
        simple ASR added to the entry to the INKEY$ line, has never failed
        us at keeping the CPU totally quiet in any WIN-95/8 or OS/2 DOS-VDM
        session. As far as I can tell, there has never been a typist that is
        routinely using the keyboard I/O that has ever complained that
        the keyboard is too slow or unresponsive!

        That same trick can be worked into the SLEEP routine, and also,
        with care, added to the ON TIMER deal as well. I've had as many
        as sixteen, I think, separate PB 3.5 applications running at the
        same time in DOS-VDM sessions in OS/2 and the processor, if looking
        for just keyboard I/O will never even show a ripple off the 0%
        level on the WPS (Toolbar to you WIN-9x crew!) pulse graph that
        rides for all us OS/2 users constantly!

        I invite you folks to add this little in-line ASR code to these
        routines and see if it really makes any difference in the user
        interface to them! I think you will find there is none. If it
        falls to anyone to use your code in the multi-tasking game, my
        thought is that your users will be *SO* glad you were thoughtful
        of them and put an end to keyboard polling for them in advance!

        If only the PB crew would give us some similar relief on the PB IDE
        itself, it would be greatly appreciated by those of us that do
        intensive work with the IDE or the PBD which has the same fault.
        Although less and less of us are still using the old classic Intel
        CPU with the semaphore bug flaw, there are plenty of then out there.
        In that case, this INKEY$ polling deal and also the PB IDE and PBD,
        if left running constantly in that maxed CPU mode, can actually
        cause disk I/O and system data loss from the F0 bug flaw that they
        can precipitate by keeping the processor maxed out in load mode.
        It's happened to me more than once when I didn't know what was at
        the bottom of this and went off leaving test systems up and smasho
        on the CPU meter!

        Mike Luther
        [email protected]
        Mike Luther
        [email protected]


        • #5
          The IDE doesn't seem to take up excessive time under Windows 2000, but I haven't checked other OSes. Also, the INT 15h timer is not available on all machines. However, it is interesting to hear about the problem and proposed solution, and we will consider it for the next PB/DOS revision.

          Tom Hanlin
          PowerBASIC Staff


          • #6

            Do you think

            WHILE NOT INSTAT: WEND: Char$ = INKEY$

            would cause the same problem with multitasking while in a Loop.
            I noticed that you had left it out of possible causes. It looks
            like it could cause the same problem. But I'm no expert in these



            • #7

              You know .. I just tried it! It doesn't smash an OS/2 DOS-VDM
              session with OSTSR loadhigh c:\u\ostsr 3, together with the
              TAME program loaded as loadhigh tame /TINY /I 9 /TS OS/2..

              I thought that it would so I never tried it!

              To work .. I coded the following:

                  WHILE NOT INSTAT
                  CHAR$ = INKEY$
                  IF CHAR$ = CHR$(13) THEN
                  END IF
                  PRINT CHAR$;
                  GOTO 10
              CPU is totally flat at this point. This may be a far better way
              to do it as this Tom's point was correct. The ASM won't be a
              way to do this in all cases .. If your suggestion does, in fact
              work, then at least for KEYBOARD detoxification, it would open
              up that to more boxes...

              To check this out further, now I've got to reset the SESSION setting
              stuff in the test DOS-VDM in OS/2 .. Then I've got to compile this
              tiny snip and try it on WIN-9x boxes, as well as find someone that
              is using WIN-NT to try it. Someone else can test that here faster
              than I can, methinks...

              That still doesn't solve the problem of polling smasho for the
              SLEEP and TIMER functions ... Any thoughts on what we might do
              to get them out of INT land? It would be wonderful to get out of
              the ASM snippet for those too ...

              Mike Luther
              [email protected]
              Mike Luther
              [email protected]


              • #8
                I can't resist this ..

                Tom and Jerry!

                I just tried the suggestion by Jerry without any polling protection
                in the OS/2 DOS-VDM session game. Bad luck, rats and hamsters ;(

                Unfortunately it roars off totally with the CPU unless I load
                TAME320 as part of the AUTOEXEC.BAT run for the session. You can
                use any sort of ####EXEC.BAT file you want for any DOS-VDM session
                in OS/2, just give it whatever batch file name you want. Thus it
                is easy to test stuff like this ..

                Without TAME loaded, we've off to the moon on a rocket for CPU
                polling with Jerry's suggestion ...

                Tom .. is there *ANY* substitute that you know about for the INT 15
                code that is a better solution? I'd really like to know it if
                there is as I know there are limitations with it...

                While you folks are mulling it over, as part of the IDE fix we
                have badly needed for so long at this, the R&D crew might also
                give thought as to how to break up the polling game for INKEY$
                and SLEEP and the TIMER game too. It might take a separated
                parameter of some kind that you use for these functions to let
                the user select the alternate and some form of a controllable
                poll damping for them, as desired. If you folks did that, you
                would, I think, markedly extend the lifespan of the PB 3.5
                product on into the future where we are all going to be forced
                to go to more and more multi-tasking as a fact of life..

                Thanks ...

                Mike Luther
                [email protected]
                Mike Luther
                [email protected]


                • #9
                  This may be of use
                  $IF 0
                                              by dls
                                        Placed in the public domain
                                        Transient INPUT replacement
                           Trinput returns 0 if a terminated input is still pending
                           but returns 1 if an input is terminated by either an [Enter]
                           or [Esc].
                           If terminated with [Enter] it returns in Answer$ whatever
                           was entered, if by [Esc] it returns a null string.
                           It is transient in the sense that if there is no keyboard
                           activity then you can use the time doing other things.
                           The only limitation is the time to fill the normal keyboard
                           buffer, a second or two, it will catch up with the input
                           when time is available.
                          ' Constants
                          %TRINBUFSIZE=33 'Input buffer size - make it what you want
                          LOCATE 10,20     'Setup position of input
                            IF Trinput("Please give an answer",Answer$) THEN EXIT LOOP
                          LOCATE 4,20
                          IF LEN(Answer$) THEN
                             PRINT "You entered "+Answer$
                             PRINT "You didn't enter anything"
                          END IF
                          SUB Showtime
                              LOCATE 1,1
                              PRINT Time$+" "+Date$;
                          END SUB
                          SUB Screenthings
                              LOCATE 12+13*RND,1+79*RND
                              PRINT CHR$(64+16*RND);
                          END SUB
                          FUNCTION Trinput(BYVAL Question$,Answer$) AS BYTE
                              STATIC Status?,Oldrow?,Oldcol?,Buf$,Cursorpos?
                              STATIC Lq?,Nextchar?,Instate?
                              LOCAL K??
                              IF Status?=0 THEN   ' First time in
                                 Display Oldrow?,Oldcol?,Question$+"? "+LEFT$(Buf$,Nextchar?)
                              END IF
                              IF INSTAT THEN
                                 SELECT CASE K??
                                 CASE %CR
                                 CASE %ESC
                                 CASE %BS
                                 CASE %HOM
                                 CASE %LFT
                                 CASE %RGT
                                   IF Nextchar?>Cursorpos? THEN INCR Cursorpos?
                                 CASE %END
                                 CASE %INS
                                   Instate?=(Instate?+1) MOD 2
                                 CASE %DEL
                                 CASE <256
                                   IF Instate? THEN
                                      Buf$=LEFT$(Buf$,Cursorpos?-1)+" "+MID$(Buf$,Cursorpos?)
                                   END IF
                                 END SELECT
                                 Display Oldrow?,Oldcol?,Question$+"? "+LEFT$(Buf$,Nextchar?)
                              END IF
                              Setcursor Oldrow?,Oldcol?+Lq?+Cursorpos?,0,Instate?
                              FUNCTION=(Status?+1) MOD 2  ' Invert Status?
                          END FUNCTION
                          SUB Setcursor(BYVAL Row?,BYVAL Col?,BYVAL Page?,BYVAL Instate?)
                              LOCAL Cursize??
                              IF Instate? THEN
                                 Cursize?? = &H0208 'Line 2 to 8
                                 Cursize?? = &H0708 'Line 7 to 8
                              END IF
                              DECR Row?            ' Zero base
                              DECR Col?            ' Zero base
                              !    MOV AX,&H0100   ; Set cursor size
                              !    MOV CX,Cursize??
                              !    INT &H10
                              !    MOV AX,&H0200   ; Setcursor position
                              !    MOV BH,Page?    ; Select page
                              !    MOV DL,Col?
                              !    MOV DH,Row?
                              !    INT &H10
                          END SUB
                          FUNCTION Removechar$(BYVAL Q$,BYVAL Posn?)
                          END FUNCTION
                          SUB Display(BYVAL Row?,BYVAL Col?,BYVAL Q$)
                              LOCATE Row?,Col?
                              PRINT Q$;
                          END SUB


                  [This message has been edited by Dave Stanton (edited July 08, 2000).]

                  You're never too old to learn something stupid.


                  • #10

                    Would putting DELAY .05 before INKEY$ while in a LOOP allow
                    the CPU enough time to Share with other programs, or will it
                    stop the CPU dead in it's tracks?

                    DELAY .05
                    Char$ = INKEY$
                    IF Char$ <> "" THEN EXIT DO



                    [This message has been edited by Jerry Fielden (edited July 08, 2000).]


                    • #11
                      Jerry ..

                      I tried you suggestion without any protection from OSTSR or TAME
                      in a DOS-VDM session in OS/2 ...


                      Humor here! 'You have just been attacked by a level 9 key troll!'

                      He has stolen your CPU!

                      Mike Luther
                      [email protected]
                      Mike Luther
                      [email protected]


                      • #12

                        An interesting real beginning of a keyboard I/O routine. It
                        thoughtfully shows the screen perspective of the whole deal as well
                        as it also gives one a real chance to see exactly where the CPU
                        destruction occurs during multi-tasking, even with full pre-emptive
                        multi-tasking such as OS/2 offers!

                        For those not having thought about it yet, in theory, pre-emptive
                        multi-taskers, such as OS/2, are supposed to have the ability to
                        decide on the basis of relative importance of many processes, which
                        one(s) should be given more time in the time-slicing game.

                        If you think about it, the CPU can, in a crude manner of speaking,
                        do only one thing at a time. Thus, if you wish to do two things at
                        a time, in a crude way of speaking, with a CPU, what you must do is
                        generate a list of tasks. You then give instructions to the CPU to
                        divide its efforts on the basis of some algorithim, so many cycles
                        to one task, so many cycles to another. What is really happening
                        when you do this is that the CPU really isn't doing two things at
                        once, but is spending a moment doing this, a moment doing that, a
                        moment doing something else. Because it shifts gears and does these
                        things so quickly, the user perceives that it is doing more than one
                        thing at a time when, in reality, it isn't.

                        That's why, as we get more and more things going at psuedo-once, we
                        need faster and faster CPU's .. gobble-gobble!

                        DesqView was a time slicer and task controller that was oriented
                        toward giving a FIXED number of CPU CYCLES to one task, then to
                        giving a FIXED number of CPU CYCLES to another one. You could lay
                        out conditions where it may have given 7 to one; 5 to another, and
                        so on, but the slicing was still rather fixed by the design of the
                        load matrix for the programs.

                        OS/2 and WIN-NT are what we call pre-emptive multi-taskers! They
                        are the 'next generation' of multi-program control templates, which
                        were originally designed to do a better job of orchestrating CPU
                        time cycles between a number of processes. In the scheme of things,
                        we might want to have, for example, a telecommunications program
                        that is downloading data from a satellite running at the same time
                        we are simply typing a letter to someone.

                        In DesqView, the ratio of time that the CPU took for each of those
                        program could have been set up in a fixed way. We, for example,
                        knowing that the satellite down-loader needed a lot of attention,
                        could be set for 90% of the time and the typing program could be
                        set for only 10% of the time. In truth, if those two programs were
                        the only programs we ever ran, the system would work just fine, and
                        as a matter of fact, did work VERY well for well-designed static
                        program mix systems.

                        However, suddenly we now decide we want to process a picture that
                        has arrived via the satellite! So, on the fly, we load up PMVIEW,
                        for example to see it! Trouble in River City! Our planning as to
                        the relative importance of timing is all awry.

                        OS/2 and WIN-NT, LINUX, for example, all are designed to make a
                        moving dynamic decision on the relative importance of what the CPU
                        should be doing on the fly! For example, while we may really need
                        a burst of CPU time for a quick barrage of letters we type in one
                        creative dash of a sentence in the word processor, we pause to think
                        of what to write next. In that pause, OS/2, WIN-NT, LINUX, VMS, and
                        the other full pre-emptive multi-taskers realize that the keyboard
                        has fallen silent. They, analyze the silence. They make a prediction
                        that the keyboard will remain silent for longer, and, until it comes
                        alive again, they adjust the time available for the satellite and the
                        PMVIEW program to give them more time for action!

                        Much better!

                        I chose these three applications for examples, however, for a reason!
                        While looking at PMVIEW can be delayed for a few thousandths of a
                        second and you'll never notice it, downloading from the satellite is
                        another story! It doesn't give a tinker's dink on a pot about the
                        receiver below if it is in pure broadcast mode! Thus, the whole
                        CPU receiving program *MUST* be fast enough, no matter what, to pull
                        in the ongoing barrage of data, and switch away from that task, *ONLY*
                        when there is idle time in it to do so!

                        Thus, *ANY* program which is designed to use keyboard I/O, comm port
                        I/O, timer I/O for any reason, *MUST*, these modern days, have some
                        way of building in a process where during idle time for that program's
                        I/O stream, it can RELEASE TIME SLICES for other programs. It simply
                        is no longer acceptable for any modern compiler to allow creation
                        of a program that demands total attention to a CPU as a de-facto
                        standard of its work. That's true of both the program as a utility
                        itself, as well as the code it creates in pure DOS too.

                        While we do have utilities that can, most of the time, break up even
                        many of these errant polling-type programs, even a VERY good pre-emptive
                        multi-tasker such as OS/2, can become totally reduced to absolute
                        maximum CPU use by some types of I/O techniques.

                        Ordinarily, although it's only bad policy to allow any program to do
                        this, the results of total CPU domination are not fatal. Its just bad
                        technique to do it. However, in one very important case, there is a
                        little known, and frankly, seldom seen error in the design of all the
                        Intel Classic Pentium CPU's up to what I have been told is the 330 Mhz
                        versions, and it includes all the MMX versions as well.

                        There is a flaw in the semaphore register section of these chips. The
                        semaphore register, in a simplistic sense, is part of the traffic cop
                        operations for the CPU. It's 64 different ranks of task swap can
                        be, under certain circumstances, host to the decisions as to what
                        needs more and what needs less time to operate. It's part of the real
                        true multi-tasking decision making process. In what has been called,
                        as I understand ... bitterly too, about all this, in *ALL* the old
                        Classic Pentiums. If, the semaphore register has a roll-over error if
                        it gets full and hard disk I/O is needed at just the right instant
                        in time when the 64 segments of that register are full ... and that
                        I/O is present on the partition from which the program is loaded,

                        at MAXIMUM CPU LOAD ... BLAM!

                        At that point, because of the roll-over error, the entire system
                        can and *DOES* lock up. Any disk I/O that is going on at that
                        time *MAY* become corrupted. Recall that in a multi-tasker, if
                        you are writing, for example the file allocation tables of your
                        hard disk when it happens ..

                        your hard disk can become toast.

                        The bug is called the F0 Bug. This discussion is important, even
                        though long and complex, because any DOS program which can max out
                        the CPU in a polling manner, can set up PRECISELY the process in
                        these Classic Pentium CPU's that will and does provoke the disk
                        trashing problem.

                        I personally, in development work in DOS-VDM's with Classic Pentimns
                        using PowerBASIC 3.5, have had to totally rebuild my developement
                        box on three separate occaisions from tape from leaving the PB IDE or
                        PBD debugger running in active state and going off and leaving a
                        system hung up at max CPU load for hours. To test server reliability,
                        you have to also test on an active server, folks. I do. These
                        errors are *NOT* what the average user will ever see. But they
                        *DO* happen and they are painful. Yes I can restore a full
                        8-9 Gig test server from tape with over 60,000 files on it. No,
                        I don't like doing it and you always wonder .. Sometimes when I ask
                        a tape system to rebuild a big one like this that old Black
                        spiritual I used to sing in the High School chorus rings back ..

                        "I wonder as I wander out under the sky, If .. "

                        In theory, it really is only bad programming to release any code
                        which can permit CPU dominiation or fail to yield time slices to a
                        poll killer application such as TAME .. However, because of the
                        fact that we can't control the literally millions of Intel Classic
                        CPU, as I have been educated carefully by my Industrial CPU card
                        engineering vendor, the damage risk from releasing code which can
                        cause CPU max and lockup, isn't acceptable at all.

                        Their most visible system lockup problem they had to solve over
                        all this happened to be the Rockwell-Collins world-wide voice comm
                        server system for the USAF, including all the secured communications
                        for Air Force One, so noted to me! The problem is *NOT* limited to
                        DOS-VDM's, the PowerBASIC IDE, applications that use INKEY$ written
                        in PowerBasic... grin. This one was a total native OS/2 32 bit full
                        pre-emptive multi-tasking system! Very huge grin here.

                        Those of you who are designing any PowerBASIC application which
                        uses this technique of INKEY$ for keyboard I/O simply need to be
                        aware of the issue and again it is *NOT* a fault of PowerBASIC,
                        in any pure sense of the word at all. Nor is it of any importance
                        at all if you are the only one using what you write and can control
                        the system in such a way that polling is not relevant.

                        But we badly need a fix for the general problem which is better
                        than the little assembler routine I posted.

                        And ... sigh for Dave too..

                        I tried your suggestion without any protection from OSTSR or TAME
                        in a DOS-VDM session in OS/2 ...


                        Humor here! 'You have just been attacked by a level 9 key troll!'

                        He has stolen your CPU!

                        The problem is still the same

                        If you simply remark out in your subroutine:

                          SUB Screenthings
                          '       LOCATE 12+13*RND,1+79*RND
                          '       PRINT CHR$(64+16*RND);
                                END SUB
                        You see the why right in that very SUBROUTINE, we need SOMETHING
                        like the assembly snip I suggested. Without some form of TAME
                        or OSTSR or other poll troll killer utility, we are right back in
                        the same gorry poll slicendicer that kills us...

                        I've been begging for help from PowerBASIC for this one ever
                        since I bought PB 3.5 when it first came out.

                        Tom's remark is *VERY* important and *VERY* much appreciated.

                        Mike Luther
                        [email protected]
                        Mike Luther
                        [email protected]


                        • #13
                          I don't think this will help the OS/2 population, but under Windows, the following code releases the current time-slice to Windows and drops the CPU utilization to almost nothing:

                          WHILE ISFALSE INSTAT
                            IF ISTRUE BIT(pbvHost,8%) THEN
                              ! push DS
                              ! mov AX, &H1680
                              ! int &H2F
                              ! pop DS
                            END IF
                          A$ = INKEY$

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


                          • #14

                            I don't think this will help the OS/2 population, but under Windows,
                            the following code releases the current time-slice to Windows and
                            drops the CPU utilization to almost nothing:
                            What a misquote! Hugh grin - GDRFC!

                            It works in OS/2 DOS-VDM's as well! I just tried it in in one and
                            the CPU utiliization is slam at the bottom! That's true even
                            without *ANY* polling dampers!

                            To get a Handel on things ...

                            Hallelujah, Hallelujah.Hallelujah ...


                            What are the chances of getting this into even the next fixme for
                            PB 3.5's IDE and the PB 3.5 PBD interface? That way I can leave a
                            critical piece of code work *LOADED* when pager goes off and I have
                            to scram, instead of dump the whole project down and start over with
                            all the debug pointers and settings!!!!!

                            Of course I could take the quote another way about us
                            poor OS/2 users too ... but ...

                            Given time and money .. I guess anything can be solved
                            that ain't mortal...

                            Thanks for your post. I know it's been made before, but I'm guilty as
                            much as anything else for being a stubborn member of the species. As
                            first read I azoomed something I shudn'tof.

                            Mike Luther
                            [email protected]
                            Mike Luther
                            [email protected]


                            • #15
                              Thanks Mel & Jerry for your first two replys to my request for
                              help I combined your two procedures. The only problem that seems
                              to arisen is that when I capitize a letter a blinking cursor appears
                              on the line below as well as blinking cursors are appearing on the
                              working line. This there some way these two problems could be addressed.
                              Fred K



                              • #16

                                I didn't have any problem with it when I tried it out, but
                                I didn't combined the Two.

                                There is better Examples than the one I posted. Did you try
                                the one Dave Stanton posted?



                                • #17

                                  Re your code snippet as follows:-

                                  WHILE ISFALSE INSTAT
                                  IF ISTRUE BIT(pbvHost,8%) THEN
                                  ! push DS
                                  ! mov AX, &H1680
                                  ! int &H2F
                                  ! pop DS
                                  END IF
                                  A$ = INKEY$

                                  Does it need to be used in conjunction with INSTAT and if so what
                                  is "pbvHost"?

                                  Can it be incorporated in an Interrupt call? Presumably Interrupt
                                  &H2F with &H1680 placed in the AX register.

                                  I've searched the Internet for a few days now and can find little
                                  reference to Interrupt &H2F. Could you possibly explain (briefly)
                                  what your code is doing?

                                  Roy Petrie
                                  [email protected]



                                  • #18
                                    Simply put, the code loops until a keypress is detected (INSTAT becomes true).

                                    However, within the loop, the code calls the "multiplex" interrupt (&H21) with AX=&H1680 which asks Windows to reliquish the remainder of the time-slice for the VDM (Virtual DOS Machine).

                                    pbvHost is an internal PowerBASIC variable that "describes" the host environment that the code is running in... bit 8 is true if Windows is running. Unfortunately bit 8 does not detect Windows 2000, but Windows 2000 does respond to the INT &H21|AX=1680 call, so I usually add an additional test in there to cater especially for Win2K...

                                    IF Environ$("OS") = "Windows_NT" then IsNT% = -1 ' elementary way to detect WinNT... there are other ways!
                                    WHILE NOT INSTAT
                                      IF ISTRUE BIT(pbvHost,8%) OR ISTRUE IsNT% THEN    
                                    BTW, pbvHost is documented in the on-line help.

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


                                    • #19

                                      Thanks for that, worked a treat.

                                      As this thread switched to concern about CPU usage I benchmarked
                                      INSTAT and INT&H2F on my PC at work with the following results
                                      (all tests under the same conditions).

                                      PB35 with only an "Inkey" loop
                                      CPU hits 51% on launch and after 6 secs falls to 0%

                                      PB35 with INSTAT and "Inkey" loop
                                      same result

                                      PB35 with INSTAT and INT&H2F
                                      CPU hits 16% on launch and after 1 sec falls to 0%

                                      PBCC20 with "Inkey" loop only
                                      CPU hits 54% then oscillates between 34% and 54% never falling to 0%

                                      PBCC20 with INSTAT and "Inkey" loop
                                      same result

                                      The Interrupt clearly makes a huge difference whereas INSTAT makes
                                      no difference to CPU usage in either programme.

                                      [email protected]



                                      • #20
                                        This is off topic for this forum, but in PB/CC (for Windows), you release the current timeslice by using a "SLEEP 0" statement in the loop. However, PB/CC provides a much nicer and cleaner way to achieve this task:

                                        A$ = WAITKEY$

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