rothberg@polya.Stanford.EDU (Edward Rothberg) (12/03/88)
I'm writing a piece of software which consists of three applications, with the ability to easily transfer between them. I need to be able to tell if an application is started up via transfer, and if so I want to pass a bit of information from the transfering application to the transferee. Is there an elegant way to do this? Right now, I use the Scrap to pass the info. While this works fine, it has the obnoxious side-effect of wiping out what was previously in the scrap without the user having ever issued a command which would obviously have this effect (i.e. Cut, Copy). It seems that what I want to do is put the info into the system heap, but I can't seem to figure out how to make it identifiable once it's there. I can't make it a simple handle, since the application starting up won't have any way to find it. I can't make it a resource, since then it will get added to the resource file. Is there any good way to do this? Ed Rothberg rothberg@polya.stanford.edu
leonardr@uxe.cso.uiuc.edu (12/05/88)
rothberg@polya.Stanford.EDU(Ed Rothberg) writes in comp.sys.mac.programmer >I'm writing a piece of software which consists of three applications, with >the ability to easily transfer between them. I need to be able to tell >if an application is started up via transfer, and if so I want to pass a >bit of information from the transfering application to the transferee. >Is there an elegant way to do this? > >Right now, I use the Scrap to pass the info. While this works fine, it >has the obnoxious side-effect of wiping out what was previously in the >scrap without the user having ever issued a command which would obviously >have this effect (i.e. Cut, Copy). It seems that what I want to do is >put the info into the system heap, but I can't seem to figure out how to make >it identifiable once it's there. I can't make it a simple handle, since >the application starting up won't have any way to find it. I can't make >it a resource, since then it will get added to the resource file. Is there >any good way to do this? > Another distinct problem that you are forgetting with using the scrap is the wonderful world of MultiFinder which DOES NOT convert the scrap betwseen applications automagically. You application must do this itself! You are correct that you want to put the data into the System Heap as the method for mainting data 'links' between applications (until Apple gives up IPC or IAC). You should be using resources as this is anice doucmented method for doing what you want. I think what you are missing about resources is that when you you do a AddResource which marks the handle as a 'Resource Handle' it DOES NOT add the resource to the file, it simple marks the resChanged bit so that when a WriteResource or UpdateResFile is done it is added to the file. If you do neither of the above (Write or Update) then the resource is not added to the resource file, but is still in the System Heap. The other possibility is to use the method described by Paul Snively and Frank Alviani in the last couple MacTutors for doing your own IPC/IAC. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + AppleLink: D0025 + + + + +---------------------------------+-----------------------------------+
beard@ux1.lbl.gov (Patrick C Beard) (12/06/88)
Come on! This is very simply done by setting AppParmHandle (see IM II-57) the way the Finder does, for the consumption of the next application. There should be a way to differentiate it from the one that the finder uses. Patrick Beard Lawrence Berkeley Laboratory
tim@hoptoad.uucp (Tim Maroney) (12/07/88)
In article <1378@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >Come on! This is very simply done by setting AppParmHandle (see IM II-57) >the way the Finder does, for the consumption of the next application. There >should be a way to differentiate it from the one that the finder uses. Unless you have some interest in future compatibility, of course. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Prisons are built with stones of Law, Brothels with bricks of Religion." - Blake, "The Marriage of Heaven and Hell"
michael@taniwha.UUCP (Michael Hamel) (12/08/88)
In article <1378@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >Come on! This is very simply done by setting AppParmHandle (see IM II-57) There is one slight problem: AppParmHandle is pointing to the parameters that were passed to your application, in a *locked* block on the system heap. You can't leave that there and just repoint AppParmHandle. The strategy I adopted was to change the contents of the locked block, and only move it if I absolutely had to. This seemed to work, but I wish I knew why the Finder locked it (the implication being that someone was keeping a pointer to it... -- "Pay no attention to this swine," I said to the hitchhiker... Michael Hamel | currently ..!{unisoft|mtxinu}!taniwha!michael University of Otago | soon to be ..!ucbvax!michael@otago.ac.nz
holland@m2.csc.ti.com (Fred Hollander) (12/09/88)
In article <234@taniwha.UUCP> michael@taniwha.UUCP (Michael Hamel) writes: >In article <1378@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >>Come on! This is very simply done by setting AppParmHandle (see IM II-57) > >There is one slight problem: AppParmHandle is pointing to the parameters that >were passed to your application, in a *locked* block on the system heap. You >can't leave that there and just repoint AppParmHandle. The strategy I adopted >was to change the contents of the locked block, and only move it if I absolutely >had to. This seemed to work, but I wish I knew why the Finder locked it (the >implication being that someone was keeping a pointer to it... > I've seen it move. Are you sure it wasn't just locked temporarily? Fred Hollander Computer Science Center Texas Instruments, Inc. holland%ti-csl@csnet-rela The above statements are my own and not representative of Texas Instruments.