BlitzBasic Portal Worklogs - CocoaExt

bugFixes

d-bug — Sun, 14 Feb 2010 12:07:43 +0100

Vorweg mal ne kurze Info zu MaxGUI 1.38 und CocoaExt:
Einfach CocoaExt neu kompilieren, dann läufts wunderbar.

So, hab in letzter Zeit mal wieder gefühlte 2.000.000 bugfixes veranstaltet. Die folgende Liste beginnt am
23.12.2009 und endet heute...

+ = hinzu / - = entfernt / # = gefixt bzw. geändert

+ cocoaext.userdefaults: Unterstützung für Default-Variablen.
+ cocoaext.gui: Methode um Gadgets drehen zu können.
+ cocoaext.gui: Checkbox-Verhalten für MenuItems
# cocoaext.gui: GadgetHidden auf ein Fenster angewendet führte unter besondern Umständen zum Absturz
# cocoaext.gui: Vordefinierte Breite der Scrollbars auf die, von Apple vorgebenen, 15 Pixel geändert
# cocoaext.gui: Absturz beim "nullen" des Images einer ImageView gefixt
+ cocoaext.gui: CocoaSelectButtonMenuItem und CocoaSelectedButtonMenuItem hinzugefügt (anwendbar auf Popup-und Pulldown Buttons)
# cocoaext.gui: Popup-und Pulldown Buttons konnten die MenuItems nicht sperren (disabled)
# cocoaext.gui: MaxGUI1.36+ Crash mit: "duplicate identifier _NSSetHotKey" Meldung <-- (hatte ich ja schon mal erwähnt)
+ cocoaext.tabbar: setItemExtra und setItemText Unterstützung
# cocoaext.tabbar: CocoaDisableFocusRing für alle Sub-Gadgets eingebaut
+ cocoaext.scopeview: Man kann nun auf den Modus-Popup-Button zugreifen
# cocoaext.tabbar: Absturz beim entfernen des letzten Items gefixt
+ cocoaext.tabbarView: Hab die komplette Tabbar über den Haufen geworfen und eine TabbarView hinzugefügt
# cocoaext.gui: EVENT_GADGETACTION vor Aufruf des Menüs bei Popup-und Pulldown Buttons hinzugefügt
# cocoaext.gui: Unkontrolliertes Verhalten bei aufeinanderfolgenden Sheet-Alerts gefixt

Ihr seht also, es lohnt sich wirklich mal was größeres mit seinen eigenen Modulen zu programmieren. So findet man dann auch mal die Bugs :>

Zu der dem Verwerfen der Tabbar ist noch was nachzulegen:
Da ich wirklich überhaupt keine kontrolliertes Verhalten beim hinzufügen oder entfernen der Tabs herbeiführen konnte, bin schlußendlich zu dem Ergebnis gekommen, dass die von BRL eingeführte Item-Verwaltung über Arrays scheiße ist. Ich bin also hingegangen und habe das ganze über LinkedLists realisiert und das läuft doch um einiges stabiler. Außerdem bringt die neue TabbarView jetzt pro Tab ein ContentPanel mit, dass automatisch ein bzw. ausgeblendet wird. Dieses Panel kann auch bei bedarf ersetzt werden. Das ein/ausblenden bleibt!
Nachteil der ganzen Geschichte ist, dass die Tabs nicht mehr automatisch ihre Größe ändern, wenn es zu viele auf der Leiste sind.

Um die Kompatibilität zu erhalten habe ich die alte Tabbar mal dabei gelassen, werde sie aber nie und nimmer mehr anpacken. Bei mir liegt die eher als Abfall auf der Platte. :>

So long...

Warnung^2!!!

d-bug — Thu, 31 Dec 2009 09:57:56 +0100

Heute wurde ja bekannter maßen schon MaxGUI 1.36 veröffentlicht, dass Key Events und diesen ärgerlichen "TIntWrapper ist nun Private" Käse gefixt hat!

Dafür bekam ich aber beim kompilieren die Fehlermeldung, dass NSSetHotKey nun doppelt vorhanden sei! Dies war wiederum ein Fehler von mir. Bitte holt euch die letzte Version von CocoaExt aus dem SVN und kompiliert diese neu.

(Es gab da auch noch diverse andere Bugfixes, die mir während der Erstellung meines ersten größeren CocoaExt Projekts unter gekommen sind.)

Grüße

Warnung!

d-bug — Wed, 23 Dec 2009 00:23:41 +0100

