--------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ECU00001 Date: 08/20/97 From: JEAN MENTEN Time: 11:25am \/To: DENIS BRAUSSEN (Read 0 times) Subj: Clipper -> Windows ! What Hallo Denis, DB> 1) DB> for my part, i've chosen Clip4Win. it's a third part library DB> which provide a FULL access to windows' API and allows you DB> to build REAL windows EXE. (but only 16 bits :( ) I'm trying to learn some Clip4win-programming........but......it's so hard to find someone who can give you some hints or tips. It seems to me that there are only very few Clip4winners on earth. As for now I'm compiling the examples provided with the library. I have got the impression that not every example is a working example. Could you tell me more about this ? Do you know if there ara any books available on the Clip4win topic ? DB> In conclusion, I'm _totally_ satisfied with Clip4Win. (very good, DB> very stable and mostly bug free library Glad to hear. DB> with an excellent HotLine DB> provided by its author, John Skelton himself ! ) Do you need an internet account for getting help? Can you get help by fido ? Groetjes, Jean Menten 2:292/120.136 --- * Origin: Digital Contact (2:292/120.136) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ECU00002 Date: 08/25/97 From: RICHARD STRICKLAND Time: 04:38am \/To: IGOR IVANOV (Read 0 times) Subj: Problem This problem is known of. There is a problem with the processor running too fast. If you have access to the Internet, go out to the Oasis (www.iag.net/~philb) to solve this problem. Look for a file called R6003FIX.ZIP. If you do not have access to the Internet and cannot find it on a local BBS, let me know. I can UUENCODE the file to you. This fixes the problem with the processor. You need to run it everytime you start-up the machine if you are going to run a Clipper application. This problems is also know to occur with the Cyrix chip. --- Alexi/Mail 2.02b (#12) * Origin: Database Connections BBS * USR DS * 281-980-3234 (1:106/4196) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ECW00000 Date: 08/25/97 From: DENIS BRAUSSEN Time: 08:59pm \/To: ERIK WACHTMEESTER (Read 0 times) Subj: Clip4win Erik Wachtmeester, In a message on 14 August, you wrote to me : EW> Reply-To: erik.wachtmeester@bighole.iaf.nl EW> Denis Braussen wrote in a message to Jean Menten: EW> EW> JM> I'm trying to get acquainted with the clipper add-on library EW> JM> CLIP4WIN. I'v got some questions about this library: EW> EW> DB> nice idea, excellent choice. :-)) EW> DB> Clip4win is a (very good) library wich allow you to write REAL EW> DB> WINDOWS EXE (but only in 16 bits, because Clipper makes 16 EW> DB> bits *.obj) The structure of your PRG is, in such a windows EW> DB> style programming, very close from C style. (BUT, last Version EW> DB> of Clip4Win include an OOP engine which allow you to create EW> DB> your own classes...) EW> EW> Hmm. I'm quite new to Windows programming, but wouldn't it be asier/bette EW> write a user interface in e.g. Delphi, C++ Builder or Visual C++ that EW> communicates with a Clipper engine on the background through named pipes EW> shared memory? I don't know if a Clipper library that supports named ipes EW> shared memory exists, but if yes, you've got a much more flexible olution EW> Thefront end could also been written for OS/2, X11, System7, Java, etc., EW> theClipper engine could be running on another machine (maybe even upporti EW> different clients). The latter would only work with named pipes of ourse, EW> because shared memory over different machines just isn't possible... nice idea... but it seems to be difficult to do it :( i've never heard about such pipes. Besides CLIPPER makes 16 bits exe and programs like DELPHI, C++ Builder are 32 bits App. So you have to call within a 16 bits exe 32 bits *.dll and vice et versa (i've red something about that: it's something named 'THUNK' (there are some build in Win95 for compatibility with old 16 bits apps). it was very hard stuff, impossible (IMHO) to make it with clipper :( ) -------->BUT i've heard that John Skelton will implement such call (16->32) in the next release aof Clip4Win.(?) ?:-/ That will allow you to call 32 bits *.dll like R&R (report maker) for instance) <------------ It's perhaps possible to only make somme 'call' to external clipper module (exe) ? IMHO, it's possible, but complex (too many small clipper *.exe, you need also to maintain a lot of temporary files for transmitting parameters for instance) that sounds to me like the (bad) (very) old basic ands its (ugly) RUN "C:\..." within a pgm :-) 'pipe' are only well implemented on UNIX plateform (you can try LINUX :-)) ). halas, UNIX is not so easy (IMHO) to use as MS-DOS and even windows programming. in conclusion, i think that if your custommers don't _really_ insist to have a 'windows look & feel', you can continue to produce (good) old clipper *.exe in ms-dos mode. If you really wants to continue using the (exellent) old (good) :-)) clipper AND having a windows look&feel, IMHO, the best choice is Clip4Win (perhaps FiveWin, but i've not tried it yet). Windows programming is not so difficult after all ... Best regards from France, Denis. - --- )\ ___ _ /\_('')/\ Bien Amicalement, | \ ___ _ _ (_)___ - -- \__ __/ Best regards, | |) / -_) ' \| (_-< _/ \ FidoNet 2:325/200 |___/\___|_||_|_/__/ --- \____/ --e-mail--> denis.braussen@suptel.frmug.org --- ATP/Linux 1.50 Origin: - SuPTeL NaNCy BBS -(33)- 03 83 53 16 17 -8N1- --- QScan/PCB v1.19b / 01-0633 * Origin: SUPTEL NANCY - 3 USR V34+ - 4 ALTO V34 - 33-83532021 (2:325/200) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ECZ00000 Date: 08/27/97 From: RAYMOND PESEK Time: 11:58pm \/To: RICHARD STRICKLAND (Read 0 times) Subj: Problem BRS ->This problem is known of. There is a problem with the processor ->running too fast. The problem is that the K5 uses memory pipelining and this is causing a software timing loop in Tools III to run far faster than it was ever thought it could. RS ->This fixes the problem with the processor. It's _not_ a problem with the processor. It's simply a problem that popped up from running "old" technology programs on new technology CPUs. RS ->You need to run it everytime you start-up the program. It's linked into the program so it doesn't have to be run separately. RS ->This problems is also know to occur with the Cyrix chip. Correct. Cyrix provided a program named PIPELOOP.EXE that had to be run each time the computer started up to slow down the computer, which has the unfortunate effect of slowing down everything. RS ->Look for a file called R6003FIX.ZIP. I can UUENCODE the file to ->you. I'll save you the trouble. Here t'is: section 1 of 1 of file r6003fix.zip < uuencode 95 (v40) by R.E.M. > begin 644 r6003fix.zip M4$L#!!0``H`(`'27E2$)Y"ZP[04``+P+```*````4D5!1$U%+E185&U686_-XLO5OD-1%'7<-+=I[[SP.DC[*>"2HUV>*5)'4I8WO[XS" M(\E>IS%@PY*&Y)OWWLSP[H"`T894T$':_8ZV0NL#PI-3?O/H(O_ M,'!`3?3Q$0ST.>T"=C#Z>M#J.OB^QPRF[X.WIOH4"U3,G8_T$/=@*I1JJ\S8GVM'16RH4/P8(2.X7`]>93@3P0])+:.M(Y4'W':8:4^G(&)1$0TWM'* M..J!P<+W(J%+;B"FQX.W!Z:X9X8(UV\FUL'>8]7J+J508+TFIAQ<7[U>GM=@U M38RIPICR/9@R8T/7P&])V`$)U:H=HIT$(06%@.]A6<%NJ,062TC,%59ZAQ!\M MO&<68Z64CFEX(3'X%NC=*]II*+S1+"J?<7WW:2O.(=7X_PT_:(6/%:-CMK-_X M0&;W"EIBML?4$Q,'\X"D7)]R9;.=JLOR)8)((7245M\]X!EOHQ611T#JF.!9L M3;!#SI-!\/'@=U[<*0?9%)V7M(0:6GKUZS_@7Q=:"?7'[!_A\O'G2X)<6"190 M-&;9826Q1(V9-S^0(C'!6>L?SZ9@]%FK-,85RTVI3AMRG)G#^E0X:P(@T3#B: M#HJO[':M#K7V?WGS9AS'QO+*QJ8.0,Q)H5R3A+_X4@6;B90>VJ$:X@ZBZ=!I> MM5EOWO_[YF;3O/_/^\F6?K)QFVDO2?C3W0U]O&[>7=U-38!3MV8H6&:S:"4>U MG^U10AI93,J+:(E)Y)^R\1)3AQP)D!#`+L(<3=#*&GO`U6S\T8<`;%[?>FN$6 M/H?[;!R*C7O,;PCKN(H5U:[F8^3H[7/5)Q^^C\S"V,K+@J&0%A/? M^1:.)\T%*804]YBUBHB.H]?DB.*OIWJ:BI2R%HN1_ER!/D5Q4<97C&L"Q+QTAO2BE M7VY>V)ML*C+9)$RW+`02!M:D:H#3AKFN6C&V0HP0!JXHTI%XC$[<*4K`-D%K. M<@-_W?]MJ56Q'+N50!8,+5$57]53;\P\_2X22D^6<.Y.SKW_]7J]?2CU18IQ`0X2ONDY=2 M/VPQ/Z"XX`/;*^6A(X[V`P\V[H6,;?$_^V-!Q/4_C7*MGCAU\T3G/BDN8HGH! M+=<718:C4/-YR;DPK\OF&=D>M;H_EJ\D./@2SX\T^FUS,G MN()-HD5.R-L.NX)_#-,(\%4.F?.>'7*"[!3-=!'0:AJ^>2I`&8;)6L/P38`/. MFW\NI)4&?C7!PO:`SJ'D]HY;V#I:2CB%(5;$>1LZ'G,U][BP+E<\^I"1IQ=.0 MV.:KB!&LR/>H,@29$*?WP-7S785E6CVGM)*E`H*8

