Rainer.Buerck

maybe someone can help me with a little problem. I have written several max objects with windows which display lots of parameter values. In recent months I have re-written these objects for Max5, using Cocoa and Objective-C to create these windows etc.

Some of these objects receive midi data such as program change or controller data to change the values of certain parameters. Of course the windows should always display the current values and therefore have to be updated whenever the object receives a new value.

But there is a problem with this: When I send a value from a number box of a Max patcher window to the object, the contents of the window are re-drawn and display the current value. But when I send numbers via midi from pgmin or ctlin, nothing happens.

I have created a very simple object called "simplewindow" to demonstrate this. It contains a class "MyWindow", and the struct _simplewindow contains the instance "myWindow" of this class. The function "initWindow" is called from simplewindow_new to initialize this window. When a bang is sent to the inlet of simplewindow, the window opens and the method "drawWindowContents" is called to draw the contents of the window. The window displays a white rectangle in the bottom / left corner, and into this rectangle a number is drawn whose value depends on a global called "value". For the values 1 to 3 the strings "1" to "3" are drawn.

When I send a value from a number box of a patcher window to the inlet of simplewindow, this value is stored in the global "value", and the "update" method of the window is called to draw the window contents. As I have described above, this works fine when I send the value from a number box, but when I use pgmin to send this value to the inlet of simplewindow, the drawing doesn't happen, though the "drawWindowContents"method is called and the value of "value" is correct (which is proved by posting it to the Max window). What is the reason for this, and how could it be fixed?

maybe someone can help me with a little problem. I have written several max objects with windows which display lots of parameter values. In recent months I have re-written these objects for Max5, using Cocoa and Objective-C to create these windows etc. 

Some of these objects receive midi data such as  program change or controller data to change  the values of certain parameters. Of course the windows should always display the current values and therefore have to be updated whenever the object receives a new value. 

But there is a problem with this: When I send a value from a number box of a Max patcher window to the object, the contents of the window are re-drawn and display the current value. But when I send numbers via midi from pgmin or ctlin, nothing happens. 

I have created a very simple object called "simplewindow" to demonstrate this. It contains a class "MyWindow", and the struct _simplewindow contains the instance "myWindow" of this class. The function "initWindow" is called from simplewindow_new to initialize this window. When a bang is sent to the inlet of simplewindow, the window opens and the method "drawWindowContents" is called to draw the contents of the window. The window displays a white rectangle in the bottom / left corner, and into this rectangle a number is drawn whose value depends on a global called "value". For the values 1 to 3 the strings "1" to "3" are drawn. 

problems-with-updating-windows

P.S. maybe I should enclose the entire folder of my example (see attachment).

... sorry, it didn't work out, the zip file was too big. But the "simplewindow.rtf" file should be clear enough.

yersterday I found something in the NSWindow Class Reference

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html

Maybe the problem has to do with the bufferingType of the window. I initialized my window like this:

x->myWindow = [[MyWindow alloc] initWithContentRect:NSMakeRect(100,100,400,300)

                                         styleMask:NSTitledWindowMask

                                            backing:NSBackingStoreBuffered

                                             defer:NO];

In the Reference this method is explained like this:

- (id)initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle backing:(NSBackingStoreType)bufferingType defer:(BOOL)deferCreation

Specifies how the drawing done in the window is buffered by the window device, and possible values are described in “NSBackingStoreType—Buffered Window Drawing.”

The bufferingType seems to affect the drawing. I have tried different buffering types, but this hasn't been successful yet.

Flushes the window’s offscreen buffer to the screen if the window is buffered and flushing is enabled.

Does nothing for other display devices, such as a printer. This method is automatically invoked by the NSWindow display and displayIfNeeded methods and the corresponding NSView display and displayIfNeeded methods.

So I called flushWindow for my window after the drawing method, but this hasn't been successful either. But maybe the problem exists somewhere in this area.

yersterday I found something in the NSWindow Class Reference 

x->myWindow = [[MyWindow alloc] initWithContentRect:NSMakeRect(100,100,400,300)
										  styleMask:NSTitledWindowMask
											backing:NSBackingStoreBuffered
											  defer:NO];

In the Reference this method is explained like this: 

bufferingType
Specifies how the drawing done in the window is buffered by the window device, and possible values are described in “NSBackingStoreType—Buffered Window Drawing.”

The bufferingType seems to affect the drawing. I have tried different buffering types, but this hasn't been successful yet. 

flushWindow
Flushes the window’s offscreen buffer to the screen if the window is buffered and flushing is enabled.
- (void)flushWindow
Discussion
Does nothing for other display devices, such as a printer. This method is automatically invoked by the NSWindow display and displayIfNeeded methods and the corresponding NSView display and displayIfNeeded methods.

So I called flushWindow for my window after the drawing method, but this hasn't been successful either. But maybe the problem exists somewhere in this area. 

P.S. if you want, I can send you the entire Xcode folder of my example as a zip file so you can try it out. Just give me a mail address where I could send it to.

ist because you send on the midi/scheduler thread instead of main thread? try deferlow object?

ist because you send on the midi/scheduler thread instead of main thread?  try deferlow object?


Heureka, I just found the solution. It is always simple when you know the solution...

at the end of the function and the updating works fine!

problems with updating windows