--------------- FIDO MESSAGE AREA==> TOPIC: 139 FOXPRO Ref: E1K00000 Date: 01/15/97 From: GLEN HARNESS Time: 10:05pm \/To: DAVID POWELL (Read 2 times) Subj: 2 FPLib() TOC DP> I've been assembling them. I believe Cy Welch has them available at his DP> site on the Internet. I do not have a site or I'd make them available DP> from me, too. OK, I just thought you had them zipped up and they were generally available for file request... DP> Thanks for the interest and I would encourage your input as well. I'll see what I've got. I would be happy to get them from Cy and make them available for file request for others... Glen --- Maximus 3.01 * Origin: Strawberry Fields (1:116/5) --------------- FIDO MESSAGE AREA==> TOPIC: 139 FOXPRO Ref: E1L00000 Date: 01/15/97 From: DEN BARNES Time: 11:50pm \/To: BILL KRESSBACH (Read 2 times) Subj: FINALLY! Hi Bill, Thank You so much for the correction. I will update my FoxPro Infobase accordingly. I am sure Abber will appreciate Your more accurate address. Happy New Year's to Ya, den --- TMail v1.31.5 * Origin: Diablo Valley PCUG-BBS, Walnut Creek, CA 510/943-6238 (1:161/55) --------------- FIDO MESSAGE AREA==> TOPIC: 139 FOXPRO Ref: E1M00000 Date: 01/17/97 From: DAVID POWELL Time: 07:56pm \/To: GLEN HARNESS (Read 2 times) Subj: 2 FPLib() TOC Hi Glen: No problem. They ARE zipped inside a .dbf/.fpt combination. Let me know if can help in any way. David in Dallas. --- Maximus/2 3.01 * Origin: * MacSavvy OS/2 BBS * Dallas, Texas * 972-250-4479 * (1:124/1208) --------------- FIDO MESSAGE AREA==> TOPIC: 139 FOXPRO Ref: E1M00001 Date: 01/17/97 From: BILL KRESSBACH Time: 07:46pm \/To: DAVID POWELL (Read 2 times) Subj: 2 FPLib() TOC -> RunMain.prg received. And many thanks! -> The other two were WallPapr from John Thornton and MsgBox() for DOS. Don't have WallPapr. Stange! Here's MsgBox. *********************************************************************** > BBS: MUG Club BBS (517) 263-2061 Date: Tue, 06-04-96 (22:56) Number: 748 Refer: 0 To: David POWELL From: Renaud MAVRE Subj: INI functions & MSGBOX (3 Conf: Foxpro (13) Read: No Status: Public ============================================================================= * Forwarded by Renaud MAVRE (2:321/1.14) * Area : YOUWROTE * From : Renaud MAVRE, 2:321/1.14 (Tuesday, 12 March 1996 18:20:48) * To : John THORNTON * Subj : INI functions & MSGBOX (3/3) ============================================================================= Hi John, Here is the last part of my message : *!**************************************************************************** *! Function........: MSGBOX (for DOS) *! Author..........: Renaud MAVRE *! Project.........: FoxPro Library() *! Created.........: 1994 *! Copyright.......: Freeware *! Platform........: FoxPro DOS *! Description.....: Simulate the MsgBox() of Foxpro Windows *! Syntax..........: [Response]=MsgBox(Message, Title, Typebutton, Colscheme) *! Parameter list..: Message : message to be displayed *! Title : title of the message box *! Typebutton : kind of buttons set : *! 0 : [OK] *! 1 : [OK] & [Cancel] *! 3 : [Yes] & [No] & [Cancel] *! 4 : [Yes] & [No] *! 5 : [Repeat] & [Cancel] *! 9 : [Cancel] & [OK] *! Colscheme : color scheme to use (default : 7, red) *! Response : a figure corresponding to the kind of *! button chosen by the user : *! 1 : [OK] *! 2 : [Cancel] *! 4 : [Repeat] *! 5 : [Ignore] *! 6 : [Yes] *! 7 : [No] *! Called by.......: Any *! Calls...........: None *! Examples........: =MsgBox("Time to lunch !","Information",6,6) *! IF MsgBox("Start backup ?","Attention",3)=1 ... *! Notes...........: The default button is always the leftmost one. *! Any kind of other buttons sets can be added. *!**************************************************************************** FUNCTION MsgBox PARAMETERS wMessage, wTitre, wTypebout, wColscheme PRIVATE ALL LIKE w* PRIVATE zChoixNum * The color scheme is set to 7 (red background) if not supplied IF TYPE("wColscheme")="L" wColscheme = 7 ENDIF wFenetre = SYS(3) wLigne = 10 DIMENSION wButton(7) wButton[1] = "OK" wButton[2] = "Cancel" wButton[3] = "" wButton[4] = "Repeat" wButton[5] = "Ignore" wButton[6] = "Yes" wButton[7] = "No" DO CASE CASE wTypebout=0 wLibelle = "\!\?\ TOPIC: 139 FOXPRO Ref: E1M00002 Date: 01/17/97 From: BILL KRESSBACH Time: 07:46pm \/To: DAVID POWELL (Read 2 times) Subj: 2 FPLib() TOC (Continued from previous message) wColdeb = INT(((80-MAX(wLongbout,LEN(wMessage),LEN(wTitre))-4)/2)) wColfin = wColdeb+MAX(wLongbout,LEN(wMessage),; LEN(wTitre))+3+IIF(LEN(wMessage) TOPIC: 139 FOXPRO Ref: E1P00000 Date: 01/18/97 From: DEN BARNES Time: 10:25pm \/To: RANDELL BOSMA (Read 2 times) Subj: FoxDoc in FPWindows Hi Randy, Well I finally tracked down the Official Ms. Bug report on the Left Margin problem. All it adds is that the problem effects not only FPW 2.5, 2.5A, 2.5B and 2.6, but 2.6A as well. I can not even tell from this if it ever got fixed: DOCUMENT:Q115051 26-JUN-1995 [foxpro] TITLE :BUG: SET MARGIN Does Not Work in FoxPro for Mac or Windows PRODUCT :Microsoft FoxPro PROD/VER:2.50b 2.50c | 2.5x 2.60 2.60a OPER/SYS:MACINTOSH | WINDOWS KEYWORDS:kbprint kbbuglist -------------------------------------------------------------------- The information in this article applies to: - Microsoft FoxPro for Macintosh, versions 2.5b, 2.5c - Microsoft FoxPro for Windows, versions 2.5x, 2.6, 2.6a -------------------------------------------------------------------- SYMPTOMS ======== SET MARGIN does not affect the left margin when you are printing in FoxPro for Macintosh or FoxPro for Windows. STATUS ====== Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available. MORE INFORMATION ================ SET MARGIN is used to set the left offset of printing. It works correctly in FoxBASE+/Mac. Steps to Reproduce Problem -------------------------- The following program illustrates the problem: SET PRINT ON SET MARGIN TO 0 ? "This text should start at column 0" SET MARGIN TO 15 ? "This text should start at column 15" SET PRINT OFF SET PRINT TO Additional reference words: FoxMac FoxWin buglist2.50a buglist2.50b buglist2.50c buglist2.60 buglist2.60a 2.50a 2.50b 2.50c 2.60 2.60a KBCategory: kbprint kbbuglist KBSubcategory: FxprintGeneral ============================================================================= Copyright Microsoft Corporation 1995. --- TMail v1.31.5 * Origin: Diablo Valley PCUG-BBS, Walnut Creek, CA 510/943-6238 (1:161/55) --------------- FIDO MESSAGE AREA==> TOPIC: 139 FOXPRO Ref: E1P00001 Date: 01/19/97 From: RENALD LOIGNON Time: 08:39pm \/To: ALL (Read 2 times) Subj: CALCULATE, naming conventions ============================================================================= * Forwarded by renald loignon (1:167/133.100) * Area : DBASE (DBASE) * From : renald loignon, 1:167/133.100 (Sunday January 19 1997 18:35) * To : Steve Board * Subj : CALCULATE, naming conventions ============================================================================= RL>> CALCULATE [scope] MAX(fieldname) [TO memvar] SB> By golly, you're right. And it works great--much faster than my SB> use of SB> arrays. The other functions are useful to. They've got everything I SB> need but median values. Median? Is that the middle of the range of values that appear in a given field? If so, try this: CALCULATE MAX(fieldname), MIN(fieldname) to __max, __min __median = __min + ((__max - __min) / 2) SB> Thanks Renald. I owe you one. No problem. Sharing is what these electronic conferences are all about. ======================================= Speaking of sharing, and as long as I'm warmed up, here is a comment on the above lines, which may double as a possible contribution to the general field of xBASE programming. I had been meaning to write this up for a couple of years, and it's about time I got around to it: The use of underscores is a personally developed naming convention of mine for memory variables (or "memvars"). I can only vouch absolutely for the legality of this practice under Foxpro 2.x, and a quick glance at an old copy of dBASE 4 (from a customer's backup of an obsolete application) indicates it could not be used in that version (late flash: it also _works_ in Visual dBASE 5.5). The benefits of this approach are: 1) Prefixes such as m->memvarname (Foxpro or vDBASE) or m.memvarname (Foxpro) are used to force reference to a memvar when a physical field of the same name may exist in the currently selected area. However, besides adding tediousness to program coding (and a wee bit of size to program files), there is some evidence (as read in a Foxpro Advisor article) that the wholesale addition of these prefixes slows down programs by a measurable factor. Using my naming convention, the "m->" and "m." prefixes can be dropped altogether, while ensuring that no physical field name will EVER conflict with my memvars, since physical field names MUST begin with a letter. 2) When using SCATTER MEMVAR (in Foxpro) or STORE AUTOMEM or USE AUTOMEM (in vDBASE 5.5), memvars are created for all fields in the currently selected area. This could overwrite any existing memvar of the same name, which can again be prevented with absolute certainty if all programmer-defined memvars start with an underscore. 3) Foxpro 2.x and vDBASE 5.5 already define certain system parameters as memvars whose names start with an underscore, for example _PADVANCE or _WRAP. To avoid conflict with these, I name my local variables with two (or more; see below) underscores at the beginning. 4) As an extension to the above practice, I use the following additional personal conventions: global memvars start with 2 underscores, whereas local memvars start with 3 underscores. At the beginning of each program routine, I then place the following two lines: PRIVATE ALL EXCEPT _* PRIVATE ALL LIKE ___* The first line "hides" all memvars *_except_* those whose name start with at least one underscore. The second line also "hides" all memvars who names start with 3 underscores (which would be local variables defined by a program in the calling chain), leaving only the system memvars (names starting with a single underscore) and my own global memvars (starting with two underscores) visible. I then proceed to initialize my local memvars with the certainty that they will not conflict with any field or memvar used elsewhere in the application. An extra benefit is that when, in the course of debugging or modifying an application, I need to add a memvar somewhere, I do not have to concern myself with adding it to a "" in a PRIVATE statement, thereby also ensuring that I could not accidentally forget to add it. I am sure most experienced xBASE programmers have encountered situations where the omission of a variable in a PRIVATE statement caused all kinds of strange behavior because of conflict with an existing memvar of the same name... Whew! Now that I finally committed this to print, the irony is that it may already be obsolete due to new features of Visual Foxpro or other recent xBASE development environments. if anyone know of such a fact, please let me know... Still, I hope this will prove useful to some die-hard users of the classic Foxpro 2.x family or the current Visual DBASE. I would appreciate any feedback from users of dBASE 5.0 as to its applicability there. Finally, if anyone would like to repost this text elsewhere, they may do so provided they attribute it properly. I will cross-post it immediately to the FidoNet FOXPRO Echo, for starters... renald loignon (Internet: rhl@cam.org) -+- GoldED 2.50+ + Origin: Point of View (1:167/133.100) ============================================================================= Hello All! renald --- GoldED 2.50+ * Origin: Point of View (1:167/133.100)