Solltet ihr darüber nachdenken auf das gerade eben erschienen 1.35er Update der MaxGUI upzugraden und nebenbei auch noch CocoaExt verwenden wollen, so muss ich euch warnen! Das funktioniert nicht mehr miteinander. Netterweise hat SebHoll die, für CocoaExt, wahrscheinlich wichtigste Klasse (TIntWrapper) in der neuen Version der MaxGUI auf "private" gesetzt. Ich habe ihn bereits darum gebeten dies rückgängig zu machen, da es unter anderem auch kleptos scintilla.mod (die OSX Version) betrifft. Diese greift ebenfalls auf die TIntWrapper Klasse zurück.

SpeedFix:
öffnet ...BlitzMax/mod/maxgui.mod/cocoamaxgui.mod/cocoagui.bmx
geht zu Zeile 915
kommentiert das dort stehende Private einfach aus.
kompiliert die Module neu

Dies hat keinen Einfluss auf die Funktionalität von MaxGUI.

Bis denne!

ScopeBar

d-bug — Sun, 22 Nov 2009 18:00:53 +0100

Moin,

nun hatte ich mal Lust auf was anderes und hab begonnen die ScopeBar zu erstellen. Die ScopeBar ist auch bei Apple ein selbst gefriemeltes Wunderwerk, wenn man z.B. die Suche in Safari oder XCode aktiviert. Da ich kein besonderes Interesse an 2.000 Einstellmöglichkeiten habe, ist sie ziemlich statisch geraten. Man kann sie allerdings als eine Art Vorlage betrachten.

Erst mal was fürs Auge:

Zu sehen ist die Leiste im "Normal" Modus, nachdem sie eingeblendet wurde. Eine einfache Suchfunktion mit noch fehlender Trefferanzeige und eine Vor-und Zurück Button-Kombination mit der man zwischen den Treffern hin und her springen können soll. Außerdem gibts links noch einen Popup-Button, der es ermöglicht zwischen "Suchen" und "Suchen & Ersetzen" hin und her zu wechsen. Dieser wird später mal optional sein, damit man auch die Leiste nur zum suchen verwenden kann.

Nun ist das ganze ausgeklappt, bzw. der Ersetzen-Teil der Leiste wird ebenfalls angezeigt. Dort gibt es links die drei Buttons, die verschiedene Arten des Ersetzens ermöglichen sollen. Außerdem hats da ein normales Textfeld, in dem man den Token eingeben kann.

Die ganze Suchfunktionalität wird nicht von der Leiste geliefert. Dafür wirds aber einen Haufen Methoden und Callbacks geben, die man verwenden kann. Die Textarea als solches ist nur lose drangepappt. Man könnte also auch klepto2' Scintilla-Gadget benutzen. Einzig und allein muss man die TextArea oder die ScintillaArea als Target-View der Leiste zuweisen. Diese sorgt dann wiederum dafür, dass die TextArea automatisch vergrößert oder verkleinert wird, je nach momentanem Stand der Leiste. Die Leiste ist also keine Leiste als solches, sondern eine Erweiterung der TextArea. Man muss die Größe so angeben, wie die TextArea später groß sein soll.

So, das wars dann auch erst mal.

Drag & Drop für ImageViews

d-bug — Sat, 21 Nov 2009 19:53:20 +0100

Vorweg: Heute kein Bilderbuch hier.

Soeben ist es mir gelungen Drag&Drop für die ImageViews zu integrieren. Letztens gabs ja nur Drop, dass ging mir allerdings ein wenig auf die Nerven, also hab ich mich heute mal wieder dran gesetzt. Erstaunlicherweise gibt es erschreckend wenige samples im Netz, die es einem einfacher machen würden das alles zu verstehen. Wie dem auch sei, ich fand dann doch noch zwei nach denen ich mich richten konnte.

So war es mir zuerst möglich Images durch die Gegend zu ziehen, die vorher in die ImageView "gedropt" wurden. Diese speicherten ihren Pfad ab und wurden mit diesem Pfad auch wieder ausgelesen und konnten so auch wieder in einer anderen Applikation abgelegt werden.

Nach ein wenig mehr Hirnschmalz konnte ich dann auch noch das ganze so implementieren, dass wenn man ein Image programmiertechnisch an die ImageView übergibt, dieses wenigstens schon mal von anderen ImageViews erkannt wird. Leider kann man es nicht mehr in anderen Applikationen ablegen, oder gar auf dem Desktop.

