steve@violet.berkeley.edu (Steve Goldfield) (10/24/89)
Encouraged by the many glowing descriptions I've seen about FoxBase (many of which are undoubtedly true), I tried running my McMax database in FoxBase. I ran into a number of problems, some trivial, some not. For instance, McMax accepts either T (dBase II) or .T. (dBASE III+). More importantly, FoxBase seemed to have trouble passing public variables from one program to another. But the worst feature of FoxBase is the one I mention in the subject above. FoxBase takes over both data and program files and changes their type so that McMax can't run them. In order to get my database running again in McMax while waiting to figure out what's wrong with FoxBase (version 2.0), the file types had to be changed back for any file that FoxBase touched. I don't see any advantage to the user for FoxBase to "take over" such files, especially the databases themselves, except to use the type to launch FoxBase. It reminds me of the infamous one-way compatibility many programs offer to get users in but not out. In McMax, the user is given the option of changing the file type to McMax (I usually do so only on programs which launch a primary menu or are stand-alone). Why did FoxBase put in such an annoyingly proprietary feature? Finally, does anyone know what the problem with the public variables is? I have various programs which set filenames and other parameters and then use these to share other programs which perform basic functions like editing, appending, reindexing, printing galleys and labels, and packing. I declared a variable public in one program and set it to a value, but in the next program I ran the variable was declared not to have a value. I'm not strongly motivated to use FoxBase if the programming features I'm used to using don't work. Steve Goldfield
alexis@panix.UUCP (Alexis Rosen) (10/25/89)
First of all, I think it's extremely irresponsible to compare FoxBase to a virus. The behavior described, which is quite reasonable, bears absolutely no resemblance to viral activity. There is enough nonsense going around about viruses (witness the latest InfoWorld Cringe Idiocy) that we don't need more of this on the net. Sorry if this seems harsh but I'm completely serious. That said, the reason for this behavior is simple. First of all, without the correct file types and creator the icons wouldn't have the correct appearance. Much more importantly, you wouldn't be able to find them in the standard file when you tried to open them from the file menu without going through the "all files" check box each time. I considered this issue too when I first encountered it and decided that what they were doing was entirely appropriate. If you don't like it, there are lots of solutions less draconian than tossing the product. As for the problem with globals that you describe, I've never encountered it (as best as I can tell from a very hazy description) and I use globals quite a bit (unusual app, in one case). That's not to say that a problem doesn't exist. If you post some code, I'll be glad to look at it and pass it on to Fox if it really is a bug. They are very good about fixing bugs (turnaround is typically on the order of two days to two weeks, as opposed to two months to two years, which is common practice in the Mac market). Alexis Rosen ps- Until I iron out the bugs on this system, mail to me may vanish for long periods, as may news. So if I disappear for a while, it's not because I don't want to chat, but rather that I can't... If mail does fail, you can try me at alexis@rascal.ics.utexas.edu, but it's not certain either. cmcl2!panix!alexis@nyu.edu
timk@xenitec.on.ca (Tim Kuehn) (10/26/89)
steve@violet.berkeley.edu (Steve Goldfield) writes: First off I takes strong exception to relating Foxbase/+ to ANYTHING other than the high-quality dbaseIII+ compatable rdms it is. (And especially to viri of any sort!!) Another post has explained why things happen in the Mac version of f-base. I'll touch the following problem: >I declared a variable public in one program and set it to a >value, but in the next program I ran the variable was declared >not to have a value. I'm not strongly motivated to use FoxBase >if the programming features I'm used to using don't work. > >Steve Goldfield Did you check the procedure your were running in to make sure that it didn't have a PRIVATE statement with the same variable name. if you do something like this: public varxyz . . .<.....code here . . procedure try_me private varxyz q = varxyz When you run try_me you're going to get an error since the public variable is not 'visible' to the local procedure, which has a variable declared private (ie local) with the same name. In closing, before you condem a product (particularly one that's had so many glowing reports from almost unbiased sources :-) ) make SURE of your claims!! (You'll get less egg-foo-young on your face that way! :-) ) +-----------------------------------------------------------------------------+ |Timothy D. Kuehn timk@xenitec.on.ca | |TDK Consulting Services !watmath!xenitec!timk | |871 Victoria St. North, Suite 217A | |Kitchener, Ontario, Canada N2B 3S4 (519)-741-3623 | |DOS/Xenix - SW/HW. uC, uP, DBMS. Satisfaction Guaranteed| +-----------------------------------------------------------------------------+
bsa@telotech.UUCP (Brandon S. Allbery) (10/28/89)
In article <1989Oct24.153944.29979@agate.berkeley.edu>, steve@violet (Steve Goldfield) writes: +--------------- | mention in the subject above. FoxBase takes over both | data and program files and changes their type so that +--------------- Assuming you're talking about FoxBase+/Mac, what FoxBase does is no different from what any word processor does. +--------------- | I declared a variable public in one program and set it to a | value, but in the next program I ran the variable was declared | not to have a value. I'm not strongly motivated to use FoxBase | if the programming features I'm used to using don't work. +--------------- As far as I've been able to tell, the MS-Doesn't versions of both FoxBase and dBase III+ require that you declare a variable PUBLIC in *all* procedures that want to use the public copy. Probably the Mac versions of both do the same. I don't know anything about McMax, so I can't comment on its handling of PUBLIC variables. ++Brandon -- -=> Brandon S. Allbery @ telotech, inc. (I do not speak for telotech.) <=- Any comp.sources.misc postings sent to this address will be DISCARDED -- use allbery@uunet.UU.NET instead. My boss doesn't pay me to moderate newsgroups. ** allbery@NCoast.ORG ** uunet!hal.cwru.edu!ncoast!{allbery,telotech!bsa} **
awd@dbase.UUCP (Alastair Dallas) (10/28/89)
In article <1989Oct26.010852.11879@xenitec.on.ca>, timk@xenitec.on.ca (Tim Kuehn) writes: > First off I takes strong exception to relating Foxbase/+ > to ANYTHING other than > the high-quality dbaseIII+ compatable rdms it is. (And especially to viri of > any sort!!) > > ...[stuff deleted]... > > In closing, before you condem a product (particularly one that's had so > many glowing reports from almost unbiased sources :-) ) make SURE of your > claims!! (You'll get less egg-foo-young on your face that way! :-) ) > I wish people would "takes strong exception" when others "condem" dBASE IV. After all, nothing is more "dbase" "compatable" than we are. The pervasiveness of the prevailing opinions about Fox and A-T have made me more aware of pernicious attitudes in general. I'm re-thinking whether Exxon was wrong to leave Alaska, or whether Jim Bakker really deserves 45 years. I know "everybody knows" these things are true, but what are the facts? Who cares? Spare me the "glowing reports from almost unbiased sources," please. I'll have the young egg-foo to go. /alastair/ /alastair/