garyc@robbie.acns.nwu.edu (06/02/91)
Urgent: Need Quick Reply Does anyone know if there a simple drawing function like DrawText() or DrawString(). I need to display some plain strings in my View area; but I hate to go thru and use the Text Object. Wouldn't it be nicer if they can be done thru a simple func call like DrawLine of NXFrameRect(). Basically we have a CASE tool in which the user creates nodes on a canvas (the view class) and then annotates it. If the user gives the node a name (arrow changes to I-beam for entering text), then the chars should appear in the node. But we are clueless on how to make the chars appear in the node while the user is typing. Any good suggestions? THANKS! --Gary Chang NeXTMail: garyc@robbie.acns.nwu.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (06/02/91)
In article <1991Jun1.212429.11027@casbah.acns.nwu.edu> garyc@robbie.acns.nwu.edu writes: >I hate to go thru and use the Text Object. Use a TextField object. -=EPS=-
glenn@heaven.woodside.ca.us (Glenn Reid) (06/02/91)
garyc@robbie.acns.nwu.edu writes > Does anyone know if there a simple drawing function like DrawText() or > DrawString(). I need to display some plain strings in my View area; but > I hate to go thru and use the Text Object. Wouldn't it be nicer if they can > be done thru a simple func call like DrawLine of NXFrameRect(). If you already have a View, all you have to do is something like this: PSmoveto ( 100.0, 100.0 ); // or wherever PSselectfont ( "Times-Roman", 48.0 ); PSshow ( "Hello whirled." ); NXPing(); Or, even better, write a small PSwrap to do more of it at once. See the docs for more info. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-326-2974 (NeXTfax 326-2977)
moose (Michael Rutman) (06/03/91)
In article <516@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: > garyc@robbie.acns.nwu.edu writes > > PSmoveto ( 100.0, 100.0 ); // or wherever > PSselectfont ( "Times-Roman", 48.0 ); > PSshow ( "Hello whirled." ); > NXPing(); > Agreed that this works, but the docs say that a [font set] is faster than a PSselectfont and why should he do an NXPing()? The window server will never be more than an eyeblink behind an NXPing(). Or do I misunderstand NXPing(). -- Michael Rutman | moose@svc.portal.com Cubist | makes me a NeXT programmer Software Ventures | For Your Eyes Only Public Key smile, you're on standard disclaimer | 071400171C051913
sstreep@elvis (Sam Streeper) (06/04/91)
In article <1991Jun1.212429.11027@casbah.acns.nwu.edu> garyc@robbie.acns.nwu.edu writes: > I need to display some plain strings in my View area; but > I hate to go thru and use the Text Object. EPS suggested using a TextField object; That's probably the best way to do what you want to do. Glenn suggested postscript code; that works too. Here's yet another way so you can take your pick... You might have a couple of View methods that look like this: - initFrame:(const NXRect *)frameRect { [super initFrame:frameRect]; readOut = [[Cell alloc] initTextCell:"Hola!"]; return self; } - someOtherViewMethod { NXRect cellRect = {0, 0, 100, 20 }; [readOut drawInside:&cellRect inView:self]; return self; } This example displays text, but the text won't be editable as it would be in a TextField object. This code was borrowed from the Plotter example which probably appears somewhere on the purdue archive. -- Opinions are not those of my employer. They're not even mine. They're probably wrong besides. How did they get in here, anyway?
eps@toaster.SFSU.EDU (Eric P. Scott) (06/04/91)
In article <1991Jun3.164701.9219@svc.portal.com> moose@sv.portal.com writes: > the docs say that a [font set] is faster than a >PSselectfont Really? But I can think of other reasons to prefer [font set]: 1) selectfont is a DPS extension; you don't want to emit it in a printing context. 2) It does the +useFont: for you. -=EPS=-
sstreep@elvis (Sam Streeper) (06/05/91)
In article <1991Jun3.164701.9219@svc.portal.com> moose (Michael Rutman) writes: > ... and why should he do an NXPing()? The window server will never be > more than an eyeblink behind an NXPing(). Or do I misunderstand NXPing(). NXPing() guarantees 2 things for you. First, you know all your postscript code has been flushed to the window server. Second, it does not return until that code has been rendered. Other things can do one or both of these functions, so it is not always necessary. For example, any time you wait on an event (either by returning to the event loop or explicitly by using Application's getEvent: method) you know that your postscript code has been flushed to the window server. (Remember, though, that the rendering is asynchronous). Any time you call a wrapped postscript function that returns a value, the wrap both flushes and waits for the code to be executed (rendered) before returning. While I'm on the subject, maybe I'll bring up some NXPing religion. Your app can spew postscript to the window server much faster than the window server can render it, so it's possible for your app to get way ahead of the WS. When this happens, the relationship between a user action and the drawing that happens at that time (apparently in response to the action of the moment) gets mushy. Mouse dragged events are coalesced by default, so if you NXPing and the next event is a drag event, your next drawing will actually reflect the current position of the mouse. Pinging can definitely slow you down, because it can force extra communication between the app and the window server, and this communication is not always necessary. It can also speed up rendering, because the app stops competing with the window server for CPU time until the rendering is done. As always, there is no single correct answer, and your mileage may vary. -sam -- Opinions are not those of my employer. They're not even mine. They're probably wrong besides. How did they get in here, anyway?