locking focus

Thread View: comp.sys.next.programmer

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Vin Locke Wed, 23 Dec 1992 16:21

#1952

Author: Vin Locke
Date: Wed, 23 Dec 1992 16:21

30 lines
1629 bytes

I have a class subclassed from View.
On initialization, a background image is attached, and on mouseDown, 
graphics actions occur in locations pertinent to where the mouse was
clicked. cool. (all these drawn objects are from pswrap-ped PS functions)

I have a another method that draws to the view that I want to call from 
a menu, also a pswrap-ped function.  However, when I execute this from the
menu, the graphics are drawn in the menu itself!  yuck-o!  

Now, I figure this is a matter of lockFocus.  Thing is, I haven't given
the View a name -- I'm just referring to it as "self" in the methods.  
When the menu executes the method, it does the drawing to the menu window,
and I must find a way to tell it where the drawing should be done -- right?

Is there a way I can refer to the window where the drawing _should_ be 
taking place, without having to to assign new id's for this View?  I figure
there must be an easy way to this, but looking through my collection of
examples and sample programs, I can't seem to pinpoint the solution.  I also
suspect my solution may be in IB wiring, rather than in coding.

 


-- 
					--vin

vin@netcom.com

"Every reform movement has its lunatic fringe"
					--Teddy Roosevelt

Re: locking focus

#1954

Author: Ray Spalding
Date: Wed, 23 Dec 1992 17:40

22 lines
1346 bytes

In article <1992Dec23.162156.1556@netcom.com> vin@netcom.com (Vin Locke) writes:
>I have a another method that draws to the view that I want to call from 
>a menu, also a pswrap-ped function.  However, when I execute this from the
>menu, the graphics are drawn in the menu itself!  yuck-o!  

You could have the method that is the target of your menu item do a
[self display], assuming the method is in your View and that your
View does the right thing in drawSelf::.  ("display" takes care of
focusing for you.)

Or, you could do something like the following:
	BOOL isfv = [self isFocusView];
	if (!isfv) [self lockFocus];
	// drawing code goes here
	if (!isfv) {
		[self unlockFocus];
		[[self window] flushWindow];
	}
-- 
Ray Spalding, Office of Information Technology
Georgia Institute of Technology, Atlanta Georgia, 30332-0715
Internet: ray.spalding@oit.gatech.edu (NeXT Mail accepted)

Re: locking focus

#2009

Author: Ali Ozer
Date: Sat, 02 Jan 1993 20:25

16 lines
929 bytes

In article <78766@hydra.gatech.EDU> Ray Spalding writes:
>Or, you could do something like the following:
>	BOOL isfv = [self isFocusView];
>	if (!isfv) [self lockFocus];
>	// drawing code goes here
>	if (!isfv) {
>		[self unlockFocus];
>		[[self window] flushWindow];
>	}

It's more efficient to do the flushWindow before you unlockFocus;
otherwise flushWindow has to temporarily focus on the window containing 
the view. Of course there isn't a noticable hit unless you are doing this
in a time critical situation.

Ali, Ali_Ozer@NeXT.com

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads