kji@vpnet.chi.il.us (Ken Isacson) (04/10/91)
Here is the start of a list of what I think is missing from Paradox 3.5: 1) A function to get the time of file, such as filetime(fname). They have filesize(fname)! 2) The ability to save the PAL canvas to a buffer. Including all the colors! If you have any additions to this list or would like to place your suggestions for possible solutions, I sure would like to hear them. PS - I have a solution to the first one, not real fast, but it works! -- __________________________________________________________ Ken Isacson Sysop - Board Of Trade BBS GT 016/001 kji@vpnet.chi.il.us (815) 753 - 0042 ----------------------------------------------------------
dnb@meshugge.media.mit.edu (David N. Blank) (04/10/91)
> 1) A function to get the time of file, such as filetime(fname). They > have filesize(fname)! Definitely. I would love to have my application remake its libraries if the source script changed but couldn't think of a clever way to get around the lack of a filetime() function. > PS - I have a solution to the first one, not real fast, but it works! Please share it. Well, here's some other ideas that come right to mind: 1) a function to return the current color/mono attributes of the character under the cursor. I can return the cursorchar(), but not its attributes. 2) a function or mechanism to return the currently selected color combination in the color pallette. I wrote two functions to color a selected text lablel or field for form design. I could have really used a paintworkspace command. As it stands I have to pop up the color pallette and do a getchar() loop to force the user to select the color combination before continuing. If I can't get a paintworkspace command, I'd settle for way of knowing where I am in the pallette, then I can fumble under program control for the color combination I need. 3) the ability to write to the workspace on the fly. I would love to have the ability to create a generic form and fill in portions. For example, a form could have at the bottom: [Customer ] I would like to fill in "Edit" or "View". You can paint those words on the canvas, but as soon as you Wait <table|record>, they go poof. This would only be a temporary change and not recorded in the form spec. I could fake the keystrokes to use the form editor and edit the form on the fly before using it, but that's an unelegant hack, IMHO. Peace, dNb
byock@umaxc.weeg.uiowa.edu (Bill Yock) (04/13/91)
From article <1991Apr09.224033.1497@vpnet.chi.il.us>, by kji@vpnet.chi.il.us (Ken Isacson): > Here is the start of a list of what I think is missing from Paradox 3.5: > 1) A function to get the time of file, such as filetime(fname). They > 2) The ability to save the PAL canvas to a buffer. Including all the > colors! > If you have any additions to this list or would like to place your suggestions > for possible solutions, I sure would like to hear them. > PS - I have a solution to the first one, not real fast, but it works! > __________________________________________________________ > Ken Isacson Sysop - Board Of Trade BBS GT 016/001 > kji@vpnet.chi.il.us (815) 753 - 0042 > ---------------------------------------------------------- Could you explain what it is your trying to do with these wish list items? What was your work around to number 1? The PAL canvas is just a curtain over the PAL workspace where you can paint prompts and messages to the user. To redraw a canvas simply invoke a procedure that has a Text ..Endtext or Output commands in it. You can use the Paintcanvas command to style and color areas of the canvas and you can use the Canvas command to hide incremental painting of the canvas until the painting is complete. Coming from an art background I just love these analogies. -- Bill Yock, Weeg Computing Center, University of Iowa, Iowa City, Iowa 52242 byock@umaxc.weeg.uiowa.edu
ac119@cleveland.freenet.edu (Neil Parks) (04/14/91)
How about an option to get a FormView of a Lookup table when using "HelpAndFill"? What I mean is: In data entry, I have put a ValCheck into a particular field requiring that all entries in that field must be found in another table. The user presses F1 to view that lookup table in "Table View", and then selects a record and presses F2. But I want the user to see my lookup table in Form view sted Table View. ------------------------------ NEIL EDWARD PARKS (Internet) ac119@cleveland.freenet.edu (Fidonet) 157/511 (Appleholics) (GT) 22/9 (Akademia) "Let's Go Mets!" ----------------------------- --
gribble@ogre.cica.indiana.edu (04/15/91)
-Support for Time data type -Support for Memo fields (i know you can use add-ons, but they are cumbersome) -Auto-Increment Keys -Support for Referential Integrity (enforcing at Table level) -Support for Foreign Keys -a Compiler just for starters... -- ************************************************************************** * Steve Gribble (812) 855-9172/7629 gribble@cica.cica.indiana.edu * Systems Manager, Inst. of Social Research swg@socmail.soc.indiana.edu * Dept. of Sociology, Indiana University gribble@iubacs
klox@otago.ac.nz (04/16/91)
My $0.02 worth: A postscript driver for report printing (there is one for graphs) KLox
glenn@welch.jhu.edu (Glenn M. Mason) (04/16/91)
In article <1991Apr16.080947.289@otago.ac.nz> klox@otago.ac.nz writes: >My $0.02 worth: > >A postscript driver for report printing (there is one for graphs) How about functions for DOS file I/O? How about a source generator for forms, reports and tables that will document database structures and provide means for recreating damaged or lost files? How about a compiler? How about a Windows-based interface toolkit? How about more high level application functions like pop-up dialogs and menus, pull-down menu systems, etc.? How about mouse control for development environment and for applications? How about a printer status function that returns a status in under an hour (I wrote a tiny C program to run underneath Paradox to do this which is about 100 times faster than the built in function on a 386 w/couple meg of RAM ... I can't believe they can't improve the speed of this function)? I'm not complaining, btw, I think Paradox is an excellent product. I would just hope to see some of these features in future releases. Glenn
bressler@lwtua6.sdi.sub.org (Stefan Bressler) (04/17/91)
In article <1991Apr15.041214.11383@cica.indiana.edu> gribble@ogre.cica.indiana.edu writes: >-Support for Time data type You can use the character type and create a validity check. Calculation is difficult but you can store time data. >-Support for Memo fields (i know you can use add-ons, but they are cumbersome) They are not there but I don't miss them. The relational data model consists of tables and only tables. >-Auto-Increment Keys I have a macro for this. See addfield.sc at the end of this article. >-Support for Referential Integrity (enforcing at Table level) >-Support for Foreign Keys If you use multi table forms, these things are enforced. >-a Compiler More than that I would like a better query optimizer. For complicated queries Paradox can be very slow. Also I would like to omit the final sorting and duplicate elimination in a query. In SQL this is possible, too. mfg Stefan Bressler ; ----------------------------------------------------- ; addfield.sc by Stefan Bressler (bressler@sdi.sub.org) ; put into init.sc: setkey -30 play privdir()+"addfield" ; and use addfield.sc with Alt-A while in edit-mode. IF SYSMODE()<>"Edit" THEN MESSAGE "Use the Edit-Mode if you want to make changes." ch=GETCHAR() ELSE IF FIELDTYPE()="N" OR FIELDTYPE()="S" THEN ? "Increment actual field by? " ACCEPT "N" TO tmp IF NOT ISBLANK(tmp) THEN []=[]+tmp ENDIF RELEASE VARS tmp ELSE MESSAGE "not a numeric field." ch=GETCHAR() ENDIF ENDIF RELEASE VARS tmp,ch -- Stefan Bressler, bressler@sdi.sub.org, 089/611-67-64 Bussardstrasse 42, 8025 Unterhaching bei Muenchen, Deutschland
aa640@cleveland.Freenet.Edu (Neil Parks) (04/18/91)
Newsgroups: comp.databases Subject: Re: What is missing in Paradox 3.5 glenn@welch.jhu.edu (Glenn M. Mason) says: >How about a source generator for forms, reports and tables that will document >database structures and provide means for recreating damaged or lost files? You can document your database structures by using the Tools/Info option on the menu. That creates a "structure" table. Then you use the Report/Output function to copy the structure table to an ASCII file. Write each module of your application as a separate script, and then use Personal Programmer to generate the menus. It will also generate full documentation of the menu hierarchy and all files used. As for recovering damaged files, there is something called a "TUtility" which claims to be able to do that. Happily, I have not had any occasion to test that claim. >How about a compiler? That would be nice. But the "procedure library" is the next best thing. Store all your source code in the form of procedures, write it into libraries, and load it with the "autolib" function. BTW, I was just reading a comparative review of Paradox 3.5 and other DBMS's in PC World. Paradox Runtime costs $49.95. The competitors who offer runtime code charge not less than five hundred bucks. >How about more high level application functions like pop-up dialogs and >menus, pull-down menu systems, etc.? I guess you haven't tried the Data Entry Toolkit. Just store the procedures in POPUP.SC in a library, and call SetPopUp and PopUp in your application. It is quick and easy. -- NEIL EDWARD PARKS >INTERNET: ac119@cleveland.freenet.edu (Fidonet) 157/511 (Appleholics) (GT) 22/9 (Akademia)
glenn@welch.jhu.edu (Glenn M. Mason) (04/18/91)
In article <9104180445.AA01554@cwns4.INS.CWRU.Edu> aa640@cleveland.Freenet.Edu writes: > >Newsgroups: comp.databases >Subject: Re: What is missing in Paradox 3.5 > >glenn@welch.jhu.edu (Glenn M. Mason) says: > >>How about a source generator for forms, reports and tables that will >document >>database structures and provide means for recreating damaged or lost >files? > >You can document your database structures by using the Tools/Info option >on >the menu. That creates a "structure" table. Then you use the >Report/Output >function to copy the structure table to an ASCII file. This wouldn't do a fraction of what I'd be interested in seeing. This does provide some documentation for table structures, but most of the tedious work is in the reports and forms. I would like to see an option that produces *real* PAL code that would recreate a form, report or table at any time. Such a script would have been produced simply by selecting a table, form or report and an appropriate Paradox option to perform the action. This is the ultimate level of documentation and backup-recovery for *all* objects generated from within the Paradox development environment that are output in a binary format. >Write each module of your application as a separate script, and then use >Personal Programmer to generate the menus. It will also generate full >documentation of the menu hierarchy and all files used. > >As for recovering damaged files, there is something called a "TUtility" >which >claims to be able to do that. Happily, I have not had any occasion to >test >that claim. Yes this utility has proved useful to me, but only rebuilds damaged indexes. It would not be very useful in a situation where a table has been damaged due to a power loss of some sort during a critical table update or other types of PC or DOS related occurrances such as disk crashes. >>How about a compiler? > >That would be nice. But the "procedure library" is the next best thing. >Store all your source code in the form of procedures, write it into >libraries, >and load it with the "autolib" function. Yes it is the next best thing, and the built in memory management really makes it a useful implementation, but ... it simply can never compare to the raw execution speed of a DOS executable. Borland certainly would be the right company to produce a good compiler for Paradox since they have some of the leading PC-based compiler technology; and I wouldn't be suprised to see them come out with a compiler that has overlay management capabilities since their other compiler products have this available. I see that PAL compilers are beginning to pop up now - TSR Systems is marketing PalCom which would provide what I would look for in a compiler (it does have some limitations though), but at a price tag of ~1500. I can't justify buying it for a product that I paid $134. for!-) You can bet that Borland will release a future version of Paradox with a compiler that will probably be unmatched by any competition for a price that everyone can afford. >BTW, I was just reading a comparative review of Paradox 3.5 and other >DBMS's >in PC World. Paradox Runtime costs $49.95. The competitors who offer >runtime >code charge not less than five hundred bucks. Yes I am currently using this. It is actually a version of Paradox that is exactly the same except that the ECHO function has been disabled. It's easy to see why they wouldn't include that function in the runtime module. So you can expect that exact same performance from an application using Runtime that you would under Paradox itself. >>How about more high level application functions like pop-up dialogs and >>menus, pull-down menu systems, etc.? > >I guess you haven't tried the Data Entry Toolkit. Just store the >procedures >in POPUP.SC in a library, and call SetPopUp and PopUp in your >application. It >is quick and easy. I have used the Data Entry toolkit extensively ... enough to have had to rewrite some of the code to suit my personal tastes. The PopUp2 function, for example, has the limitation of not allowing flexible color attribute specs (they are read from the current attribute settings table). There are other minor things that I have changed as well ... but I am happy at least that the source for these critters was included so that I *could* hack them. As for the high-level functions, I have created a library full of these things, but it was tedious work and there are other functions that I would like to have but have not had the time to genericize from my current applications. I think that Borland could supply the PAL source code to build a Paradox library of many of these things that are very general to fit a wide variety of application needs. I think many of these things would justify a quick purchase of the next Paradox release. I also found out that Borland is showing off its Windows-based version of Paradox ... can't wait to see that. Glenn
sel@vega.hut.fi (Sami El-Mahgary) (04/22/91)
I think Paradox is already a powerful and robust DBMS and has a great programming language, PAL. Like any software it does have a few defiencies: - slow search speed for large tables (LOCATE command) - query optimization is weak - selecting a multitable form can be slow (PICKFORM command) Put simply, I think speed is what needs to be enhanced the most. If Borland can do that they can look forward to greatly increasing their market share. Compilers, colors, & Windows support are nice, but raw speed is what most users are after. ------------------------------------------------------------------------------ Sami El-Mahgary sel@saavi.hut.fi Tel 358-0-451 3236 System Error: Cannot find .signature
tomr@dbase.A-T.COM (Tom Rombouts) (04/25/91)
In article <678@lwtua6.sdi.sub.org> bressler@lwtua6.sdi.sub.org (Stefan Bressler) writes: [ Most of discussion of things missing in Paradox 3.5 deleted ] > >>-Support for Memo fields (i know you can use add-ons, but they are cumbersome) >They are not there but I don't miss them. The relational data model >consists of tables and only tables. I feel that memo fields have nothing to do with the relational model. To me, they can be viewed as just very large character fields. Imagine the following hypothetical SQL statement: CREATE TABLE Coffee ( Emp_ID CHAR(5), Lastname CHAR(20), Firstname CHAR(15), Comments CHAR(65000) ); This would effectively create "Comments" as a memo field. (Of course, let's hope this would not result in 65000 spaces added to each record! That would depend on the particular data engine in use.) Anyway, I do not see how a very wide character field violates the relational model in any way. Perhaps you are thinking of sub-fields, such as those found in the Pick OS, which clearly violate the guidelines of data normalization. (BTW, yes, I know that memo fields in many products can also hold binary data. However, I do believe C.J. Date mentions the possibility of future data types in his "Introduction to Database Systems" 5th Ed.) Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com