November 1998
-
simple list mgr help (please) (30 Nov 1998 20:45:50)
-
bowerbirds on p.b.s. (x-fb) (1 Dec 1998 11:59:10)
-
Pete's Custom Item-in-DLOG code (30 Nov 1998 12:05:53)
-
Nav Services (Again) & more (29 Nov 1998 14:34:10)
-
QuickBasic not (quite) dead [X-FB] (28 Nov 1998 23:38:05)
-
Re: [COORD] Programing for all (28 Nov 1998 19:44:15)
-
Re: New web site [X-STAZ, ANDY] (29 Nov 1998 07:06:10)
-
Re: New web site [X] (28 Nov 1998 17:53:22)
-
Re: [X-FB] caret's etc. (28 Nov 1998 13:06:04)
-
Using XREF@ [COORD] (29 Nov 1998 11:45:40)
-
Using XREF@ (28 Nov 1998 11:59:43)
-
[COORD] Roadmap & Apologies (Important) (28 Nov 1998 04:54:41)
-
RTF (28 Nov 1998 12:04:11)
-
Going Out of Business Dec 1998 (2 Dec 1998 11:06:50)
-
Re:SpriteWorld vs G3 (27 Nov 1998 23:26:40)
-
SpriteWorld vs G3 (27 Nov 1998 21:08:26)
-
User Item Trick demo (27 Nov 1998 19:36:21)
-
User Item Trick (27 Nov 1998 17:55:01)
-
test-prep programs (28 Nov 1998 13:06:26)
-
Text adventure shell (28 Nov 1998 11:03:17)
-
FB List Xmas Xword (27 Nov 1998 01:28:58)
-
pGreplaceXRes trouble... (27 Nov 1998 00:19:28)
-
Re: [X-FB]Escape Beyond 2001 (preview 6) (26 Nov 1998 18:01:13)
-
Assembler (30 Nov 1998 18:28:07)
-
Wow... (26 Nov 1998 15:27:17)
-
thanksgiving [not X-FB] (27 Nov 1998 09:04:45)
-
Re: Moving GIF's/PICT's (26 Nov 1998 11:46:26)
-
Great Deal on FutureBasic II This Weekend (26 Nov 1998 09:36:35)
-
Escape Beyond 2001 (preview 6) (26 Nov 1998 01:13:41)
-
thsnks giving (25 Nov 1998 19:52:59)
-
MS Word File Spec? (27 Nov 1998 20:41:29)
-
Programmer wanted (25 Nov 1998 16:00:26)
-
Moving GIF's (26 Nov 1998 04:35:45)
-
Handbook and Manuals (26 Nov 1998 04:35:46)
-
XREF vs Growing your own (28 Nov 1998 11:59:33)
-
Re: futurebasic Digest 25 Nov 1998 07:26:42 -0000 Issue 649 (25 Nov 1998 08:27:49)
-
More than 4 DLOG paramaters (26 Nov 1998 17:40:23)
-
Re: XREF@ questions (30 Nov 1998 15:02:22)
-
no problems with large segments here (25 Nov 1998 02:26:38)
-
Double buffering animations (26 Nov 1998 17:40:53)
-
Joysticks support (25 Nov 1998 10:21:00)
-
Re: FN eXchequer (was More XREF Questions) (25 Nov 1998 00:49:42)
-
Re: futurebasic Digest 22 Nov 1998 10:00:34 -0000 Issue 644 (25 Nov 1998 00:06:02)
-
Detecting edit field clicks (25 Nov 1998 20:46:05)
-
Re:monitors (x-fb) (25 Nov 1998 09:12:00)
-
Constants created with DIM RECORD (24 Nov 1998 16:59:48)
-
Re: files question, no more (24 Nov 1998 13:10:57)
-
Simple Progress Bar Thingie (24 Nov 1998 11:09:04)
-
FN RESERROR (20 Apr 1999 15:14:26)
-
Just in case ... (25 Nov 1998 07:48:56)
-
Printing (24 Nov 1998 08:44:29)
-
Custom item in DLOG (26 Nov 1998 19:05:50)
-
Re: User Interface [X-FB] (24 Nov 1998 01:21:33)
-
Nav Services docs available (24 Nov 1998 14:44:59)
-
Re: [LIST MOM] Poetry, veggies, etc... (24 Nov 1998 01:20:57)
-
TextEditor.Main (23 Nov 1998 23:33:34)
-
SCROLL BUTTON/EF blues... (26 Nov 1998 02:12:40)
-
User Interface (26 Nov 1998 17:39:50)
-
[X-FB] Poetry (23 Nov 1998 15:18:51)
-
Re: -> Peter [X-FB] was BREAK (23 Nov 1998 14:26:09)
-
Appearance Manager Corruption (24 Nov 1998 08:20:50)
-
MIDDI Martial Music (23 Nov 1998 09:20:06)
-
Re: Multi monitors (was files question) (25 Nov 1998 21:29:05)
-
buy function junction 3 here... (23 Nov 1998 06:57:00)
-
FB Pages updated (23 Nov 1998 05:21:42)
-
BREAK ON/OFF doesn't work as expected? (26 Nov 1998 21:11:32)
-
r: [FB] LOCAL FN CenterPICT (PICT&) (22 Nov 1998 20:19:42)
-
x-fb Re: [FB] vegetarian (22 Nov 1998 20:01:24)
-
incompatibility with QT 3 (22 Nov 1998 19:58:11)
-
vegetarian (22 Nov 1998 19:40:33)
-
[x-fb] Sincere apologies to veggies (22 Nov 1998 19:22:41)
-
x-fb Re: [FB] cool graphic function thingees yes yes yes yes yes (22 Nov 1998 18:03:40)
-
Re: FB alters clipboard text (22 Nov 1998 14:10:49)
-
Thank You Jonathan (22 Nov 1998 12:54:54)
-
Re: Damaged Project File Error Messag (22 Nov 1998 12:45:39)
-
centerpict (pict&) (22 Nov 1998 07:34:47)
-
CLEAR LOCAL FN centerpict (pict&) (22 Nov 1998 07:32:47)
-
cool graphic function thingees yes yes yes yes yes (23 Nov 1998 12:42:12)
-
Minutes of the Paris meet [X-FB] (23 Nov 1998 14:36:49)
-
LOCAL FN CenterPICT (PICT&) (23 Nov 1998 06:22:28)
-
An update? (23 Nov 1998 00:25:13)
-
More XREF Questions (23 Nov 1998 20:35:46)
-
Constant, the hell dragon (21 Nov 1998 23:03:50)
-
Mysterious XREF Problem? (24 Nov 1998 20:29:44)
-
Desktop refresh (22 Nov 1998 16:31:17)
-
files question (24 Nov 1998 01:20:30)
-
[X-FB] - changing Finder menus (21 Nov 1998 17:22:50)
-
[X-FB] Apology for "PlugIns 102" (21 Nov 1998 17:02:48)
-
PlugIns 102 - repost (21 Nov 1998 17:02:47)
-
Damaged Project File Error Message (22 Nov 1998 11:57:33)
-
Call for a Progress thingie (22 Nov 1998 20:47:34)
-
Capitalization II (22 Nov 1998 13:31:32)
-
try this one instead: 55-line e-book skeleton program... (21 Nov 1998 01:40:08)
-
55-line e-book skeleton program... (23 Nov 1998 15:20:40)
-
Appology (20 Nov 1998 23:37:26)
-
Data Handling (22 Nov 1998 00:10:02)
-
suggested size set (20 Nov 1998 21:23:54)
-
CDEFs and PG (20 Nov 1998 16:00:53)
-
FN Folder (20 Nov 1998 14:44:29)
-
APPLE MENU malfunction? (20 Nov 1998 18:06:27)
-
setting Suggested Size (21 Nov 1998 06:18:36)
-
Problem Demo Solution (20 Nov 1998 11:49:54)
-
(20 Nov 1998 08:14:18)
-
INIT.BAS FIXED! (20 Nov 1998 08:03:53)
-
Re: FAQs Facts (20 Nov 1998 11:48:58)
-
(21 Nov 1998 13:52:18)
-
[X-FB] summer@stazsoftware.com (20 Nov 1998 12:09:47)
-
Re: Finder Menu Trap? (20 Nov 1998 22:45:11)
-
Appearance Manager guidelines (20 Nov 1998 15:26:22)
-
Re: File Management Date: Thu, 19 Nov 1998 00:16:49 -0500 To: futurebasic@associate.com, allmedia@microtec.net From: "Eric M. Bennett" Subject: working directories, vrefs, and paramblocks explained [long] (was Re: [FB] C to FB) Message-Id: Sylvain wrote: >Thank you Eric, but i can't use the FOLDER statement coz >i'm in the mini-runtime. > >That would have been easy. Well, dang. Now we'll have to do it the hard way. But that's what you get for using the mini-runtime. :-) >Also, i know that 2 volumes can have the same name, but i have code >to deal with it. > >Things like '.ioNamePtr&' and 'GETVOLUMEINFO' is like >reading a japanese newspaper to me. In theory, the following function will do what you want (it's modified from some other code of mine, and I haven't tested my modifications). If you want to understand how it works (and a good programmer always understands how the code he's using works :-), then you'll have to read the rest of this rather long message. 'this function converts a path name to a 'working directory number ' 'Note the total lack of error checking. ' CLEAR LOCAL DIM 255 paramblock$,pbPtr&,oserr%,workingDirectoryNumber% LOCAL FN NameToID (fold$,myAppCreatorCode&) 'fold$ holds a full pathname pbPtr&=@paramblock$ 'Get address of this block of memory... pbPtr&.ioCompletion&=0 '...and access it as a record. pbPtr&.ioNamePtr&=@fold$ 'A pointer to the pathname of a directory. pbPtr&.ioVRefNum%=0 'A volume reference number. oserr%=FN GETCATINFO (pbPtr&) pbPtr&.ioWDProcID& = myAppCreatorCode& oserr%=FN OPENWD (pbPtr&) workingDirectoryNumber%=pbPtr&.ioVRefNum% 'you could call CLOSEWD when you're done using this directory, but 'as I explained previously, that can be dangerous END FN=workingDirectoryNumber% Now for the explanation of how this works. First let me start with an aside on where working directory numbers came from and why FB confuses them with volume reference numbers. On the original Macintosh, the filesystem was called MFS (Macintosh File System). It did *not* support directories at all. Every file on the disk was stored in the same directory. The system software created the illusion of directories, but in fact there weren't any (one consequence was that no files on the same volume could have the same name--even if they were in different "fake" directories). Then Apple introduced HFS, which allowed real directories. And there was a very big problem. All the existing software was used to identifying files by two pieces of data: the volume reference number and the file's name. But that information wasn't sufficient any more, because on an HFS volume two files can share the same name if they are in different directories. Uh-oh! So Apple hacked around the problem. Apple made it appear to old applications as if *every folder* on an HFS drive were a separate volume! It did that by assigning volume reference numbers to folders. Since these weren't *really* volume reference numbers (they refer to folders rather than disk partitions), Apple gave them a new name: working directory numbers. The File Manager keeps track of the difference between the two, but old applications are fooled into thinking they have received a volume reference number when in fact they have received a working directory number. At this point it is probably clear why the confusion exists. But this solution creates another problem. Volume reference numbers are short integers, and directory ID numbers are long integers. So the File Manager can't just assign a working directory number to every folder. It might run out of numbers. Instead, it assigns them on an as-needed basis. This is why you must "open" and "close" working directory numbers. When your application quits, modern versions of Mac OS will automatically close working directory numbers that your application used as long as no other programs have been using them. In summary, working directory numbers are a hack to allow old software programs to access HFS volumes. There is NO GOOD REASON why any application written since the introduction of HFS (a loooong time ago) should use them. Shame on whoever decided to use them heavily in FB's file routines. Now let's talk about what's going on in the above function. In theory you can get a working directory number with the OpenWD toolbox call (you'd have to convert your path name into a volume reference number and directory ID first): FUNCTION OpenWD (vrefnum: Integer; dirID: LongInt; procID: LongInt; VAR wdRefNum: Integer): OSerr; This is the Pascal toolbox info. procID& is (quoting IM:Files) "a working directory user identifier. You should use your application's signature as the user identifier." You can use this info to write an assembly language routine in FB that calls OpenWD. See page 239 of the handbook. In FB, the assembly language function would be called like this: oserr% = myOpenWD (vref%, dirID&, procID&, @workingDirID%) It happens that FutureBASIC does implement a function called OpenWD, but it does *NOT* implement it as described in IM:Files. (This sort of thing is a very big pain. I really hate FB's file management.) In FB's implementation of OpenWD, you need to pass a parameter block, which includes things like ".ioNamePtr&". If .ioNamePtr& really is Japanese to you, you'd better learn a new language (don't worry, it's not hard). :-) The toolbox has more friendly routines--such as the version of OpenWD I described above--that do not use parameter blocks, but FutureBasic implements approximately ZERO of them (another reason its file management drives me crazy). The File Manager calls that FB implements use parameter blocks. When you hit a wall with the built-in FutureBasic file routines, you can either learn parameter blocks or you can write assembly routines to call the friendlier file manager calls that FB doesn't support. The former is less of a pain, which is why I used FB's version of OpenWD in the sample function at the top of this message. A parameter block is just a chunk of memory... in FB, you end up treating it as if it were a record. The record definitions are available in Inside Mac, and FB gives partial definitions in the appropriate places (like the docs for GET VOLUME INFO in the reference manual). When you create a record in FB, FB creates constants that let you access the data in the record. If you're not familiar with records, you should probably read the appropriate section in the FB manuals before continuing. Here is a sample record definition from one of my own programs (with a lot of entries snipped): DIM RECORD myXVolumeParam DIM myQElemPtr& DIM myQType% DIM myioTrap% DIM myioCmdAddr& DIM myioCompletion& [snip] DIM END RECORD _myXVolumeParam Now, when you want to create a record of type myXVolumeParam, you do the following in FB: DIM myRecord.myXVolumeParam And then you read or assign values as follows: myRecord.myQElemPtr& = 0 otherVariable& = myRecord.myQElemPtr& To understand a parameter block, you need to understand how FutureBasic accesses records. In this example, let's say that FB knows that the data for myRecord starts at memory location 100. Since long integers are four bytes long, bytes 100-103 hold the value for myQElemPtr& and 104-105 hold the value for myQType% (two-byte short integer). FB associates the value zero with .myQElemPtr& and the value 4 with .myQType%. When you access myRecord.myQType%, it adds the value of .myQType% to the starting location of myRecord. That's 100+4, so FB knows that the data for myRecord.myQType% starts at memory location 104. If you access myRecord.myioTrap%, FB adds 100 to 6, and knows that the data for myioTrap% starts at memory location 106. Now, if you're familiar with how FutureBasic treats pointers, you know that you can treat any long integer variable as a pointer. Here's the important part: ***FB treats a DIMmed record name just like a pointer!*** And if that's true, then you might suspect that you can use a pointer as if it were a record. And, in fact, you can. Therefore, the following two pieces of code accomplish exactly the same thing: Local FN MyRoutineA DIM myRecord.myXVolumeParam myRecord.myQElemPtr& = 0 FN CallSomeOtherFunction (myRecord) END FN Local FN MyRoutineB DIM myRecord.myXVolumeParam,recordPtr& recordPtr& = @myRecord recordPtr&.myQElemPtr& = 0 FN CallSomeOtherFunction (recordPtr&) END FN This also means that you can access any block of memory as any particular type of record! If I have a pointer at memory location 2000, then writing myVariable% = myPointer&.myQType% will copy memory locations 2004 and 2005 into myVariable%. FB does not care whether or not there is a DIMmed record sitting at location 2000. If I have a pointer to a string (such as myPtr& = @myString$), then myVariable% = myPtr&.myQType% will copy two bytes from the fifth and sixth bytes of the string. (If the string is "Apple", the first byte is the string length byte with value five. The fifth and six bytes are the "le" from Apple.) When you are dealing with low-level file manager routines, the file manager usually expects you to pass it a pointer to a big record. The record has entries for things like volume reference numbers, directory ID numbers, pointers to file or directory names, file sizes, file types, etc. This is the mysterious "parameter block"--a block of memory with lots of parameters in it. In other words, it's a record. When dealing with this data in FutureBasic, you don't usually bother to DIM a record. You just clear out a large block of memory and then access it through its pointer *as if it were a DIMmed record*. FutureBasic already has most of the entries in the record (such as .ioNamePtr&) defined for you. So now let's look at the function I'm proposing to you: 'this function converts a path name to a 'working directory number ' 'Note the total lack of error checking. ' CLEAR LOCAL DIM 255 paramblock$,pbPtr&,oserr%,workingDirectoryNumber% LOCAL FN NameToID (fold$,myAppCreatorCode&) 'fold$ holds a full pathname pbPtr&=@paramblock$ 'Get address of this block of memory... pbPtr&.ioCompletion&=0 '...and access it as a record. pbPtr&.ioNamePtr&=@fold$ 'A pointer to the pathname of a directory. pbPtr&.ioVRefNum%=0 'A volume reference number. oserr%=FN GETCATINFO (pbPtr&) pbPtr&.ioWDProcID& = myAppCreatorCode& oserr%=FN OPENWD (pbPtr&) workingDirectoryNumber%=pbPtr&.ioVRefNum% 'you could call CLOSEWD when you're done using this directory, but 'as I explained previously, that can be dangerous END FN=workingDirectoryNumber% This code uses a 256 byte string called paramblock$ as the parameter block. Because the function includes the CLEAR LOCAL line, the parameter block will be zeroed. The parameter block contains a lot of entries whose values we won't be concerned with. However, passing random junk in these entries is a very bad thing, so using CLEAR LOCAL (or otherwise zeroing the parablock) is important. GETCATINFO is a file manager call that will look up the item whose pathname is given and fill in various other parts of the parameter block. If you're getting info on a file, for example, it will fill in pbPtr&.ioFlCrDat&, which is the creation date of the file. If you are getting information on a directory, it fills in the directory ID number (pbPtr&.ioDrDirID&) and volume reference number (pbPtr&.ioVRefNum%) for the directory. [An aside: GetCatInfo doesn't *require* a path name. You can feed it an empty path name along with other information that uniquely specifies a file and it will fill in the file's name--but not the complete path name--for you. You can get info on a directory with GetCatInfo too. It's a very useful function.] Next my function calls OPENWD, which takes the information in the paramblock, tries to find the directory it describes, and tries to create a working directory number for that directory. OPENWD overwrites the volume reference number stored in pbPtr&.ioVRefNum% and puts a working directory number there instead. Why does it do that? As I explained at the beginning of this message, working directory numbers were originally a hack designed to fool old programs into thinking that every folder on a drive was actually an independent volume. That meant that the File Manager returned working directory numbers in variables that were originally supposed to hold volume reference numbers. And since the applications thought they have a vref%, they would keep passing this value back to the file manager as a vref%. So whenever you see a variable that's supposed to hold a volume reference number, you can *probably* stick a working directory number in it instead and the File Manager will sort things out. And when dealing with functions that manipulate working directory numbers, the File Manager just uses the variable that's supposed to hold a volume reference number. This is--in a twisted sort of way--just being consistent with how working directory numbers are used elsewhere. Another important thing to know about parameter blocks is that the file manager uses various memory locations in them for more than one type of entry. For example, pbPtr&.ioVolIndex% and pbPtr&.ioFDirIndex% actually refer to the SAME memory location in the paramblock! The former entry only applies to volumes, so when you are dealing with a volume, the file manager puts a volume index number (ioVolIndex%) there. When you are dealing with files, the file manager doesn't need a volume index number. Instead, it reuses this space for a directory index number (ioFDirIndex%). If you are having mysterious problems with a paramblock and can't figure out why, there may be junk left over from a previous file manager call sitting in some of these multi-purpose places in the paramblock. Try re-clearing the entire paramblock and see if the problems go away. -- Eric Bennett (http://www.pobox.com/~ericb/), Cornell Biochemistry Department First law of computer trade journalism: "No technology exists until Microsoft invents it." -Nicholas Petreley (19 Nov 1998 23:08:14)
-
(19 Nov 1998 22:12:16)
-
Re: futurebasic Digest 19 Nov 1998 10:00:27 -0000 Issu (19 Nov 1998 21:42:03)
-
Re: a dynamic system (X-FB) (19 Nov 1998 18:45:31)
-
a minor talent (19 Nov 1998 18:12:54)
-
a dynamic system (21 Nov 1998 10:10:23)
-
Re: [X-FB] FAQ's Facts (19 Nov 1998 16:15:01)
-
X-FB Unix System Support Job Available (19 Nov 1998 21:51:55)
-
STAZ FN Folder (19 Nov 1998 13:25:37)
-
FAQ's Facts (20 Nov 1998 08:18:40)
-
Re:INIT.BAS doesn't work, of course. (20 Nov 1998 01:40:12)
-
Re: futurebasic Digest 19 Nov 1998 10:00:27 -0000 Issue 638 (19 Nov 1998 08:39:19)
-
INIT.BAS doesn't work, of course. (19 Nov 1998 19:23:11)
-
Was C to FB (19 Nov 1998 20:12:04)
-
Threaded CGI (19 Nov 1998 16:15:02)
-
working directories, vrefs, and paramblocks explained [long] (was Re: [FB] C to FB) (20 Nov 1998 23:25:31)
-
Re: C (well, Pascal) to FB (18 Nov 1998 21:02:59)
-
vref vs. working directory (was Re: [FB] C to FB) (19 Nov 1998 23:30:29)
-
Preference Resources (18 Nov 1998 22:35:06)
-
Fintder Menu Trap? (18 Nov 1998 16:17:17)
-
Paris meet reminder (18 Nov 1998 11:59:10)
-
PlugIns 102 (20 Nov 1998 06:38:28)
-
fsrwshperm problem (18 Nov 1998 08:36:28)
-
Re: [X-FB]Microwaves (18 Nov 1998 18:40:33)
-
Re: futurebasic Digest 18 Nov 1998 07:29:21 -0000 Issue 635 (18 Nov 1998 02:44:37)
-
API? (18 Nov 1998 18:37:25)
-
Re:Graphics question (17 Nov 1998 23:35:54)
-
C to FB (18 Nov 1998 20:09:32)
-
Re: X-FB Microwave (17 Nov 1998 20:21:50)
-
PlugIns 101 (19 Nov 1998 17:38:10)
-
White Background In Edit Field (17 Nov 1998 22:54:44)
-
Ex FB. Fax Stuff (16 Nov 1998 23:37:06)
-
(16 Nov 1998 22:40:42)
-
Re: hand-holding (was: Common core code) (16 Nov 1998 22:23:09)
-
Sheeeshh... (16 Nov 1998 21:56:32)
-
Graphics question (18 Nov 1998 10:16:59)
-
Writing Apps to accept "Plug-in" functionality (17 Nov 1998 21:30:50)
-
Sine/Cosine (17 Nov 1998 00:22:01)
-
4 byte question (17 Nov 1998 10:32:35)
-
[X-FB] HTML work (16 Nov 1998 04:02:14)
-
Dirty words (16 Nov 1998 23:26:36)
-
4 Byte Vars (16 Nov 1998 18:09:58)
-
Core stuff (15 Nov 1998 17:53:15)
-
COMPILE settings (15 Nov 1998 12:40:46)
-
futurebasic cooperation (15 Nov 1998 12:22:40)
-
MIDWorld Again (15 Nov 1998 06:54:27)
-
Re: incoming files, apple events (14 Nov 1998 21:27:05)
-
Re: Splash interference, No More (15 Nov 1998 03:05:31)
-
game (14 Nov 1998 19:32:48)
-
Question About DIM and XREF@ (15 Nov 1998 12:51:27)
-
Re: [X-FB] Paris (14 Nov 1998 15:54:07)
-
type 12 error (15 Nov 1998 17:33:48)
-
Re: Common core code (15 Nov 1998 16:53:14)
-
[X-FB]A good new... (14 Nov 1998 13:59:25)
-
Proposition: Common core code (15 Nov 1998 09:49:28)
-
Re: [X-FB] T-shirts? (14 Nov 1998 09:15:56)
-
Bill's 'CLEAR' Error (14 Nov 1998 15:54:19)
-
FB convention Paris (14 Nov 1998 02:02:25)
-
apple events in first segment (13 Nov 1998 20:05:11)
-
T-shirts? (13 Nov 1998 19:42:54)
-
Re: is there a better storage method (16 Nov 1998 12:14:38)
-
more on incoming files (14 Nov 1998 16:32:20)
-
HELP!!! SEGMENT SWAPPING??? (13 Nov 1998 16:22:39)
-
Arg, more on aliases! (13 Nov 1998 10:41:32)
-
FB FAQsheets Revisions Correction (12 Nov 1998 18:30:22)
-
FB FAQsheets Revisions (12 Nov 1998 18:20:25)
-
JPEG read/write filter (12 Nov 1998 17:46:56)
-
Baud detection (13 Nov 1998 08:04:21)
-
incoming files (18 Nov 1998 15:33:12)
-
Question about "#" syntax in memory (13 Nov 1998 09:52:30)
-
is there a better storage method? (13 Nov 1998 05:35:19)
-
capitalization (12 Nov 1998 23:07:56)
-
Re: A Better Location Manager (11 Nov 1998 18:23:24)
-
A 4 byte solution (13 Nov 1998 15:44:36)
-
Free Apple Express MODEM (33.6) (11 Nov 1998 17:09:49)
-
SPAM (X-FB) (11 Nov 1998 19:38:36)
-
Re: [X-FB] Paris meet! (11 Nov 1998 11:02:07)
-
Download PS file,URGENT HELP! (11 Nov 1998 12:14:29)
-
Color Depth & Resolution (11 Nov 1998 18:02:05)
-
FJ II Manual (11 Nov 1998 02:10:42)
-
[X-FB] Looking for Kazuhiro Furuhata (11 Nov 1998 18:14:05)
-
Paris meet! (12 Nov 1998 18:30:20)
-
Fatbits (10 Nov 1998 22:45:30)
-
Announcements FB FAQsheets (10 Nov 1998 16:05:03)
-
Easy MENU question (12 Nov 1998 19:26:04)
-
Redneck Publisher (XFB) (10 Nov 1998 18:16:22)
-
Re: PNG/zLib (11 Nov 1998 11:15:45)
-
How to zoom the Window (11 Nov 1998 01:37:51)
-
Splash interference (13 Nov 1998 20:45:47)
-
list of desired fb "plug-ins" (10 Nov 1998 14:12:51)
-
Picts in PG (10 Nov 1998 11:11:55)
-
entering numerical prefs again (9 Nov 1998 11:14:58)
-
Embroidery (XFB) (9 Nov 1998 10:29:45)
-
CD Guru's (9 Nov 1998 09:51:15)
-
ANother MIDWorld update (8 Nov 1998 19:01:18)
-
Re: [X-FB] Re: FnJn crashes (8 Nov 1998 18:24:46)
-
Re: [X-FB] STAZ Image Filters (8 Nov 1998 16:28:22)
-
FB2 (9 Nov 1998 11:20:11)
-
STAZ Image Filters - Tiff files (10 Nov 1998 04:11:45)
-
Jpeg, Tif file formats (8 Nov 1998 11:51:44)
-
Re:STAZ Image Filters (9 Nov 1998 22:27:10)
-
sorry, should have consolidated these posts... (7 Nov 1998 23:10:30)
-
gemma (7 Nov 1998 17:34:10)
-
STAZ Image Filters (8 Nov 1998 11:21:33)
-
(7 Nov 1998 20:39:36)
-
FnJn crashes (9 Nov 1998 20:13:43)
-
[fb] FB^3 (7 Nov 1998 11:56:09)
-
Resource Help (7 Nov 1998 17:13:31)
-
Re: Mount a DAT tape (6 Nov 1998 07:57:08)
-
Drag'n'Drop: Files in Window? (9 Nov 1998 19:53:07)
-
open source (8 Nov 1998 02:28:27)
-
Serial reset!! (5 Nov 1998 20:27:20)
-
Re:[FB] iMac/modems (+ Serial Demo does not work) (5 Nov 1998 08:39:59)
-
DAT Tape (X-FB) (5 Nov 1998 13:34:46)
-
[x-FB] (5 Nov 1998 20:31:02)
-
FNJIII and checks etc (5 Nov 1998 22:54:18)
-
Re: debugging was:numerical.. (5 Nov 1998 23:08:29)
-
Re: [X-FB][FB] Foreign Mazooma (4 Nov 1998 19:31:27)
-
Foreign Mazooma (4 Nov 1998 16:10:29)
-
Online ordering (X-FB) (6 Nov 1998 05:34:58)
-
arrayed regions (4 Nov 1998 19:21:22)
-
FnJn Status (4 Nov 1998 23:25:14)
-
(4 Nov 1998 17:47:02)
-
Taxman etc (4 Nov 1998 06:14:38)
-
Re: Online ordering (gone X-FB) (5 Nov 1998 10:57:24)
-
Online ordering (XFB-ish) (4 Nov 1998 02:14:29)
-
well said, tedd (4 Nov 1998 11:17:39)
-
MIDWorld Update (3 Nov 1998 14:31:40)
-
numerical layout in memory (5 Nov 1998 05:32:58)
-
X-FB The MS QB thing (3 Nov 1998 15:09:36)
-
[X-FB] test (23 Sep 1999 19:18:09)
-
Language Translator (3 Nov 1998 10:46:59)
-
an abacus (3 Nov 1998 09:35:11)
-
Young Folks (X-FB) (3 Nov 1998 15:35:05)
-
Broken but fixed (2 Nov 1998 23:08:05)
-
[X-FB] Redneck Publisher (3 Nov 1998 11:41:32)
-
FOR - NEXT loop (3 Nov 1998 09:12:02)
-
HidePict (2 Nov 1998 23:54:45)
-
[X-FB] Larry and the FB archives (2 Nov 1998 20:21:53)
-
long integer arrays (2 Nov 1998 22:31:48)
-
Ex FB VB (2 Nov 1998 21:20:39)
-
Re: X-FB Z-BASIC & Q-BASIC" (2 Nov 1998 14:23:15)
-
Older digests (2 Nov 1998 01:19:24)
-
FB Digests for Oct (2 Nov 1998 01:17:31)
-
Musical notes (2 Nov 1998 08:46:33)
-
BEEP Problem (3 Nov 1998 11:49:26)
-
4 letter register online (1 Nov 1998 00:45:47)
-
X-FB Z-BASIC & Q-BASIC (6 Nov 1998 10:27:52)
-
Speeding up code (3 Nov 1998 20:36:09)
-
Mysterious chat between applications (5 Nov 1998 18:45:58)
-
iMac/modems (3 Nov 1998 14:21:56)
-
Strings > 255 Solved! (2 Nov 1998 03:48:56)
-
Announcement: FB Debugging FAQsheet (4 Nov 1998 15:24:56)
-
Screen Capture (19 Nov 1999 06:41:46)
-
Processor Greedy (11 Mar 1999 08:28:21)
-
MouseEvents (20 Apr 1999 02:51:51)
-
Navigation Services (27 Dec 1998 06:04:30)
-
Globals (24 Sep 1999 18:10:04)
-
Str# Resources (9 Feb 1999 02:11:33)
-
PopUpMenu ID Numbers (17 Nov 1998 16:18:37)
-
[X-FB] REAL Basic (11 Jul 1999 14:14:24)
-
Wanted (4 Dec 1998 18:00:11)
-
RELEASERESOURCE (25 Oct 1999 09:56:38)
-
New Web Site (30 Nov 1998 20:30:58)
-
(13 Sep 1999 16:59:30)
-
Background apps (19 Dec 1998 15:27:16)
-
Pathname to VolRefNum (16 Nov 1998 21:06:19)
-
Handles (22 Nov 1998 22:33:19)
-
Pop Up Menus (2 Jul 1999 08:46:04)
-
FB Web Ring (6 Feb 1999 12:28:29)
-
Resources (3 Dec 1999 01:37:34)
-
Copybits Question (21 Apr 1999 21:30:26)
-
REALbasic ()
-
programming jobs (11 Aug 2000 06:20:42)
-
No Subject (27 Jun 2000 21:47:31)
-
Keep window in back (23 Feb 1999 12:12:12)
-
Memory question (9 Nov 1999 14:07:54)
-
INIT (4 Aug 1999 00:29:56)
-
Re : FB3 (21 Sep 1999 14:35:05)
-
Memory leaks (28 Feb 2000 03:30:57)
-
Macsbug (14 Oct 1999 17:06:34)
-
Re: Mercutio MDEF (19 Nov 1998 21:22:00)
-
FB3 (13 Aug 1999 02:47:30)
-
Virtual memory (29 Jul 1999 00:11:11)
-
FutureBASIC Mailing List FAQ (12 Jul 1999 04:24:32)
-
preferences (31 Jul 2000 11:47:58)
-
Help! (28 Feb 1999 20:37:40)
-
Edit Fields (26 Aug 1999 05:38:16)
-
(17 May 1999 04:49:12)
-
GWorlds (21 Sep 1999 02:31:02)
-
Merry Christmas (25 Dec 1998 12:47:18)
-
AppleEvents (15 Dec 1999 01:23:37)
-
Plugins (3 Feb 2000 23:41:08)
-
Printing Question (22 Nov 1999 01:09:12)
-
Help Menu (17 Jun 1999 03:00:22)
-
Networking (8 Apr 2000 06:51:53)
-
XFB (5 Aug 2000 23:12:13)
-
Re: Drag and Drop (20 Aug 1999 19:34:35)
-
Rotated Text (9 Oct 1999 04:23:24)
-
FB^3 (28 Apr 2000 12:21:30)
-
Tic-tac-toe (13 May 1999 12:06:23)
-
STR # (13 May 1999 12:18:45)
-
FINDERINFO (17 Nov 1999 08:44:50)
-
test (25 May 2000 08:34:12)