Vielleicht sollte ich einfach generell nur mit Pfaden laden lassen. Was aber dann hieße, dass man seine Images
irgendwo zwischen speichern müsste, wenn sie zur Laufzeit generiert wurden oder Teile einer Pixmap sind.

Übrigens wird während des Ziehens auch noch ein nettes transparentes Thumbnail angezeigt, was in seiner Grundeinstellung auf eine Breite von 300 Pixel proportional skaliert wird und einen Alphawert von 0.8 hat. Kann man selbst redend einstellen.

Ein nettes neues Custom-Gadget namens TCocoaExtMatrix gibts übrigens auch noch. Ich habe mir erlaubt eine Tabelle zu programmieren, auf die man andere Gadgets legen kann. Soll dem einfachen Positionieren und resizen von Gadgets dienen. Sehr praktisch wäre das z.B. bei meinem ChaosKnuffel gewesen. Da hätte ich all die kleinen Buttons drauf schmeißen können.

Das Ding hat aber auch einen Nachteil. Da BRL die Größe von Gadgets als Integer speichert, ist die Berechnung der Zellengrößen nicht sehr genau. Legt man, so wie ich, einen Haufen farbiger Panels drauf und setzt deren Layout auf 1,1,1,1 werden sie zwar schön skaliert, wenn man das Fenster vergrößert, aber man sieht auch den Hintergrund bei manchen Größen. So quasi als Raster. :>

Nun ja, kann eben nicht alles klappen.

Bis zum nächsten mal!

BugFixes und Neues

d-bug — Tue, 17 Nov 2009 19:16:50 +0100

So, nachdem ich YellowRider nun das erste mal die neue Version von CocoaExt komplett gegeben habe, kamen auch gleich zig Bugs auf. So weit es in meiner Macht lag, hab ich diese auch gefixt.

Einzig verblieben ist momentan eine recht mysteriöse Größenänderung in der TabView, die ausschließlich beim ersten Tab auftritt. Das aber auch nur, wenn sie die TabView auf einer SplitView befindet und den NSTabViewNoTabs flag gesetzt hat. Sehr sehr mysteriös *grusel*. Da weiß ich im Moment einfach nicht, was die Ursache sein könnte. Alle möglichen Versuche hab ich schon gestartet. Natürlich ohne Erfolg. Ich lass das jetzt einfach mal so, vielleicht hab ich ja mal eine Eingebung.

Tja, neues ist nicht all zu viel hinzu gekommen. Ein paar Methoden, die das Handling einiger Gadgets vereinfachen soll, für die sich aber eine extra Funktion nicht lohnt, weil der 08/15 Anwender von MaxGUI sie wohl nie benötigen wird. (Bitte nicht krumm nehmen)

Außerdem gibts jetzt auch noch das letzte mir verbliebene "standard" Gadget zu bestaunen. Die ImageView! Die ist nichts anderes als ein Gadget das ein Bild anzeigen kann. Man kann der View verschiedene Rahmentypen zuweisen und per Drag&Drop auch Bilder drauf ziehen. Letzteres löst einen Event aus, der als EventExtra den kompletten Pfad zum Image beinhaltet. Wäre noch schön, wenn man auch Images aus der View ziehen könnte, so wie beim ColorWell, aber da hab ich noch nichts zu gefunden. Noch ein Vorteil gegenüber eines Panels: Per NSImageViewAnimate flag kann man sich animierte Images auf der View anzeigen lassen. Die Abspielgeschwindigkeit und dergleichen werden direkt aus dem Image gelesen.

Zur ImageView gibts ein Bild! Nicht weil es schrecklich spektakulär ist, sondern weil die Kühe total geil sind! :>

(oben sieht man auch den Event, der ausgelöst wurde als ich das Bild namens moo.jpg auf die View zog.)

so, grüßt eure besseren Hälften (soweit vorhanden) und bis zum nächsten mal!

Das Ende naht! (zumindest das der Tabbar)

d-bug — Sat, 07 Nov 2009 21:37:01 +0100

Hallöle,

wo ich es jetzt endlich schaffte die Sortierung der Tabs ans laufen zu bekommen und auch so andere Klinigkeiten überarbeitete, muss ich gestehen, dass ich nicht damit gerechnet hatte, dass dieses Gadget so ein Monster werden würde.