AG6DWUA+J!K8\6P M%V*>R\=_V_IV1W#I*T:I%E*BI%BF,>RKM+36/\K]X-E%/YR?_VGIV=5W/%S8H MJ&97B(V*I`?WMH6^IY[8P"]IY,I?P3UBS_[KO'!@Y#9DF3H?GR9Z%9Q:S4#]J MU-ILHKS\@PQ;C`\^I]AAK-P*Y8;$?=`]7YJ)-DF=6688=-!\73'QGHM(JUMST MA`T6O-?JI[=O?SIO+B_._\Y4QP. M8.B[T+:1 M![4/=I_8P<+PS/F)@]61K@=/'$J^/?IR&*CL-/>!$H70[C=S?@<#>=VW@(3U\ MK9*?'J4?O[O]8V`J9?P5/3?V\/PYD@PM"@R,C%X,+>Y`2HBA)92%D;$E"DCLI M[&)B8"@!`%!+`P04``(`"`#M,Y,A>2!-@?0```!0`0``"P```$9)3$5?240NM M1$E:-5!-:\,P#+T'\A\>.:^E,%9V+=TE=*-CZWZ`FZB)AFT9V5G3_?HIA5V$' MD=Z7WVDDR/F;NH(+>T(GL3B.U&,D)8ZVG2G#U552.7L*N(X4X;#WG!(I;#VHQ M"YBRP3K2A5U7^]WJ=#R^?J)M6URFV!66:#*Q!V?H%"%WD9OR7%?;^7D+43MC* M]_:"PQ/V[U]K6+9,*%=93#K*6337U4(N'#@.\"(I(PLN+A>4T2V#_J/=(]^S? M<0C4LROD;RBDQK5WQI7+N'B2JA@ZF(,;Z,&^,CEOT.9CN]D\HN*OB^G]`````P$```P``````````0`@````%08``%]?5T%)5%]"+D]"7 M2E!+`0(4`!0``@`(`.TSDR%Y($V!]````%`!```+``````````$`(````#P'( C``!&24Q%7TE$+D1)6E!+!08``````P`#`*L```!9"``````5 `` end sum -r/size 34501/3293 section (from "begin" to "end") sum -r/size 44188/2330 entire input file Raymond Pesek * 1st 2.00 #2448 * Moderator - Clipper Echo --- InterEcho 1.19 * Origin: PC-Ohio PCBoard * Cleveland, OH * 216-381-3320 (1:157/200) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ECZ00001 Date: 08/29/97 From: CLIPPER Time: 07:24pm \/To: CLIPPER (Read 0 times) Subj: Problem with Protected mode lib of dGE * Original From: Hp Van Den Akker (1:365/3253) * Original To : Dge-Users (1:365/3253) Whenever a protected mode clipper apllication (linked with EXOspace) is running in a DOS-box of Win 3.11/Win '95 and is switching to its dGE graphics screen, it crashes. We use the protected mode lib of dGE, but the problem still exists. What causes this and what can we do about it ? --- Maximus/2 3.01 * Origin: . Gargoyle's_OS/2_Place_904-236-2320_FIDO# (1:365/3253) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ECZ00002 Date: 08/30/97 From: RICHARD STRICKLAND Time: 09:01am \/To: RAYMOND PESEK (Read 0 times) Subj: Problem I already had the file from Cyrix. The divide by zero problem is what I was adressing per user having a question about it in a Clipper program. Though, not everyone is familiar with the problem, as a user (?) had a question about it. --- Alexi/Mail 2.02b (#12) * Origin: Database Connections BBS * USR DS * 281-980-3234 (1:106/4196) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ED400000 Date: 08/31/97 From: PETER SYKORA Time: 04:59pm \/To: ALL (Read 0 times) Subj: Summer '87 I've got to maintaine 'old' application written in Summer '87 and I'm desperately seeking a library for this version of clipper to be able to control a HP Laserjets 4/4M, 5P and 5L. I wasn't able to find any yet; neather on internet. Internet replays to psykora@freemail.nl Any help is welcome.. --- * Origin: New Age always changing **31-50-5790858 (2:282/1.9) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ED400001 Date: 09/01/97 From: ERIK WACHTMEESTER Time: 06:39pm \/To: DENIS BRAUSSEN (Read 0 times) Subj: Clip4win Reply-To: erik.wachtmeester@bighole.iaf.nl Denis Braussen wrote in a message to Erik Wachtmeester: EW> write a user interface in e.g. Delphi, C++ Builder or Visual C++ that EW> communicates with a Clipper engine on the background through named EW> pipes or shared memory? DB> nice idea... DB> but it seems to be difficult to do it :( DB> i've never heard about such pipes. Both named and anonymous pipes are quite well known mechanisms in networking environments, but I've just read an 1100 page book on NT ('Windows NT 4 erver Unleashed'), and pipes weren't mentioned even once. Could it be that Windows doesn't support these, maybe because MS has got it's own Windows messaging, OLE2, DAO, etc.? DB> Besides CLIPPER makes 16 bits exe and programs like DELPHI, C++ DB> Builder are 32 bits App. So you have to call within a 16 bits exe DB> 32 bits *.dll and vice et versa (i've red something about that: DB> it's something named 'THUNK' (there are some build in Win95 for DB> compatibility with old 16 bits apps). it was very hard stuff, DB> impossible (IMHO) to make it with clipper :( ) Thunking is indeed not the simplest thing to do, but if the 16-bit database + business engine and the 32-bit user interface each are running in their own process, the thunking part is done by the operating system. And with W95 and NT MS has shown that they do know how to deal with thunking... DB> -------->BUT i've heard that John Skelton will implement such DB> call (16->32) in the next release aof Clip4Win.(?) DB> ?:-/ That will allow you to call 32 bits *.dll like R&R DB> (report maker) for instance) <------------ In that case you let your Clipper engine handle everything, and yes, you (or Skelton) will have to deal with thunking yourself. I don't know R&R, but I've fiddled with Crystal Reports, ReportSmith and ReportPrinter Pro (for Apollo), but at the moment I prefer QuickReport. Not directly usable in Clipper (maybe when Skelton dealt with this thunking?) but in Delphi or C++Builder it's a breeze: no external programs or dll's to distribute, the possibility to work with data that don't come out of your database directly but from e.g. a richedit component, and all and all it really is quick. A lot faster than Crystal anyway. Maybe ReportPrinter Pro is a little faster, but it's got far less options. DB> It's perhaps possible to only make somme 'call' to external DB> clipper module (exe) ? IMHO, it's possible, but complex (too DB> many small clipper *.exe, you need also to maintain a lot of DB> temporary files for transmitting parameters for instance) DB> that sounds to me like the (bad) (very) old basic ands DB> its (ugly) RUN "C:\..." within a pgm :-) You're thinking in DOS terms now. On a decent operating system more than one program can run side by side, and can exchange information directly, without the need for temporary files. Any real multitasking OS supports things like semaphores (not 'semaphore files'), shared memory and pipes and/or messaging. No spawning would be needed, because both tasks are running concurrently, watching eachother... DB> 'pipe' are only well implemented on UNIX plateform (you can try DB> LINUX :-)) ). halas, UNIX is not so easy (IMHO) to use as MS-DOS DB> and even windows programming. OS/2 handles them quite nicely too, and so does NetWare. But in a Windows environment it's maybe smarter to look at the Windows API (messaging, OLE) nd use these. But the general idea stays the same. Clipper is a great xBASE development system for DOS, but both xBASE and (character based) DOS are overhauled by (inter-)networking, client/server DBMS's and GUI's like Windows. You can try to keep your Clipper code alive (e.g. ith Clip4Win or with the foreground/background schedule I proposed), but it'll always be a kludge... DB> in conclusion, i think that if your custommers don't _really_ DB> insist to have a 'windows look & feel', you can continue to DB> produce (good) old clipper *.exe in ms-dos mode. Existing customers will not insist on a GUI, but new customers won't give a blink at your character based application, even if it sings and dances for them. This may not be true for all branches, but the great majority of the people looking for a hotel property management system are looking for a indows-based system. At the moment we can offer them a thoroughly tested Clipper version with all bells and whistles one could ask for and a fresh Win32 version (Delphi/InterBase) that at the moment has a lot less functionality than the Clipper version, but looks a lot smarter. And the Win32 version sells 3 times as fast as the Clipper version... Regards, Erik --- * Origin: May it be on this earth? (2:283/7.2) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: ED500000 Date: 09/03/97 From: JOOP BUKER Time: 11:13pm \/To: ALL (Read 0 times) Subj: Low ASCII in database I am working with Clipper 5.2. I want to use low ASCII symbols with their values in a database, for instance the two smileys CHR(001) and CHR(002), or the heart CHR(003), the diamond CHR(004), etc., the male sign CHR(011) and the female sign CHR(012). I have tried to enter them in a field with DBU: typing 003 while holding the ALT-key; or within a programm: REPLACE XXX WITH CHR(003). But that doesn't work, although this procedure works fine for high ASCII symbols, for instance CHR(137) or CHR(219). The reason I want to use these low ASCII symbols is that I want to put ntries of different length, one after another in a field. The symbols must work as markers that separate the strings while keeping the index in order and don't make it a ruin, what high ASCII symbols would do. To give an example of some records with names (but it can be every other entry): record 1: Johnston John Mr. ^ ^ ^ indicates where marker must come record 2: Johnstons Jane Mrs. ^ ^ If I would use high ASCII symbols as separators record 2 would come above record 1 in the indexed database, and that's not what I want. Is there anybody who has a solution for this problem. Greetings Joop Buker (Holland). --- FMail 1.02 * Origin: endaal +31-318-555956/ISDN 548095 (2:283/218.418) --------------- FIDO MESSAGE AREA==> TOPIC: 202 CLIPPER Ref: EDA00000 Date: 09/03/97 From: SERGEY SOUKHANOV Time: 09:54pm \/To: ALEX USOV (Read 0 times) Subj: future coders and programmers *** ⢥ ᮮ饭, 襥 TALKS.ASM (Echos from 2:460/113). p, Alex! y y 30 1997 Alex Usov wrote to ALL: [skip] AU> ᫥, ⥫ ⬥: ᠬ ᨫ쭠 ஭ AU> ᮢ६ ᥬ - ꥪ . ⠭ AU> ம।ﬨ ᥬ, ਮ⠥ ᮢ襭 AU> 砭. H ᯮ, ஡... ? p, p :( Bye! SY, Sergey. E-mail: Home@SNS.Crimea.UA [। 03 1997 21:54 +0300] --- GoldEd 3.00.Alpha4+ * Origin: "६" ⥡ 誮 襭... (2:460/113.50)