Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!noose.ecn.purdue.edu!dirac!gibbs.physics.purdue.edu!sho
From: sho@gibbs.physics.purdue.edu (Sho Kuwamoto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ThinkC TCL's DoCommand() wish
Message-ID: <5228@dirac.physics.purdue.edu>
Date: 5 Jun 91 18:36:38 GMT
Article-I.D.: dirac.5228
References: <1042@celia.UUCP> <1991Jun5.162514.29682@linus.mitre.org>
Sender: news@dirac.physics.purdue.edu
Distribution: usa
Organization: Purdue Univ. Physics Dept, W.Lafayette, IN
Lines: 21

In article <%> gmarzot@mitre.org (G. S. Marzot (Joe)) writes:
>In article <@> larry@celia.UUCP (Larry Weinberg) writes:
>>
>>[I want]        CBureaucrat::DoCommand(long theCommand,  long  data)
>
>[...] I agree whole heartedly in favor of a more 
>flexible interface to DoCommand and your example looks perfect. [...]

The TCL calls gGopher->DoCommand() whenever the user selects a menu item.
As far as I can tell, this is the main reason that DoCommand() exists.
Given that, we should consider how adding another arg would affect this.
What would happen when the user selects a menu?  The best we could hope
for with this new scheme is that it would call DoCommand() with
data = 0.

If you want something like the above, write your own method.  Call it
MyDoCommand() or something.  Have it call DoCommand() when appropriate.

-Sho
-- 
sho@physics.purdue.edu