Die Sortierung als solches kostete mich etwas Gehirnschmalz. Ich hatte sie bereits am laufen, als ich feststellte, dass Safari das ganz anders handhabt. Manchmal sollte man eben doch mal genauer hinschauen. Das automatische kürzen der Items z.B. klang irgendwie einfacher als es war. Auch recht unglücklich hat mich das kürzen der Labels auf dem Tab gemacht. Stundenlang hab ich versucht mir eine Lösung dafür auszudenken, dass die Labels nur gekürzt und mit "..." versehen wurden, wenn man einen neuen Tab erstellte, nicht aber, wenn man das Fenster vergrößerte oder verkleinerte. Dann viel mir plötzlich auf, dass ich als Berechnungsgrundlage der Labellänge den bereits vorher gekürzten Texts genommen hatte und nicht den ursprünglichen Text. Kleiner Fehler große Ursache.

Auf Wunsch von ozzi (siehe Kommentare) hab ich dann auch noch Icons eingebaut. YellowRider wollte gerne die Unterstützung für verschiedene Themes. Die hab ich auch eingebaut. Außerdem gibts eine 24x24 große View, in der man ein Gadget seiner Wahl platzieren kann. Die muss allerdings auch noch sichtbar geschaltet werden. Auf dem Screen ist das auf dem Tab mit dem ProgressIndicator zu sehen. Das Zahnrädchen ist btw. das Icon!

Am meisten Probleme hat es mir wohl bereitet, die TabView mit der Tabbar zu synchronisieren. Bis ich mal rausbekommen hatte, dass die TabView ihre Items neu sortiert, wenn man eines entfernt, hätte ich fast meinen kostbaren iMac vor Wut gegen die Wand getreten. Ist aber auch nirgends wirklich dokumentiert. Ich hatte mich nur immer über die tollen, unvorhersehbaren Abstürze gewundert, die die TabView verursachte, wenn man in der Tabbar einen Tab geschlossen hatte.

Zu sehen ist hier eine geskinnte Version der Tabbar. Das Standard-Theme ist immer noch dass des Safaris.

cheers

von CustomGadgets und Gepfusche

d-bug — Sun, 01 Nov 2009 00:06:05 +0100

Hallo Welt,

nachdem ich nun einen Großteil der standard Gadgets wieder hergestellt habe, dachte ich mir, ich versuch mich mal an einer Art ProxyGadget. Da ich die Safari-Tabs ziemlich knorke finde, hab ich also angefangen genau jene mal nachzubauen. Selbst Apple hat diese Tabs nur hingepfuscht. Die Leiste hat eigentlich rein garnichts mit der eigentlichen NSTabView am Hut. Diese kann nämlich keine verschiedenen Styles oder gar einen Schließen-Button auf den Controls darstellen. Schaut man sich mal die Resources im Safari-Paket an, kommt man schnell dahinter, dass diese Tabs nur aus einzelnen Images und ein paar Buttons bestehen.

Viel gerede um den heißen Brei. Am besten zeig ich euch mal ein Image, wie weit ich bereits damit bin:

Was bereits funktioniert:
Man kann bereits Tabs hinzufügen ("+" rechts in der Leiste) und Tabs schließen ("X" auf den Tabs). Außerdem kann man dies auch programmiertechnisch machen.

Was ich noch implementieren MUSS:
Auf jeden Fall die eigentliche TabView! Im Moment geht es nur um die eigentliche Leiste mit den Tabs. Außerdem muss ich noch auf inactive Fenster reagieren, denn es sieht recht dumm aus, wenn die Fenster gedimmt werden, die Tabbar aber so bleibt. Außerdem wird der Schließen-Button nicht ordnungsgemäß angezeigt, wenn man ein Tab geschlossen hat und das nächste unter die Maus hüpft.

Was ich noch implementieren MÖCHTE:
Verschieben der Tabs innerhalb der Leiste! Eine AccessoryView, auf der man eigene Gadgets in die Tabs packen kann, wie z.B. einen ProgressIndicator oder dergleichen...

Das ganze ist mir blankem BlitzMax-Code entstanden und natürlich unter Verwendung von CocoaExt. Bei letzterem musste ich allerdings den Buttons noch einen Flag verpassen, der ihnen das zeichnen des Hintergrundes untersagt.

Das ganze sieht, im Moment noch, ohne Toolbar ziemlich unfein aus. Dazu muss ich dem Fenster erst mal beibringen können, auf die unterste schwarze Kante der Titlebar nicht zu zeichnen.

