[PB Cocoa] Cocoa companion library

[wilbert]

setAllowsUserCustomization:

The way you altered the function would be correct.
PureBasic however doesn't support user customization.
Try to insert this line into my example PureBasic code just before the Repeat / Until loop

Code: Select all

CocoaMessage(0, TB_ID, "runCustomizationPalette:", #Null)

That's what the customization palette looks like.

It's also possible by the way to create multiple toolbars and change them with the window id and toolbar id

Code: Select all

CocoaMessage(0, WindowID(0), "setToolbar:", ToolBarID(0))

[DK5UR]

PureBasic however doesn't support user customization.

It does


Thanks for the hints. Next is to attach a menu to a tbButton

[wilbert]

Yes, I know the OS itself does
I meant that there's no built in command to accomplish it.

My intention with the lib is to create a way of interacting with the underlaying objects and add some functionality that might be used a lot or would be difficult to accomplish with simple commands.
I doubt if a lot of user will add such toolbar customization but it's not that difficult with the commands to send a message to an object.

CocoaMessage(0, TB_ID, "setAllowsUserCustomization:", #True)
CocoaMessage(0, TB_ID, "setAutosavesConfiguration:", #True)

I especially added debug functionality to these lower level commands like CocoaMessage() to make 'playing' with them easier.
If you use a selector that the object can't respond to, the debugger shows an error message. Without the debugger error it would simply compile and crash.

The main problem is that Cocoa works a lot with target / action or delegates and those concepts are very strange to PureBasic.
Fred does a great job wrapping things so PureBasic can work with Cocoa but adding custom objects like for example an NSSearchField object would be difficult since it doesn't post any events to the event queue.

[Fred]

You can still ask for a callback in your wrapper function, so it will get called.

[wilbert]

You can still ask for a callback in your wrapper function, so it will get called.

A callback for a simple control works
I created a single command SetTargetActionCallback for all NSControl subclasses.

Code: Select all

ProcedureC SearchCallback(Sender)
  
  text.s = NSStringToString(CocoaMessage(0, Sender, "stringValue"))
  Debug Text
  
EndProcedure

If OpenWindow(0, 0, 0, 300, 150, "Target-Action", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  
  Frame.NSRect
  Frame\origin\x = 20
  Frame\origin\y = 20
  Frame\size\width = 200
  Frame\size\height = 30
  
  SearchField = CocoaMessage(0, 0, "NSSearchField alloc")
  CocoaMessage(@SearchField, SearchField, "initWithFrame:@", @Frame)
  
  ContentView = CocoaMessage(0, WindowID(0), "contentView")
  CocoaMessage(0, ContentView, "addSubview:", SearchField)
  
  SetTargetActionCallback(SearchField, @SearchCallback())
  
  Repeat
    EventID = WaitWindowEvent()
  Until EventID = #PB_Event_CloseWindow   
  
EndIf

[wilbert]

...

[J. Baker]

Hey Wilbert, is there any way of having extra values for EnableFullScreenButton(WindowID(0))? Something like, EnableFullScreenButton(WindowID(0), X, Y, Width, Height). That way an app can be adjusted proportionally in full screen mode.

EDIT: I think WindowBounds() may control this just fine.

[wilbert]

I'm not sure what you are asking Joe.
As far as I know, a resize event occurs when the window is scaled to fullscreen.
Can't you adjust things when that event occurs ?
Or do you need additional information about the screen ?

[J. Baker]

I'm not sure what you are asking Joe.
As far as I know, a resize event occurs when the window is scaled to fullscreen.
Can't you adjust things when that event occurs ?
Or do you need additional information about the screen ?

Not an issue now. Here's some code on what I was talking about. It's for controlling the size, if you prefer to keep your app at a certain aspect ratio in full screen mode.

Code: Select all

If OpenWindow(0, 0, 0, 322, 150, "FullScreen button", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
  
  ExamineDesktops()
  
  WindowBounds(0, 0, 0, (DesktopHeight(0) / 3) * 4, DesktopHeight(0)) ; 4:3 example - control the size of the full screen app
  
  EnableFullScreenButton(WindowID(0))
  
  EditorGadget(0, 8, 8, 306, 133)
  
  Repeat
  Until WaitWindowEvent() = #PB_Event_CloseWindow
  
EndIf

[wilbert]

@Joe, you will have to set the initial window size yourself so it complies to the aspect ratio you want but you can set the aspect ratio.

Code: Select all

If OpenWindow(0, 0, 0, 400, 300, "FullScreen button", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
  
  Size.NSSize
  Size\width = 4
  Size\height = 3
  
  CocoaMessage(0, WindowID(0), "setContentAspectRatio:@", @Size)
  
  EnableFullScreenButton(WindowID(0))
  
  EditorGadget(0, 10, 10, 380, 280)
  
  Repeat
  Until WaitWindowEvent() = #PB_Event_CloseWindow
  
EndIf

[J. Baker]

There's an "R" after "CocoaMessage". Once removed, it locked up my pc.

[wilbert]

Your WindowBounds approach works for fullscreen.
Setting the aspect ratio works for all user resizes

[J. Baker]

There's an "R" after "CocoaMessage". Once removed, it locked up my pc.

Just download the library again. It should have the "R" (it was a recent addition).

Where CocoaMessage expects all arguments to be integer values or pointers, CocoaMessageR needs the return value and all arguments by reference (that explains the "R").
It's basically the same as the previous way of creating an invocation. That still is available if you want and is required if you have over 7 arguments to pass.
If you don't need to pass that many arguments, the new CocoaMessageR command is much easier and shorter.
By passing everything by reference, all kind of structures can be passed and returned. This is very convenient also when a structure like a point or a rectangle is returned.

As for your WindowBounds approach, that works for fullscreen.
Setting the aspect ratio works for all user resizes

Sweet, thanks Wilbert! Working just fine here now.

I don't think I've used more then 7 args myself. Glad to see this added.

[wilbert]

I don't think I've used more then 7 args myself. Glad to see this added.

Thanks

It should be enough for almost all Cocoa interaction.
There are methods however that require more arguments like this one
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:
but those are rare fortunately

[wilbert]

Added

PDFViewer_CatchPDF (PDFViewerObject, *MemoryAddress, Size) - Catch pdf from memory.
PDFViewer_Create (WindowID, x, y, width, height) - Create a pdf viewer object.
PDFViewer_LoadPDF (PDFViewerObject, FileName.s) - Loads a pdf file.

SlideShow_PresentImages (@ImageID_Array(), ArraySize, AutoPlay) - Presents a slideshow of images.
SlideShow_PresentFiles (@FileNames_Array(), ArraySize, AutoPlay) - Presents a slideshow of files.

Example

Code: Select all

Dim Images.s(1)
Images(0) = "Image1.jpg"
Images(1) = "Image2.jpg"

If OpenWindow(0, 0, 0, 400, 300, "Slideshow", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
  
  SlideShow_PresentFiles(@Images(), 2, #True)
  
  Repeat
    EventID = WaitWindowEvent()
  Until EventID = #PB_Event_CloseWindow
  
EndIf