Modify Cocoa Toolbar?

A while ago Alex Schneider posted a little snippet of just five lines of code that transform a TextArea into a nice little word processor:

#if targetCocoa declare function documentView lib "Cocoa" selector "documentView" (obj_id as Integer) as Ptr declare sub setUsesInspectorBar lib "Cocoa" selector "setUsesInspectorBar:" (obj_id as Ptr, value as Boolean) setUsesInspectorBar(ptr(documentView(me.Handle)), true) #endif??
Now I would like to modify this toolbar - but how? Anyone can point me in the right direction?

Thanks

Markus

I think this toolbar is not modifiable.

[quote=207317:@Markus Winter]#if targetCocoa
declare function documentView lib “Cocoa” selector “documentView”
(obj_id as Integer) as Ptr
declare sub setUsesInspectorBar lib “Cocoa” selector “setUsesInspectorBar:” (obj_id as Ptr, value as Boolean)
setUsesInspectorBar(ptr(documentView(me.Handle)), true)
#endif??[/quote]

Thanks for posting this snippet again, I didn’t see it the first time round.
Definitely one to keep for future projects.

[quote=207343:@Mark Oxley]Thanks for posting this snippet again, I didn’t see it the first time round.
Definitely one to keep for future projects.[/quote]
There is more. Have a look at the original thread

https://forum.xojo.com/15917-creating-a-bulleted-list-in-textarea/0#p131335

Thanks, heading over there now. I’m always on the lookout for snippets that I can use, or modify, for my own projects

Setting the inspector bar:

[code]Declare Function documentView Lib “Cocoa” Selector “documentView” (NSScrollView As Ptr) As Ptr
Declare Sub setUsesInspectorBar Lib “Cocoa” Selector “setUsesInspectorBar:” (obj_id As Ptr, usesInspectorBar As Boolean)

Dim scrollViewPtr As Ptr = Ptr(Me.Handle)
Dim textViewPtr As Ptr = documentView(scrollViewPtr)
setUsesInspectorBar(textViewPtr, True)[/code]
Getting a pointer to the inspector bar (uses undocumented/private API):

[code]Declare Function contentView Lib “Cocoa” Selector “contentView” (NSWindow As Ptr) As Ptr
Declare Function superview Lib “Cocoa” Selector “superview” (NSView As Ptr) As Ptr
Declare Function subviews Lib “Cocoa” Selector “subviews” (NSView As Ptr) As Ptr
Declare Function count Lib “Cocoa” Selector “count” (NSArray As Ptr) As UInteger
Declare Function objectAtIndex Lib “Cocoa” Selector “objectAtIndex:” (NSArray As Ptr, index As UInteger) As Ptr
Declare Function object_getClassName Lib “libobjc.A.dylib” (id As Ptr) As CString

Dim windowPtr As Ptr = Ptr(TrueWindow.Handle)
Dim contentViewPtr As Ptr = contentView(windowPtr)
Dim superviewPtr As Ptr = superview(contentViewPtr)
Dim subviewsPtr As Ptr = subviews(superviewPtr)
Dim count As Integer = count(subviewsPtr)

Dim inspectorBarViewPtr As Ptr = Nil

For index As Integer = 0 To count - 1
Dim subviewPtr As Ptr = objectAtIndex(subviewsPtr, index)
If object_getClassName(subviewPtr) = “__NSInspectorBarView” Then // __NSInspectorBarView is undocumented
inspectorBarViewPtr = subviewPtr
Exit
End
Next

If inspectorBarViewPtr <> Nil Then
Dim viewsPtr As Ptr = subviews(inspectorBarViewPtr)
Dim countOfViews As Integer = count(viewsPtr) // 10 NSViews
For index As Integer = 0 To countOfViews - 1
Dim viewPtr As Ptr = objectAtIndex(viewsPtr, index)
System.DebugLog object_getClassName(viewPtr)
Next
End[/code]

Just be warned, that Apple will block apps on the App Store that use Private APIs… I know I’m being a killjoy, but I thought I should mention it in case you’re targeting the App Store.

It’s also likely to break in the future or cause Apple engineers compatibility headaches when they try to change the OS.

Won’t cause them any compatibility headaches, but might cause you!

Yosemite proved that they’re happy to change the APIs without documenting the changes and let us developers figure out what we’re going to do.

I have used a few undocumented stuff since the beginnings of OS X. I never had real problems with them.

In the above case, all Apple could do is change the name of the class __NSInspectorBarView. And maybe its position in the view hierarchy. But that’s about it.

Through the Objective-C Runtime you have a guaranteed access to everything in application. Hence Apple’s strict rules when it comes to accept applications for the AppStore – the Objective-C Runtime is so “open” that it is too dangerous. But for non-AppStore desktop applications I think the above is manageable.

I would actually propose that if you want to customize this object and Apple don’t provide you documented functions for doing so, then simply roll your own. After all it’s not that a complicated control.

It might surprise you, but Apple does care about backwards compatibility. There are a lot of old behaviors left around for applications linked on older versions of the OS X SDKs and a surprising number of per-application compatibility workarounds. They even have one in there for a third-party Xojo plugin that was smashing the stack due to passing in a pointer of the wrong type to GetEventParameter.

Granted, they don’t go nearly as far as Microsoft and tend to be less careful testing with older, legacy APIs.

This does surprise me, considering the fall out we had with Yosemite. Many of our applications were left broken.

Right now, most of our old carbon apps on the forthcoming OS having trouble saving image files, but rather than trying to dig out an old version of RB, older plugins and attempting to patch them, I’m simply trying to re-write the most major ones in Cocoa.

I must also state that this time around with the new OS version, I’ve witnessed a different attitude from Apple. I filled one bug report and have had it fixed already. Where as last year, I never got any traction with my bug reports (closed as duplicate) was listed on all of them and none of them were fixed.

You’re a bit late :confused: : Carbon has started deprecation in 2007 and has been deprecated in large parts in 2012 with OS X 10.8.

With Yosemite, our Carbon apps were fine (mostly) it was the Cocoa applications that we had problems with, due to undocumented removal of a 32-Bit framework (not deprecated functionality). One carbon app did have problems because some system icons were removed (again undocumented) and I hadn’t designed the app to cope with missing system icons!

With the new OS coming, this time it’s our carbon apps that are broken while our Cocoa based apps are working (now that a bug in the OS was fixed).

Then I misunderstood your comment, sorry for that.

I don’t know where that is right now, but Apple announced years ago when the transition started, that – in addition to Carbon – some Cocoa libraries or parts of it would never get a 64-bit version (the most prominent being QuickTime). I also found that irritating, because finding out was based on scanning header files rather than checking the documentation.

Icons on disk? The resources in /System aren’t really documented and are more of an implementation detail…