Black Windows

Pixelmator fakes it for sure. Evidence for this is to take a look at the resources of Pixelmator.
BTW the resources of Pixelmator also is handy to get all the black controls graphics (button, slider, dropdownmenu, …)

[quote=78987:@Sam Rowlands]Now the down side of using your own label, the OS no longer has a ‘title’ for the Window, yes you need to draw the icon and handle the menu yourself.

[/quote]
In the last example I posted, the title is drawn in the canvas (label clips the text rather than truncate). The window title is set in order to place the icon in the correct place. When gradiated is off, the canvas draws a rectangle to obscure the window’s title drawing.

[quote=78998:@Christoph De Vocht]Pixelmator fakes it for sure. Evidence for this is to take a look at the resources of Pixelmator.
BTW the resources of Pixelmator also is handy to get all the black controls graphics (button, slider, dropdownmenu, …)[/quote]
This may be copyright infringement be careful

Here’s my current revision.
Has disabled text and text is drawn based on the location of the Icon if it has one.

BlackWindow

Here’s a way to dim the traffic light buttons when deactived.

[code]Sub Activate()
setThemeWidgetAlpha(1.0)
End Sub

Sub Deactivate()
setThemeWidgetAlpha(0.5)
End Sub

Sub setThemeWidgetAlpha(alpha As single)
declare sub setAlpha lib “Cocoa” selector “setAlphaValue:” (id As Ptr, value As single)
declare function standardButton lib “Cocoa” selector “standardWindowButton:” _
(id As integer, button As UInt32) As Ptr

dim item As Ptr

for buttonType As UInt32 = 0 to 2

item = standardButton(self.Handle, buttonType)

if item <> nil then setAlpha(item, alpha)

next

End Sub[/code]

Another handy call for the title bar is the dirty dot

declare sub setEdited lib "Cocoa" selector "setDocumentEdited:" (id As integer, yes As boolean) setEdited(self.Handle, true)

To get the name change popover I think the window needs to be backed by an NSDocument (or is it the other way round)

What a nice thread this is! A perfect showcase on how the Xojo community works. Not only Dave benefits but I have seen some amazing things too.

[quote=79078:@Will Shank]Another handy call for the title bar is the dirty dot

declare sub setEdited lib “Cocoa” selector “setDocumentEdited:” (id As integer, yes As boolean)
setEdited(self.Handle, true)
[/quote]

If by that you mean the dot in the close button, you don’t need a declare.

Use:

Window.ContentsChanged = True

That has the advantage of triggering the Window.ContentChanged event. While The Dot is OS X only, the event gives you a place to put code if you create your own visual dirty indicator on other platforms so the logic of setting dirty can be the same on any platform.

This was added a good while back. I remember it because It was a feature request I made for the property and event.

Yes and thanks. Never noticed ContentsChanged and it looks to have been there 4+ years :slight_smile:

Yes it does.

[quote=79086:@Karen Atkocius]If by that you mean the dot in the close button, you don’t need a declare.

Use:

Window.ContentsChanged = True

That has the advantage of triggering the Window.ContentChanged event. While The Dot is OS X only, the event gives you a place to put code if you create your own visual dirty indicator on other platforms so the logic of setting dirty can be the same on any platform.

This was added a good while back. I remember it because It was a feature request I made for the property and event.[/quote]
Thanks Karen! This will be helpful for me also! :slight_smile:

I’m still workin on this…

I’ll post the revisions soon!

Couldn’t someone set this up on github or similar.

Thanks for this code, looks great and works well.

One quick question. I’m looking to add a clickable element into the titlebar, something similar to the ‘Upgrade’ button Sam has created in Shine.

Using the posted code, any controls you place in the titlebar area don’t receive mouse events. Do you need to somehow enable the custom NSView titlebar to receive mouse events? I’m creating a fairly complex custom button using a canvas that I want to place within the title bar. Do I need to somehow add this canvas as a subview or is this likely to break things? I’ve heard things can get flaky if you mix NSViews and standard Xojo controls.

Any help greatly appreciated.

you have to place the button inside the canvas

Example

I think if you make sure the titlebar canvas is the parent of the custom button, it should get brought along with the titlebar canvas and receive events.

Thanks for the replies. The custom canvas button is within the titlebar canvas.

I was actually trying to be clever and have increased the size of the titlebar canvas a little, so it’s more like the App Store title bar. Interestingly elements placed on the titlebar canvas are clickable if they are within what would be the normal titlebar area, but anything outside in the extended area is not clickable. So I’ve ended up with an area where elements are clickable and an area where they are not.

Here’s an example of what I mean:

http://rjvmedia.co.uk/example.zip

The contentView is overlapping there and somehow events go to the Canvas first instead of the buttons. Note that the Canvas is actually behind the contentView. Anyways, you’ll need to move the contentView down so it doesn’t overlap there…

[code]Sub NewTitleBar(mycontrol as RectControl)

//… the current code… then add…

declare sub setFrame lib “Cocoa” selector “setFrame:” (id As Ptr, r As NSRect)

dim r As NSRect
r.x = 0
r.y = 0
r.w = self.Width
r.h = self.Height - mycontrol.Height //RectControl

setFrame(cv, r)

End Sub[/code]

You will need a Structure NSRect of x, y, w, h, all singles. And the parameter needs changing from Control to RectControl.

The code I used is in the magazine article, they do sell individual back issues if you’d like that particular issue. Because I used it in the magazine article it’s a little unfair to subscribers if I re-post it here for free.

Using the code I wrote, I’m able to push any Xojo control to the Titlebar and it still works as expected, even the Xojo control locking continues to work as expected.

The articles I write for xDev are all part of my “Building a Better Mac App” book I’m working on, where the primary focus is on taking advantage of Cocoa to make Xojo Mac apps as good as the best Obj-C apps.

Download