This is Two-appkit-questions in view mode; [Up]
Date: Sun 20-Nov-1991 04:36:22 From: louie@sayshell.umd.edu (Louis A. Mamakos) Subject: Two appkit questions I've got two appkit questions that I hope someone can help me with. First, the simple one. Problem 1: I'm hacking on an application that needs to invoke another program to hand off stuff in a file it creates. It might be a TIFF image or PostScript or sound, or whatever. I'm using a Speaker object to talk to the Workspace and the getFileInfoFor:app:type:ilk:ok: method to find out what application is around to handle a file of the appropriate name (foo.eps, foo.snd, foo.tiff, foo.gif, foo.rtf, etc). The idea is to figure out if indeed there is an application present before trying to use openTempFile:ok: to display it. So far so good. The problem that I have is that even if you don't have an application around to handle a particular type of file, you'll still get "Edit" returned as the "default" application. Now, using "Edit" as the application to open some weird image file format isn't likely to be terribly useful. Is there a way to find out, exclusive of the "default" application, what application will handle a particular file? You can't just exclude "Edit", since that might be appropriate for "foo.rtf" sort of files. Problem 2: I wanted to do something clever and sexy with sound in an application, so I stole some of the code from the SoundEditor example application. I'm running into a problem that seems to be in the original code. If you do build the original example and do this: - Fire it up from a shell - observe the "Untitled" document window that is automatically created. - Make sure that the "Untitled" document window is selected, click on the "New" menu item or type command-n - observe the following messages: Assertion failed: No window during lockFocus on a view Assertion failed: No REAL window during lockFocus on a view This seems to only happen if an existing document window is selected when creating a new one. I tracked it down to somewhere in the ScrollingSound - initFrame:(NXRect const *)theFrame { NXRect tempRect = *theFrame; id theSoundView; int borderType = NX_NOBORDER; [ScrollView getContentSize:&tempRect.size forFrameSize:&theFrame->size horizScroller:YES vertScroller:NO borderType:borderType]; theSoundView = [[SoundView alloc] initFrame:&tempRect]; [theSoundView setReductionFactor:32.0]; [super initFrame:theFrame]; [self setBorderType:borderType]; [self setHorizScrollerRequired:YES]; [self setDynamicScrolling:YES]; => [self setDocView:theSoundView]; [self setBackgroundGray:NX_WHITE]; [self setAutoresizeSubviews:YES]; [self setAutosizing:NX_WIDTHSIZABLE|NX_HEIGHTSIZABLE]; [[theSoundView superview] setAutoresizeSubviews:YES]; [theSoundView setAutosizing:NX_HEIGHTSIZABLE]; return self; The error seems to be printed when the [self setDocView:theSoundView] is invoked, and only when an existing instance of this class happens to be selected. If a current document window is not selected, the error doesn't occur. I am confused and weirded out by this. Help, louie
Date: Sun 24-Nov-1991 19:33:21 From: eps@futon.SFSU.EDU (Eric P. Scott) Subject: Re: Two appkit questions In article <1991Nov20.043622.29658@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >The problem that I have is that even if you don't have an application >around to handle a particular type of file, you'll still get "Edit" >returned as the "default" application. Not necessarily. I think you get DefaultOpenApp, which just happens to be Edit most of the time. > Now, using "Edit" as the >application to open some weird image file format isn't likely to be >terribly useful. True, but if you don't have an application that DOES handle that weird image file format, you're not going to do much better, are you? >Assertion failed: No window during lockFocus on a view >Assertion failed: No REAL window during lockFocus on a view See appkit.774 in NeXTanswers. -=EPS=-
Date: Sun 25-Nov-1991 17:48:34 From: louie@sayshell.umd.edu (Louis A. Mamakos) Subject: Re: Two appkit questions In article <1991Nov24.193321.21723@csus.edu> eps@cs.sfsu.edu writes: >In article <1991Nov20.043622.29658@ni.umd.edu> >> Now, using "Edit" as the >>application to open some weird image file format isn't likely to be >>terribly useful. > >True, but if you don't have an application that DOES handle >that weird image file format, you're not going to do much >better, are you? What'd I'd do if there was no tool available is offer to save the unknown stuff into a file. Better than a window fully ugly stuff. The whole motivation behind this is to futher enhance Mark Crispin's MailManager's handling of RFC-XXXX bodyparts. Its likely that you'll see body parts that you can't recognize or handle, and if the user insists on examining them, you ought to be able to at least tell him that you don't know how. Right now, there is a horrible, gross kludge where I refuse to open a body part if the application name is "Edit"; clearly this is not the right solution to this problem. It think that there is real hope of eventually replacing /NextApps/Mail.app with a program that does multimedia mail that interoperates with other non-NeXT platforms. louie
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.