--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EER00000 Date: 10/20/97 From: PAUL WANKADIA Time: 03:07pm \/To: NEIL HELLER (Read 2 times) Subj: VOID On 18 Oct 97, Neil Heller wrote to Paul Wankadia -- PW> Ye gods, Steven ... the term is "prototyping" ... NH> Thank you. I was dreading the thought of rewriting my communications NH> programs. I defy anyone to even THINK about saying "protoplasming" in relation to declarations of functions for a biology program... {snrk} --- PPoint 2.00 * Origin: Junyer's Workshop (1:342/1022.2) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EER00001 Date: 10/19/97 From: CAMERON CLARK Time: 08:03pm \/To: NAUMAN ABBASI (Read 2 times) Subj: Re: Visual Basic 4 CC> retVal = shell("c:\path\program.exe switches", vbHide) NA> NA> I tried the above code and it gave me a runtime error.... It never occured NA> me that I should try the value 0 instead of typing "vbHide" so I shall make NA> another attempt at this. It should unless "c:\path\program.exe" exsists. --- GEcho 1.00 * Origin: Digital OnLine Magazine! - (409)838-8237 (1:3811/350) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EER00002 Date: 10/21/97 From: JERRY COFFIN Time: 12:55am \/To: ALL (Read 2 times) Subj: Moderatorship Hello, Today I received notice that my bossnode is going to shut down on Nov. 12 of this year. I'm presently uncertain whether I'll attempt to set up as a point off of another node or not. As such, I'm going to do what I can to get a new moderator for the echo, though with the short notice, I may have to get somebody else to actually run the election. If anybody wants to volunteer to take over as moderator, please send your name to me via netmail or email - my email address is jcoffin@taeus.com and my netmail address is at the bottom of the message. The qualifications for the job are fairly simple: you must have access to email and netmail. You must have at least enough knowledge of C++ to know what's topical and what's not. Beyond that, being moderator makes you king of a little kingdom where everybody can leave at any time. As such, your word is (mostly) law within the domain, but you have to keep the laws reasonable enough that people want to stay a follow them. Otherwise, you become king of an empty country. Later, Jerry. ((soon to be ex-)C_PLUSPLUS Moderator.) --- PPoint 2.02 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EER00003 Date: 10/21/97 From: JERRY COFFIN Time: 12:36am \/To: PAUL WANKADIA (Read 2 times) Subj: node2 On (20 Oct 97) Paul Wankadia wrote to RICKEY JENKINS... PW> Jerry Coffin, our Esteemed, Revered and Illustrious Moderator, runs a PW> BBS that accepts V.34 connections. Call +1-SEE-PLUS-PLUS today! Just for anybody who might have missed it, that one's topical _strictly_ under the humor category. I'm actually a point and don't run a BBS at all, though my bossnode certainly accepts connections up to (at least) 28.8K. Later, Jerry. --- PPoint 2.02 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EER00004 Date: 10/21/97 From: JERRY COFFIN Time: 12:37am \/To: PAUL WANKADIA (Read 2 times) Subj: OS? On (20 Oct 97) Paul Wankadia wrote to Jerry Coffin... PW> FWIW, someone wrote an extremely simplistic malloc() and then PW> proceeded to rewrite PUNIX in C++. Being the non-informed ignorant PW> kiddie I am, I have no idea HOW a monolithic (i.e. not microkernel) OS PW> could possibly use OOP PW> principles to get anything done. Actually, much (if not most) of an OS (microkernel or otherwise) fits into the OO paradigm quite well. In fact, an OSes interface to device drivers is essentially an abstract base class, and the individual device drivers are derivatives of that base class. Likewise, users are instantiations of a class User, and processes are instantiations of a class Process. If the OS includes multithreading, threads are instantiations of a class Thread. Likewise, you typically have a number of I/O type things (disk files, comm ports, pipes, etc.) that are all derivatives of a base class that handles communications. In addition, nearly all the interprocess/interthread synchronization devices (mutexes, semaphores, signals, etc.) have enough in common that you could almost undoubtedly benefit from making them all derivatives of a single base class as well. Offhand, I'd have a hard time thinking of things that fit the OO paradigm more closely that an OS, monolithic, microkernel, or (as most are) some combination of both. Later, Jerry. --- PPoint 2.02 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EES00000 Date: 10/22/97 From: DARRELL HNIZDOR Time: 11:44am \/To: CLIFF RHODES (Read 2 times) Subj: Printer Thanks for the reply. I use DOS/Win95. I will work on the printing soon, if I cannot work it I will be asking for help again. New question: How does this work: " ?:" I do have a text book, I recommend a book for a rookies, otherwise gettisg started in impossible. Anyway, evalution is 3 way but what is the output? is it to the right of : or is it 0/1? --- Maximus 3.01 * Origin: Friendship Corner Albany, Tx 1-915-762-2745 (1:392/15) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EES00001 Date: 10/22/97 From: DARRELL HNIZDOR Time: 11:56am \/To: HENK DEUTEKOM (Read 2 times) Subj: Printer Thanks for the reply Henk. I am a new user and teaching myself, not an easy job. I suspect that the problems I have with learning C++ will be reflected by other new users. By the way for any new users reading this, buy a book on using C++, the money is well invested, and will get you off to a fast start. Henk, any ideas on why cin.getline doesn't always get the line or execute. The previous line would have cout< TOPIC: 203 C++ Ref: EES00002 Date: 10/21/97 From: KNUT SCHUENEMANN Time: 01:18am \/To: ALL (Read 2 times) Subj: Mousepointer I'm looking for an easy way to get the mousepointer's coordinates on a mouseclick-event... Knut --- Yuppie v2.11 * Origin: The Stoned Ghost (2:2437/120.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EES00003 Date: 10/21/97 From: CHRIS DOWNS Time: 06:15am \/To: NEIL HELLER (Read 2 times) Subj: OnCancel() NH> I have a question about inheritance and the flow of logic. There is NH> a class, CCommUI, which is decended from CDialog. CComUI contains a NH> method, OnCancel, which is included in the appropriate message map to NH> be called whenever the "Cancel" button in the modal dialog box (the NH> CComUI object) is pressed. CDialog::OnCancel() is a virtual function. It's implementation is really simple, it just calls CDialog::EndDialog() passing IDCANCEL. NH> void CComUI::OnCancel() NH> { NH> CWnd * pbutton = GetDlgItem(IDCANCEL); NH> pbutton->EnableWindow(FALSE); NH> . NH> . NH> . NH> CDialog::OnCancel(); NH> } NH> The question I have is this: NH> Does the line containing the call to the parent "percolate" up to the NH> child? It works just like any other virtual function. The system knows what type of object it is that's making the call to the virtual OnCancel() and calls the appropriate function. If it's an object of type CComUI, CComUI::OnCancel() is called. If it's an object of type CDialog, then CDialog::OnCancel() is called. If it's something derived from CDialog and this something has no override for OnCancel(), then CDialog::OnCancel() is called. If the object is derived from CComUI and this class has no OnCancel() override, then CComUI::OnCancel() is called. NH> What is the purpose of this call in the first place if NH> CDialog::OnCancel() had never been specifically fleshed out (or even NH> mentioned) anywhere in the code? As mentioned, there is an implementation of CDialog::OnCancel() which the CComUI class inheirited and then overrode. The original code is still out there and is ready to call. This is kinda typical of how MFC is used. To override a function, you either do your thing and call the base class or else you call the base class version and do your own thing. (There are, of course, plenty of exceptions.) NH> As an aside, I commented this line out and the software ran as NH> expected. With that line left in the code there was always a NH> premature closing of the dialog box. Does this mean that the method, NH> CDialog::OnCancel(), was performing some action on its own without me NH> even being aware of it? Yes. There is a message map entry inside the framework that handles an IDCANCEL message. This message is generated if you press a button that sends IDCANCEL or if you press in the dialog. This message map entry points to OnCancel(). --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: EES00004 Date: 10/21/97 From: BALOG PAL Time: 10:43pm \/To: LAURI NURMI (Read 2 times) Subj: GOTO - ?? Hi, Lauri Nurmi! On 15 Oct 97 16:22:14 you wrote to Andrew Weaver LN> It's just "label:", but it's not a good idea to use goto. And why? :) Well, C++ is quite well armored, so you have tools to avoid goto in common situations you better use it in C. Objects will do the appropriate cleanup. But even C++ has no tools to break multiple constructs. (More painly there's no multiple returns that is even harder to handle.) Paul ... Caches to caches, DOS to DOS... --- GNU/Linux * Origin: The FlintStones' Cave in BedRock (2:371/20)