-------------------------8<------------------------ DO k$ = INKEY$ IF k$ = CHR$(0) + CHR$(165) THEN PRINT "Alt Tab" IF k$ = CHR$(0) + CHR$(148) THEN PRINT "Ctrl Tab)" LOOP -------------------------8<------------------------ It did not recognize the keys. Since I was at DOS, I did a QB Keytest and ran it. It didn't recognize those keys either, altho it had clearly done so when I ran it from my menu. Strange. Sat here staring at the screen about two minutes. Then I ran both programs under PDS and they worked - my menu calls QBX Keytest. Recognizing those combinations would appear to be an enhancement in QBX. Well, at least the computer didn't prove me a complete fool as it usually does! *:o) FIDO: Bill White @ 1:135/110 (Miami) InterNet: bill.white@110.sunshine.com * SLMR 2.1a * .-----U+XXXXXXXXXXXXXX|+----X You're sticking that where? --- Maximus 2.01wb * Origin: Miami Amateur Computer Club BBS/USR Courier V.E (1:135/110) --------------- FIDO MESSAGE AREA==> TOPIC: 125 QUICK BASIC Ref: F2L00006 Date: 02/14/98 From: SCOTT MCNAY Time: 05:42pm \/To: JOHN ZORTMAN (Read 3 times) Subj: ZModem - Listen a minute! *** JOHN ZORTMAN wrote in a message to ROBERT KOHL: JZ> Zmodem is essentially very very similar, with the addition JZ> of the **! autodownload and the filename being sent and Zmodem looks more like a cross between Kermit and Windowed Xmodem than anything else; it's an order of magnitude more complex. It supports Xmodem-style xfers, but also supports a streaming mode, which is what gives Zmodem its' speed on faster connections. With streaming mode, it doesn't stop sending in order to wait for an acknowledgement. It also supports control-code escaping and 7-bit encoding, like Kermit does, which allows it to work over certain data networks. Because of control-code escaping, it can interrupt its' own data stream to restart a failed block or to interject an asynchronous data packet, such as a character for the chat mode supported by some variations, such as Super Zmodem (SZMODEM). JZ> same thing, spiffed up... I would *LOVE* to see the ZModem JZ> protocol described like above (in detail!) _Programming_ it JZ> would be very little effort! See what I mean? I'm not sure that it *can* be described so simply. I tried to read through a description just as you said you'd like to see, and I got lost quickly. Describing Xmodem, Xmodem/CRC, Xmodem-1K, Ymodem, SeaLink, Telink, Windowed Xmodem, and all the other many variations is easy, since they're so straightforward, little more than a simple loop. Attempting to describe Zmodem in such a fashion could be done, I think, only if you assumed a window size the same as the block size, and ignored the data escaping. Oh yeah, the block size is variable also, varied depening upon the line conditions. I think you have to view Zmodem as a series of commands, each of which can be interrupted by another command, with data being anything that doesn't appear to be part of a command. JZ> This has nothing at all to do with some kids wanting JZ> "Pkzip" stuff. What others talk about I don't care. *I* JZ> would like to see the rules / format of the ZModem protocol JZ> as I just described Xmodem above. THAT should be available I know I've seen it; you might try the Omen Technology BBS, run by Chuck Forsberg; he developed it and was required to make it available to the public, so his BBS *should* have a description of it. JZ> IDEA: Why not something like *10K* blocks? For the same JZ> reason that the original 128 byte block Xmodem no longer JZ> makes sense for todays big files, breaking down Tradeoffs are involved here, even when you have ISDN-speed transfers. With 300bps xfers, the length of time that it takes to transfer a block is significant, so you want to catch errors before you spend too much time moving the block. With faster modems, that's not as significant, but you do want to throw out a CRC every once in a while, so that you don't spend too much of the proportion of the overall xfer time in REsending. You also need to account for lag caused by network xfers and modem error-correction (MNP4/v42). Larger block sizes, 8K, are available in ZedZap, which is a variant of Zmodem designed for Fido-style mailers. It's modified to support an extra feature bit for the 8K block size, and also allows no (0) files to be sent; normal Zmodem specifies that a file should be sent. The code is available in C as part of BinkleyTerm, which you can find as BSRC-260.ZIP or some similar name. It's interesting to note, though, that the new bi-directional protocols designed for use with Fido-style mailers (Janus and Hydra) use 4K block sizes, which is half that of ZedZap, which has been in use in Fidonet for over a decade now. I haven't been able to find specs for PPP and other internet protocols (I'd like to, though!!), but they seem to have a relatively low block size also. --Scott. --- timEd 1.01 * Origin: Wizard's PC Services, BBS=254-554-2146, Pager=903-3097 (1:395/11) --------------- FIDO MESSAGE AREA==> TOPIC: 125 QUICK BASIC Ref: F2M00000 Date: 02/17/98 From: RICHARD MCCONNELL Time: 07:47am \/To: GREG EASTHOM (Read 3 times) Subj: add text GE> Y'know, this *really* sounds like incremental school projects. Know I am taking this at school but it sucks their all we do is just sit their and type out the programs on the sheet no thought needed.... GE> Just post the whole semester's assignments, so we can get it over with. GE> And I'm *still* going to tell on you. :) Well thanks for the help, Do you know if tou can have a file work like a INI file in windows. --- Maximus 2.01 * Origin: Access Info Kingston (613)547-2479 (1:249/104) --------------- FIDO MESSAGE AREA==> TOPIC: 125 QUICK BASIC Ref: F2M00001 Date: 02/17/98 From: RICHARD MCCONNELL Time: 07:53am \/To: MIKE WYNNE (Read 3 times) Subj: create a file Thanks the program looks great I have to log off to give it a try. You said something about saving or opening binary how is this done. --- Maximus 2.01 * Origin: Access Info Kingston (613)547-2479 (1:249/104) --------------- FIDO MESSAGE AREA==> TOPIC: 125 QUICK BASIC Ref: F2M00002 Date: 02/17/98 From: JASON MAC INNES Time: 08:21am \/To: OLE HEJLSKOV (Read 3 times) Subj: help! Greetings and salutations, -=> Quoting Ole Hejlskov to All <=- OH> Is there a command in Qucikbasic 4.5 that gives you the current OH> disk-space? The easiest way is to save the directoy as a text file, and then examine that to obtain the information you want. You would do that with a simple: SHELL "dir *.*>dirtext.tmp /-p" Then the text file "dirtext.tmp" could be examined for the hard drive size. Below is a lengthy example, which will give you a directory plus the info you want. I have no idea as to the source, except that it should be public domain. It was, I believe, written for GW-BASIC or BASICA. This should work in either QBASIC or QuickBASIC. (I use Quick) Oh the code is messy and unstructured. But that's how I code... ' get directory module SHELL "del dirtext.tmp" SHELL "dir *.*>dirtext.tmp /o:g /-w /-p" DIM a$(512, 3): ' how may files can be in a hard drive directory, anyway? x = 0 OPEN "dirtext.tmp" FOR INPUT AS #1 DO LINE INPUT #1, a$(x, 1) x = x + 1 LOOP UNTIL EOF(1) = -1 CLOSE #1 y = x - 1: x = 0: Start = 0 DO UNTIL LEFT$(a$(Start, 1), 1) = ".": Start = Start + 1: LOOP FOR x = Start TO y - 2 f$ = LEFT$(a$(x, 1), 8): a = INSTR(1, f$, " ") IF a THEN f$ = LEFT$(f$, a - 1) a$ = MID$(a$(x, 1), 14, 5): IF a$ = "