hairston@henry.ECE.CMU.EDU (David Hairston) (03/03/91)
I've got this simple app that only makes sense when run under MultiFinder (i.e. it displays some info but otherwise does nothing useful). Since it assumes MultiFinder, I've decided not to add support for DA's within my application (after all, there's DA Handler). This only means that if you install a DA in my app then I won't open it but I will still otherwise open DA's into DA Handler. To accomplish this goal I thought I'd simply set the current resource file to the system file and then AddResMenu(AppleMenuHandle, 'DRVR') and then switch the current resource file back to my application when creating my application menus. Is this approach "star-crossed" for any reason (i.e. too simplistic)? -dave- hairston@henry.ece.cmu.edu
deadman@garnet.berkeley.edu (Ben Haller) (03/03/91)
In article <12182@pt.cs.cmu.edu> hairston@henry.ECE.CMU.EDU (David Hairston) writes: > I've got this simple app that only makes sense when run under > MultiFinder (i.e. it displays some info but otherwise does > nothing useful). Since it assumes MultiFinder, I've decided > not to add support for DA's within my application (after all, > there's DA Handler). This only means that if you install a > DA in my app then I won't open it but I will still otherwise > open DA's into DA Handler. To accomplish this goal I thought > I'd simply set the current resource file to the system file > and then AddResMenu(AppleMenuHandle, 'DRVR') and then switch > the current resource file back to my application when creating > my application menus. Is this approach "star-crossed" for > any reason (i.e. too simplistic)? Well, I have no idea if this is System 7.0 compatible and such, but I object to it for a much simpler reason: under System 6.0.x, a user may open a DA in the same layer as an app by holding down option and selecting the DA's name. If you don't support DAs in your app, it will behave strangely, and possibly crash, when someone does this. This is unacceptable. And yes, there are reasons why people would do this - I have reasons to do it all the time. I probably option-open more often than not. Why do you not want to support DAs? Just laziness? Also remember that MultiFinder uses a lot of strange tricks to do things, any many of those tricks depend on the apple menu of an application working in a predictable way. MultiFinder fakes apple menu selections to force clipboard conversion, and I think other stuff too. Finally, I fail to see why you want to take your app out of the resource path before calling AddResMenu *anyway*. I thought that DAs inside an apps resource file would be opened in their own layer just like DAs in the System file. Is this not true - are they opened in the same layer as the app? BTW, hi, Dave. -Ben Haller (deadman@garnet.berkeley.edu)
hairston@henry.ECE.CMU.EDU (David Hairston) (03/04/91)
[hairston@henry.ECE.CMU.EDU (David Hairston) writes:] [] I've got this simple app that only makes sense when run under [] MultiFinder (i.e. it displays some info but otherwise does [] nothing useful). Since it assumes MultiFinder, I've decided [] not to add support for DA's within my application (after all, [] there's DA Handler). This only means that if you install a [] DA in my app then I won't open it but I will still otherwise [] open DA's into DA Handler. To accomplish this goal I thought [] I'd simply set the current resource file to the system file [] and then AddResMenu(AppleMenuHandle, 'DRVR') and then switch [] the current resource file back to my application when creating [] my application menus. Is this approach "star-crossed" for [] any reason (i.e. too simplistic)? [deadman@garnet.berkeley.edu (Ben Haller) writes:] [] Well, I have no idea if this is System 7.0 compatible and such, but I [] object to it for a much simpler reason: under System 6.0.x, a user may [] open a DA in the same layer as an app by holding down option and selecting [] the DA's name. If you don't support DAs in your app, it will behave [] strangely, and possibly crash, when someone does this. This is [] unacceptable. And yes, there are reasons why people would do this - I [] have reasons to do it all the time. I probably option-open more often [] than not. i should have mentioned that i did write a simple check for this and in this case i simply display an alert that says "<myApp> does not support DA's in its own partition." [] Why do you not want to support DAs? Just laziness? well, i was trying to minimize useless functionality and i couldn't think of any good reasons why someone would want to open a DA in my itsy-bitsy 32k partition. supporting DA's is trivial but since I've got DA Handler I thought I'd figure out how to correctly not support DA's (in my partition), if this resulted in a size saving. from a user's perspective, why would it be _necessary_ to open a DA in my app since they can use DA Handler? [] Finally, I fail to see why you want to take your app out of the resource [] path before calling AddResMenu *anyway*. I thought that DAs inside an [] apps resource file would be opened in their own layer just like DAs in the [] System file. Is this not true - are they opened in the same layer as [] the app? in my experience, DA's installed in an apps resource file are opened in the apps layer (can't vouch for system 7). thus i thought of the above trick to not see DA's inadvertently installed in my app. i know this is terribly unfriendly, but ... [] BTW, hi, Dave. ... ;) -dave- hairston@henry.ece.cmu.edu "It was a nightmare! It started with these giant red lips, floating around!"
lsr@Apple.COM (Larry Rosenstein) (03/06/91)
In article <12182@pt.cs.cmu.edu> hairston@henry.ECE.CMU.EDU (David Hairston) writes: > >nothing useful). Since it assumes MultiFinder, I've decided >not to add support for DA's within my application (after all, >there's DA Handler). This only means that if you install a You still have to support DAs in order for MultiFinder to work. For example, when the user picks a DA, the only way for MultiFinder to know this is that your application calls OpenDeskAcc. The same is true of switching applications by choosing the name from the Apple menu. It might be possible to leave out some of the other calls, but you're not talking about much code, so you might as well put it in. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 3-PK Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
hairston@henry.ECE.CMU.EDU (David Hairston) (03/07/91)
[hairston@henry.ECE.CMU.EDU (David Hairston) writes:] [] ... [] nothing useful). Since it assumes MultiFinder, I've decided [] not to add support for DA's within my application (after all, [] there's DA Handler). This only means that if you install a [lsr@Apple.COM (Larry Rosenstein) writes:] [] You have to support DAs in order for MultiFinder to work. For example, [] when the user picks a DA, the only way for MultiFinder to know this is that [] your application calls OpenDeskAcc. The same is true of switching [] applications by choosing the name in the Apple menu. It might be possible [] to leave out some of the other calls, but you're not talking about much [] code, so you might as well put it in. no, you misunderstood. i didn't mind calling up DA's as long as they went into DA Handler. DA's opened by option-clicking or DA's installed in my app were to be verboten. well, i played around with this a lot and found out that its just not worth it trying to not support DA's correctly. the easiest thing to do is simply follow the rules and pray that DA's also follow the rules (i.e. check available memory when starting up). the code overhead is _very_ minimal and you don't have to worry about possible loopholes or future system patches breaking your code, etc. moral: DA's just yes, maybe ... ;) -dave- hairston@henry.ece.cmu.edu