Achso, die eigentliche NSTabView (die mit CreateTabber bei MaxGUI erstellt wird) kann jetzt die Controls oben, unten, links oder rechts haben. Außerdem kann man ihr gar keine Controls zuweisen (das brauche ich für z.B. die Tabbar). Davon hab ich keinen Screen parat, aber ihr könnts mir auch so glauben.

Bis dahin!

ScrollView und Placards

d-bug — Sat, 24 Oct 2009 16:28:05 +0200

Hallöle!

Erst einmal zu der sicherlich aufkommenden Frage: "Was sind Placards?"
Placards sind eigentlich nichts anderes als Buttons, die bei einer ScrollView links oder rechts neben dem horizontalen Scroller, oder über und unter dem vertikalen Scroller liegen. Dazu wird der jeweilige Scroller gekürzt um genügend Raum für die Buttons zu schaffen. Warum die nun Placards heißen, kann ich euch auch nicht sagen, aber ich hab den Namen trotzdem mal aus der Apple Interface Guideline übernommen.

Im Moment hab ich es leider erst fertig gebracht, dem horizontalen Scroller solche Placards aufzuzwingen, was schon hart genug war, da es dafür eigentlich keine Unterstützung seitens Cocoa gibt. Die Dinger müssen also mühsam von Hand gecodet werden. Mühsam vor allem, weil man dafür NSScrollView subclassen muss um ihr mit der Methode "tile" feinsäuberlich zu erklären, dass sie gefälligst den Scroller gekürzt zeichnen soll. Das nervte unglaublich und steht mir noch für die vertikalen Scroller bevor.

Es ist außerdem nur möglich die Placards entweder links oder rechts vom Scroller zu haben, aber keinesfalls auf beiden Seiten.

Um das ganze so einfach wie Möglich zu gestalten setze ich als Placard eine NSView, die dann wiederum mit Buttons oder dergleichen bestückt werden kann. Man muss sich allerdings darüber im klaren sein, dass man erstens: Vorher schon wissen muss wie groß der Raum sein soll - und zweitens: Das wenn man ein ChildGadget des Placards mit FreeGadget löscht, dort ein weißer Raum übrig bleibt!

So, noch ein wenig lausig formatierten Code: (ich hasse es alle Tabs rausnehmen zu müssen)
[syntax="bmax"]SuperStrict

'-----------------------------------------------------------------------------------------------------------------------------------
' import CocoaExtension framework
'-----------------------------------------------------------------------------------------------------------------------------------
Framework chaos.cocoaext

'-----------------------------------------------------------------------------------------------------------------------------------
' callbacks
'-----------------------------------------------------------------------------------------------------------------------------------
Function CallBack_EndApplication (Event:TEvent)
End
End Function

Function CallBack_OnAction (Event:TEvent)
Print Event.toString ()
End Function

'-----------------------------------------------------------------------------------------------------------------------------------
' set application event callbacks
'-----------------------------------------------------------------------------------------------------------------------------------
CocoaRegisterEventCallback (NSApp, EVENT_APPTERMINATE, CallBack_EndApplication)

'-----------------------------------------------------------------------------------------------------------------------------------
' create a window
'-----------------------------------------------------------------------------------------------------------------------------------
Global MyWindow:TGadget = CocoaCreateWindow (AppTitle, NSCenter,200, 400, 200,, NSWindowDocument, NSWindowHasTitlebar | NSWindowIsResizable, 32)
CocoaRegisterEventCallback (MyWindow, EVENT_WINDOWCLOSE, CallBack_EndApplication)
SetMinWindowSize (MyWindow, 200, 20)

'-----------------------------------------------------------------------------------------------------------------------------------
' create a scrollview without autohiding scrollers
'-----------------------------------------------------------------------------------------------------------------------------------
Global MyScrollview:TGadget = CocoaCreateScrollView (10,10,380,180, MyWindow, NSBezelBorder)
CocoaRegisterEventCallback (MyScrollView, EVENT_GADGETACTION, CallBack_OnAction)

'-----------------------------------------------------------------------------------------------------------------------------------
' add a pixmap-panel as documentview to the scrollview (has to be simplified)
'-----------------------------------------------------------------------------------------------------------------------------------
Global DocumentView:TGadget = CocoaCreateView (704,320)
Global Panel:TGadget = CreatePanel (0,0,704,320,DocumentView)
SetPanelPixmap (Panel, LoadPixmapPNG (AppDir+"/data/tileset.png"), PANELPIXMAP_TILE)
CocoaScrollViewSetDocumentView (MyScrollView, DocumentView)

