Making a window... not a window.

Thread View: comp.sys.next.programmer

5 messages

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

5 total messages Started by Mike Matthews Wed, 18 Nov 1992 03:02

#1801

Author: Mike Matthews
Date: Wed, 18 Nov 1992 03:02

30 lines
1432 bytes

OK.

I've almost got it.

But.

How in blazes are you supposed to make a window that can not be moved?  I
know you have to use the initContext:... stuff (i.e. not use IB's palettes).
I tried passing a style of NX_PLAINSTYLE to the window but the doggone title
bar was logically there.

Then I tried to subclass Window and just make all of the moveTo:: methods and
dragFrom: methods do nothing.

Then I tried to redefine the screen to be 10 pixels longer on each border and
make the window so big the title bar won't be on the screen (by using
initContext with screen, and getting the mainScreen and modifying its borders
a bit).  But that seems to make a background picture.

What am I doing wrong?  I know this breaks every NeXT interface rule that
applies, but damn the rules, I wanna go full speed ahead.

Or something like that.

Any help'd be GREATLY appreciated.
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
We're fighting for this woman's honor, which is more than she ever did.
- Rufus T. Firefly, in "Duck Soup"

Re: Making a window... not a window.

#1803

Author: Marcel Weiher
Date: Wed, 18 Nov 1992 11:51

21 lines
1348 bytes

matthews@oberon.umd.edu (Mike Matthews) writes:

>How in blazes are you supposed to make a window that can not be moved?  I
>know you have to use the initContext:... stuff (i.e. not use IB's palettes).
>I tried passing a style of NX_PLAINSTYLE to the window but the doggone title
>bar was logically there.
>
>Then I tried to subclass Window and just make all of the moveTo:: methods and
>dragFrom: methods do nothing.

Well you could use the delegate's -windowDidMove:  methods and let that simply
move it back, but I guess that wouldn't be too visually pleasing.

If you don't mind getting low down, use PostScript operators directly:

  windo, orderwindow etc.  

It might be a little difficult to get a View hierarchy onto that, so
you'll probably have to do drawing via straight PostScript as well.

Marcel

Re: Making a window... not a window.

#1805

Author: Mike Matthews
Date: Wed, 18 Nov 1992 14:37

10 lines
879 bytes

As a followup to my own post, and after a hint by William E. Grosso
(william@pinoko.berkeley.edu) I need to disable moving completely; I made a
delegate of the window that did a windowDidMove that just moves it right
back, and you can click there quick enough to bring an app back.  You can
also hide the app you want in front of that window too.
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
"Intelligence without character is a dangerous thing."
-- G. Steinem

Re: Making a window... not a window.

#1821

Author: Mike Matthews
Date: Thu, 19 Nov 1992 00:00

32 lines
1760 bytes

In article <1992Nov18.115118.25918@cs.tu-berlin.de> marcel@opal.cs.tu-berlin.de (Marcel Weiher) writes:
>Well you could use the delegate's -windowDidMove:  methods and let that simply
>move it back, but I guess that wouldn't be too visually pleasing.

>If you don't mind getting low down, use PostScript operators directly:

>  windo, orderwindow etc.  

>It might be a little difficult to get a View hierarchy onto that, so
>you'll probably have to do drawing via straight PostScript as well.

Ewwww. :)

kane@sonata.cc.purdue.edu (Chris Kane) gave the winning suggestion.

[window-id setEventMask:0]

That window won't respond to NUTHIN' now. :-)

Unfortunately, it won't let you use the right mouse button to get the app
menu either, but I'm still working on that (I tried easing up the event mask
to allow right button up and down, mouse entered and exit, and two other
things that I can't remember, still no go).

>Marcel
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
"All over the place, from the popular culture to the propaganda system, there
is constant pressure to make people feel that they are helpless, that the
only role they can have is to ratify decisions and to consume."
-- Noam Chomsky

Re: Making a window... not a window.

#1904

Author: Sam Streeper
Date: Tue, 24 Nov 1992 01:51

22 lines
1328 bytes

matthews@oberon.umd.edu (Mike Matthews) writes:
> How in blazes are you supposed to make a window that can not be moved?  I
> know you have to use the initContext:... stuff (i.e. not use IB's palettes).
> I tried passing a style of NX_PLAINSTYLE to the window but the doggone title
> bar was logically there.

You were probably on the right track.  If memory serves me a window with a null  
button mask has no title/move bar.  The following code seems to do what you  
want:

	window = [[Window alloc] initContent:&r style:NX_PLAINSTYLE
			backing:NX_BUFFERED buttonMask:0 defer:NO];

I think plain windows, tastefully used, don't have to violate anybody's idea of  
how a NeXTstep app ought to work.  They are very useful for all kinds of custom  
UI and I for one like to see intuitive UI objects other than those found in IB.

-sam

--
Opinions expressed herein are not those of my employer.  They're not even
mine.  They're probably wrong besides.  How did they get in here, anyway?

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