'-----------------------------------------------------------------------------------------------------------------------------------
' create tilesize-unit for 32x32 sized tiles
'-----------------------------------------------------------------------------------------------------------------------------------
Global Tiles32:String = CocoaCreateRulerUnit ("Tiles32", "t32", 32.0, 2.0, 0.1)

'-----------------------------------------------------------------------------------------------------------------------------------
' add rulers to the scrollview and set their units to Tiles32
'-----------------------------------------------------------------------------------------------------------------------------------
Global hRuler:TGadget = CocoaCreateRuler (MyScrollView, NSHorizontal)
CocoaSetMeasurmentUnits (hRuler, Tiles32)
Global vRuler:TGadget = CocoaCreateRuler (MyScrollView, NSVertical)
CocoaSetMeasurmentUnits (vRuler, Tiles32)

'-----------------------------------------------------------------------------------------------------------------------------------
' add horizontal placard with buttons on it
'-----------------------------------------------------------------------------------------------------------------------------------

Global hPlacard:TGadget = CocoaCreateScrollViewHorizontalPlacard (MyScrollView, 120, NSLeft)

Global MyButton:TGadget = CocoaCreateButton ("Button", -1, 0, 52, 18, hPlacard, NSSmallSquareBezelStyle,,NSSmallFont)
CocoaRegisterEventCallback (MyButton, EVENT_GADGETACTION, CallBack_OnAction)

Global MyPullDown:TGadget = CocoaCreatePullDownButton ("Pulldown", 50, 0, 72, 18, hPlacard, NSSmallSquareBezelStyle,,NSSmallFont)
For Local i:Int = 1 To 10
CocoaCreateMenu ("Item "+i, MyPullDown)
Next

'-----------------------------------------------------------------------------------------------------------------------------------
' Mainloop
'-----------------------------------------------------------------------------------------------------------------------------------
Repeat
WaitEvent ()
Forever[/syntax]
... das ist der ganze code für die Erstellung des Fensters, dass auf folgendem Screen zu sehen ist:

ScrollView, RulerView und spezielle Einheiten

d-bug — Mon, 19 Oct 2009 20:34:32 +0200

Guten Abend!

Da ich gestern Abend noch anfing die ScrollView wieder zu implementieren, dachte ich mir, ich mach es gleich mal richtig und verpasse dem Lineal (RulerView) mal die Möglichkeit eigene Einheiten zu verpassen. Erst dachte ich das sei Hexenwerk und wollte schon einen Scheiterhaufen errichten, aber dann war es plötzlich doch recht einfach.

Zu Testzwecken habe ich dann mal irgendein Tileset aus dem Netz gezogen, es auf ein Panel gepackt und in der ScrollView anzeigen lassen. (Im Moment noch über den Umweg einer NSView)

Als nächstes hab ich dann eine Einheit namens "Tiles32" generiert. Das ganze wird bei CocoaExt an die ScrollView übergeben. Intern wird diese dann der NSRulerView Klasse als neue Unit (Einheit) übergeben und Systemweit installiert. Natürlich nur, solange man nicht neu starten, hoffe ich zumindest. Leider lässt sich die systemweite Installation nicht vermeiden.

Der Code sieht in etwa so aus:
[syntax="bmax"]Global Tiles32:String = CocoaCreateRulerUnit ("Tiles32", "t32", 32.0, 2.0, 0.1)
Global MyScrollview:TGadget = CocoaCreateScrollView (10,10,380,180, MyWindow,NSBezelBorder, NSScrollViewHasVerticalRuler | NSScrollViewHasHorizontalRuler, Tiles32)
Global DocumentView:TGadget = CocoaCreateView (704,320)
Global Panel:TGadget = CreatePanel (0,0,704,320,DocumentView)
SetPanelPixmap (Panel, LoadPixmapPNG ("/data/tileset.png"), PANELPIXMAP_TILE)
CocoaScrollViewSetDocumentView (MyScrollView, DocumentView)
[/syntax]
Wie schon gesagt noch mit Umweg über die NSView Klasse, hier mit CocoaCreateView erstellt. Dieser Umweg fällt aber zukünftig flach, sobald ich das Panel in einen TCocoaExtGadget Ableger gepackt habe.

Die ganzen Werte der Funktion CocoaCreateRulerUnit kann man hier nachlesen. Die Reihenfolge der Übergabevariablen entspricht der, der Tabelle.

Das Ergebnis sieht dann so aus:

so, das war es auch schon wieder.