CocoaExt

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2, 3, 4, 5  Weiter

Worklogs CocoaExt

Download Version 0.02alpha

Samstag, 8. August 2009 von d-bug
So, da ich nun doch etwas zeitiger fertig war als gedacht, präsentiere ich hiermit voller Stolz und weichen Knien, die erste öffentliche Alpha von CocoaExt.

Deutsche Download Seite

und da ich ja weiß, dass ich sozusagen beobachtet werde...

English Download Page <-- only for degac Wink

So, viel Spaß damit und vegebt mir Ungereimtheiten und Fehler!

Erstes Etappenziel erreicht!

Samstag, 8. August 2009 von d-bug
So, nachdem ich nun noch die PopUp-und PullDown-Buttons implementiert habe ist das erste Etappenziel schon mal erreicht. Fehlt noch ein wenig an Dokumentation und dann gibts demnächst Version 1 zum Download.

Ich hatte ja irgendwo in den Kommentaren mal behauptet ich wolle das nicht tun, bevor man nicht zumindest die Toolbar des Finders simulieren könne. Nun ja...

user posted image

... ich denke man kann das wohl jetzt. Wink


Es werden eine paar Samples beiliegen, die genug über das erstellen solcher Gadget aussagen um damit arbeiten zu können. Natürlich ist das alles eher beta, aber wenigstens wird man es sich schon mal ein wenig ansehen können.

Wenn das ganze Modul auch zu sonst nichts gut ist, so hat es anscheinend zumindest dabei geholfen SebHoll aufzuwecken. Er scheint wieder ein wenig Hirn in MaxGUI stecken zu wollen, wie die letzten Threads auf bb.com im GUI-Bereich suggerieren.

Rechnet mal nicht vor morgen mit dem Modul...

bis dahin!

NSSegmentedControl #2

Dienstag, 4. August 2009 von d-bug
Tja, dazu gibts was neues:

- entfallen / + hinzu / #geändert

+ Menu Support für NSSegmentedControl

kurzer Auszug aus den CocoaExt-Tutorials...
BlitzMax: [AUSKLAPPEN]
'create segmented control and center it on the windows client rect
Global MyControl:TGadget = BeginCocoaSegmentedControl (NSCocoaExtCenter, NSCocoaExtCenter, 210, MyWindow)

'create a menu with a couple of items and set menus parent to the segmented control
Global MyMenu:TGadget = CreateMenu ("Menu", 0, MyControl)
CreateMenu ("MyItem 1", $1001, MyMenu)
CreateMenu ("MyItem 2", $1002, MyMenu)
CreateMenu ("MyItem 3", $1003, MyMenu)
CreateMenu ("MyItem 4", $1004, MyMenu)
CreateMenu ("MyItem 5", $1005, MyMenu)

'create some segments and add the created menu to the first segment
Global MyControlSegmentA:String = AddCocoaSegmentedControlItem ("Menu", 50, MyControl, , MyMenu)
Global MyControlSegmentB:String = AddCocoaSegmentedControlItem ("B", 50, MyControl)
Global MyControlSegmentC:String = AddCocoaSegmentedControlItem ("C", 50, MyControl)
Global MyControlSegmentD:String = AddCocoaSegmentedControlItem ("D", 50, MyControl)

'end segmented control
EndCocoaSegmentedControl (MyControl)


Somit sieht man auch schon ein wenig, dass eine SegemntedControl ähnlich aufgebaut ist, wie eine Toolbar. Also von den Funktionen her.


# Controller zusammengefasst
Bis gestern Abend gab es noch mehrere Controller für die Obj-C Komponente von CocoaExt. Ich bemerkte auch erst, dass dies ein Fehler war, als ich versuchte das erste mal ein CocoaExt-Gadget als ViewItem auf eine Toolbar zu legen. Siehe Screen. Durch das Zusammenlegen funktionierts jetzt auf jeden fall problemlos.

user posted image

Keine Panik, ein Tutorial, wie man so eine iCal-Toolbar macht liegt auch bei... Smile

So, ich bin wieder raus! Bis zum nächsten mal...

NSSegmentedControl #1 und andere...

Sonntag, 2. August 2009 von d-bug
Moinsen,

kommen wir erst mal zu den anderen...

Anstatt nun für jedes Gadget oder Item eine seperate Enable/Disable-, Show/Hide- und Select- Funktion zu haben, hab ich das abermals geändert und präsentiere nun:

- entfallen / + hinzu / #geändert

- HideGadget, ShowGadget und GadgetHidden Support für Buttons
- DisableGadget, EnableGadget und GadgetDisabled Support für Buttons
- SetButtonState und ButtonState Support für Buttons

+ HideCocoaGadget, ShowCocoaGadget und GadgetCocoaHidden Support für alles
+ DisableCocoaGadget, EnableCocoaGadget und GadgetCocoaDisabled Support für alles
+ SelectCocoaGadget und GadgetCocoaSelected Support für alles
Diese sind nun in der Lage auch auf CocoaExt Items (z.B. ToolbarItems) angewendet zu werden. Außerdem haben die jetzt den Support für MaxGUI gadgets eingebaut. Mal sehen, vielleicht bekomme ich die normalen MaxGUI Items auch noch gebacken.


Nächstes Gadget gefällig? Komplett neu und noch nie in MaxGUI vorhanden gewesen?

NSSegmentedControl #1
Eigentlich sind die nicht anders zu sehen, als z.B. Tabs oder dergleichen. Es ist eben eine Reihe von Buttons. Cocoa sieht das allerdings als einen langen Button mit verschiedenen Segmenten. Jedes Segment bekommt eine ID, auf diese dann reagiert werden kann.


Da ich damit noch in den Kinderschuhen stecke, gibt es erst mal nur noch einen Screen dazu.
user posted image

In späteren Posts gibts dazu vielleicht noch ein wenig mehr zu sagen. Allerdings nicht mehr heute.

NSButton #2

Samstag, 1. August 2009 von d-bug
So, nachdem ich mich nun mehrere Stunden durch die Buttons gewuselt habe, kann ich voller Stolz berichten, dass dieses Thema nun auch mehr oder weniger beendet ist.

NSButton #2

- entfallen / + hinzu / #geändert

+ CreateCocoaColorButton
Tja, der ist ein echter Sonderfall, den gibt Cocoa als solches nämlich auch nicht her. Da ich den aber ziemlich oft mal gebraucht habe, hab ich Ihn kurzerhand eben auch eingebunden. Eigentlich ist es ein normaler Button, der auf eine Größe von 24x24 begrenzt ist. Auf diesem Button ist eine Pixmap deren Pixel eben neue Farbe bekommen, wenn man denn eine zuweisen möchte. Das ganze kann per EventCocoaData abgerufen werden. Kein Hexenwerk, aber ab und zu doch ziemlich nützlich.

# Alpha in Pixmaps
Liebes Volk von BRL, was sollte das denn nun wieder? Wieso zwingt ihr Cocoa dazu Pixel mit Alpha-Wert in einer Pixmap mit dem Hintergrund zu vermischen? Hm? Das war äußerst unschön und sorgte für Transparenz-Fehler ohne Ende. Also gut, da ich das original Cocoa-Modul nicht anfasse, hab ich kurzerhand die Pixmap-NSImage Konvertierungsfunktion kopiert und den passenden Flag wieder einkommentiert. Ihr lest richtig, das war schon mal in MaxGUI integriert, wurde aber auskommentiert. Was auch immer das sollte.

# CreateCocoaButton
Jau, außer den Features die er eh schon hatte, kam noch die Unterstützung von Images hinzu (Siehe Screen). Man kann auch Alternativ-Images setzen, muss dazu aber einen ImageContainer verwenden, den ich gleich noch erklären werde.

+ TCocoaImageContainer
Tja, irgendwie brauchte ich eine Möglichkeit mit nur einem Parameter in CreateCocoaButton zwei Images übergeben zu können. Ein Object-Array kam nicht in Frage, da dies auch nur mit einer Klasse gefüllt werden darf. Immerhin kann der Image-Parameter mit Strings, TPixmap-Objekten und NSImageNamed...-Objekten gefüttert werden. Letztere sind eine Wrapperklasse für Integer, da es ja bekanntlich nicht wirklich möglich ist Int nach Object zu casten. Wie auch immer, ich machte eben eine Art Container-Klasse auf. Diese beinhaltet ein Interger-Array mit den Pointern zu den NSImage Objekten von Cocoa. Man könnte fast meinen es wäre ein TIconStrip, hm? Nur dass TIconStrip ganze Pixmaps speichert! Also mehr Speicher frisst und auch langsamer ist, weil die Pixmaps jedesmal konvertiert werden, wenn sie Verwendung finden. Mein Container da macht das beim einspeichern des Images nur ein mal und behält dann nur den Pointer.

+ CreateCocoaImageContainer (Image:Object, AlternateImage:Object)
Diese Funktion erstellt einen solchen Container und kann eben mit den Image-Daten für die beiden möglichen Image-States gefüttert werden.

+ AddCocoaImageToContainer (Container:TCocoaImageContainer, Image:Object)
Diese Funktion erstellt einen neuen Eintrag in dem Container. Nicht das wir uns missverstehen, CreateCocoaButton braucht nur die Einträge 0 und 1 in dem Array des Containers. Da ich aber früher oder später noch die Toolbars auch aus einem Container erstellen lassen will muss man eben ein wenig mehr Einträger einfügen können.

Schätzungsweise kommen im Laufe der Entwicklung von CocoaExt noch mehr Methoden und Funktionen für die Container-Klasse hinzu.

+ NSCocoaExtCenter, NSCocoaExtRight und NSCocoaExtBottom
Dies sind kleine Helferlein, die beim Aufruf eines Gadgets für eine einfachere, aber primitive Positionierung sorgen sollen. Folgender Aufruf von CreateCocoaHelpButton zentriert zum Beispiel den Button automatisch horizontal auf seinem Parent (siehe Screen):

BlitzMax: [AUSKLAPPEN]
CreateCocoaHelpButton (NSCocoaExtCenter, 5, MyParent)


Das funktioniert aber nur während des Aufrufs und nicht etwa auch, wenn man z.B. bei dem Fenster die Größe ändern würde.


Noch der Screen des Tages...
user posted image


Das Thema Button ist somit vorerst abgeschlossen. Als nächstes nehme ich mir die NSSegmentControl-Klasse vor. Dabei handelt es sich z.B um die geteilten vor/zurück in Safari, und die NSPopupButton-Klasse, damit man einem Button auch lecker Menüs verpassen kann.

NSButton #1 / NSToolbar #7 (doch nicht final)

Dienstag, 28. Juli 2009 von d-bug
NSToolbar #7

- entfallen / + hinzu / #geändert

# HideCocoaToolbar (MyToolbar)
wurde aus Kompatibilitätsgründen in HideGadget (MyGadget:TGadget) integriert.

# ShowCocoaToolbar (MyToolbar)
wurde aus Kompatibilitätsgründen in ShowGadget (MyGadget:TGadget) integriert

# GetHiddenCocoaToolbar (MyToolbar)
wurde aus Kompatibilitätsgründen in GadgetHidden (MyGadget:TGadget) integriert

Wie ich es liebe, wenn ich ständig dazu tendiere das Rad neu erfinden zu wollen! Könnte mich selbst dafür ohrfeigen.



NSButton #1

- entfallen / + hinzu / #geändert

+ CreateCocoaButton (Label, X, Y, W, H, Parent, BezelStyle, ButtonTypen, Modes, Image, AlternateImagel)
wobei ich noch nicht 100%ig weiß, ob der Funktionsaufruf auch wirklich so bleibt... Modes, Images und AlternateImages sind noch nicht drin... Auch dazu muss ich in einem der nächsten Posts mal ausführlicher werden.

Label:
...und AlternateLabel. Bei manchen Buttonarten wie z.B. dem NSMomentaryChangeButton, oder dem NSToggleButton sieht man nur eine Veränderung, wenn man ein alternatives Label parat hat. Diese alternativen Labels werden bei CocoaExt folgendermaßen angegeben: "HauptLabel|AlternativLabel" z.B. "ich bin der Hauptgrund für diesen button|dafür bin ich total alternativ, du" oder "Mach was|Mach was anderes". Dies geht auch mit Images, aber das hab ich noch nicht mit eingebaut.

BezelStyle (Aussehen):
Weil ich zu faul bin die alle zu benennen, hier der Link zu Apple-Dev da könnt ihr alle nachlesen. NSHelpButtonBezelStyle ist allerdings in einer eigenen Funktion untergebracht und wird nicht mehr peer Konstante mitgeliefert.

ButtonType (Verhalten/Art):
Auch hier wieder der Link zu Apple-Dev... Wie man sehen kann, hab ich da mächtig die ButtonTypes zusammengekürzt. NSSwitchButton und NSRadioButton bekamen eigene Funktionen und die anderen sind im Verhalten teilweise identisch. Ich nehme mal an, dass es sich dabei um Altlasten aus früheren OSX-Versionen handelt.

to be continued...


+ CreateCocoaHelpButton (X, Y, Parent)
dazu gibts irgendwann mal mehr, nebst Bild und dergleichen... Jetzt sei nur gesagt, dass es sich dabei um den rosa, kreisförmigen Button mit dem ? drauf handelt.

+ CreateCocoaSwitchButton (Label, X, Y, W, Parent, Modes)
Normale Checkbox, kann allerdings mit einem Modus Namens NSButtonMixedState dreifach geschaltet werden.
Siehe dazu den Screen weiter unten...

+ CreateCocoaRadioButton (Label, X, Y, W, Parent)
Naja, ein Radiobutton eben. Nix besonderes, aber CreateCocoaButton hat schon zu viele Flags und dergleichen. Wink



Noch einen Screen der bisherigen Ergebnisse:
user posted image

Toolbar & ToolbarItems final (hoffentlich)

Samstag, 25. Juli 2009 von d-bug
So, hab heute die letzten Kniffe in die Toolbars eingebaut.

- entfallen / + hinzu / #geändert

+ HideCocoaToolbar (MyToolbar)
Toolbar ausblenden

+ ShowCocoaToolbar (MyToolbar)
Ausgeblendete Toolbar wieder anzeigen

+ GetHiddenCocoaToolbar (MyToolbar)
Sichtbarkeits-Status der Toolbar abfragen

+ RemoveCocoaToolbarItem (MyToolbar, MyIdentifier)
Item aus dem sichtbaren Bereich der Toolbar entfernen

# BeginCocoaToolbar #1
Neuer NSToolbarStartHidden Flag mit dem man eine Toolbar auch ausgeblendet aufrufen kann. Verhindert das kurze aufflackern der Toolbar, wenn man nach Erstellung einfach HideCocoaToolbar nutzen würde.

# BeginCocoaToolbar #2
NSToolbarAllowsCustomization kam letztens ja schon hinzu, wurde aber jetzt nochmal übearbeitet. Er wird jetzt
beim Kompilieren des Codes nur im Release-Modus berücksichtigt, weil er während des Programmierens schon mal für Verwirrung sorgen kann. Schuffelt man gerade an der Toolbar rum und man entfernt dabei ein Item aus dem Code wird das nicht erkannt, da in der PList der Applikation das Item noch vorhanden ist. Man muss dann die PList löschen. Nix für Noobs... :>

# AddCocoaToolbarIconStrip
unterscheidet jetzt zwischen einem und zwei leeren Icons. Ein leeres Icon = Separator, zwei leere Icons = Flexible Space

# NSApplicationIcon
nach nochmaligem kompletten durchlesen der Dokumentation von NSImage auf apple.dev hab ich noch eine variable gefunden, die es einem ermöglichen soll das Icon der Applikation als NSImage zu erhalten. Das hab ich dann noch flux eingebaut. Nachteil bei der Geschichte ist aber, dass das nur im Release-Mode richtig funktioniert.
Im Debug-Modus bekommt man das Icon für Applikationen ohne eigenes Icon angezeigt. (Das Blatt mit dem Bleistift).


Generelles
Generell hat sich unter der Haube noch einiges getan. Einen Fehler hab ich z.B. noch behoben, der das korrekte erstellen einer Toolbar mit BeginCocoaToolbar verhindert hat. Da hab ich vergessen, dass man für den standard SizeMode und den standard DisplayMode nicht einfach zwei Flags addieren kann, sondern das es sich dabei um extra Flags bei Cocoa handelt.

Außerdem hab ich noch die ganze Dokumentation für den Toolbarbereich geschrieben. Das war schon hart genug. Ich hasse bbdoc einfach nur! >:O

NSToolbarItem #5

Mittwoch, 22. Juli 2009 von d-bug
Ihr sehts schon, dass mit der Toolbar ist eine längere Geschichte...

Also, es ist mir soeben gelungen, ohne großen Aufstand, sogenannte View-Items zu realisieren. Mit denen ist es nun möglich bestimmte Gadgets auf eine Toolbar zu zeichnen, anstatt auf ein Fenster. So in etwa wurde z.B. die Toolbar des Finders realisiert. Das sind normale NSButton-Views die in ein View-Item gepresst wurden. Auf MaxGui übertragen sinds also mit CreateButton erstellte Buttons...

So zur Einstimmung, hab ich mich erst mal an einem Textfield versucht. Man gönnt sich ja schonst nichts!

Der Aufruf:
BlitzMax: [AUSKLAPPEN]
Global MyTextFieldView:TGadget = CreateTextField (0,0,200,24,MyToolbar,0)
Global MyViewItem:String = AddCocoaToolbarViewItem (MyToolbar, MyTextfieldView, "My First View Item", "Hurrrrrrrrrrrraaaa")

Wie man sieht, muss zuerst das normale Gadget erstellt werden, bevor man es mittels AddCocoaToolbarViewItem in ein ToolbarItem presst. Das war auch schon das ganze Geheimnis. Label und Tooltip müssen natürlich auch noch übergeben werden. Alles weitere erfolgt über normale MaxGUI-Befehle auf das Gadget. Also nicht auf das Item! In dem Fall MyTextFieldView.

Die Events:
Gibts nicht viel zu zu sagen. Es werden einfach die Events von dem erstellten Gadget ausgegeben! Also für das oben genannte Beispiel die Events EVENT_GADGETACTION mit dem EventSource MyTextFieldView! Eigentlich wird bei den Dingern der Identifier für das ToolbarItem nirgends benötigt.

Ein Bild:
user posted image
so sieht das ganze dann aus. Links sieht man noch die Events die produziert werden. Wobei ich mir da noch per GadgetText (MyTextFieldView) den Text des TextFields ausgeben lasse.

Ihr seht also, dass ist ganz lauer Mist. Da hatte ich einen tierischen Bammel vor, weil ich dachte ich müsste dafür noch die ganzen anderen Gadgets modifizieren. Ging aber doch recht unspektakulär über die Bühne.


~edit 2009-07-24~
Seit gerade eben ist es möglich alle sinnvollen Gadgets, mit oben genannten Funktionen, einem ToolbarItem zuzuweisen. Weniger sinnvolle Gadgets sind: Desktop, Window, TextArea, Listbox, TreeView, HTMLView und Canvas. Alles andere geht problemlos bisher! Sogar die sehr instabile Combobox stellt sich diesmal nicht quer.

NSToolbarItem #4 / CocoaExt #2

Sonntag, 19. Juli 2009 von d-bug
Erst mal zu CocoaExt als ganzes Paket:
Dumm wie ich bin, hatte ich bisher chaos.cocoaext als vollwertigen Ersatz für maxgui.cocoamaxgui ausgelegt. Schlau vielleicht in dem Sinne, dass ich so auch am Controller rumfummeln konnte und ganze Gadgets rausschmeißen konnte. Leider ist wohl die Tatsache, dass ich das dann bei jedem Update von maxgui.cocoamaxgui wieder hätte tun müssen nicht zu leugnen. Mal ehrlich, das hätte ich vielleicht ein oder zwei mal gemacht und hätte dann den Support in eingestellt. Macht ja auch wirklich keinen Spaß, sowas.

Weil mir das Gott sei dank noch eingefallen ist, bevor ich zu viele Gadgets modifiziert habe, hab ich mich nach dem letzten MaxGUI Update direkt erst mal hingesetzt und das ganz als eine Art PlugIn ausgelegt. Solange brl jetzt nicht den Scope zu MaxGUI abermals ändert oder gar grundlegende Klassen eliminiert sollte erst mal nichts passieren, den chaos.cocoaext baut sich jetzt seinen eigenen Controller und auch seine eigenen Klassen, in denen ich ändern kann wie es mir beliebt.

Zu den ToolbarItems und der Toolbar:
Natürlich bleibt so ein Eingriff nicht ohne folgen. Da MaxGUI ja mehr oder weniger auf eine gescheite Lokalisierung pfeifft, hab ich beschlossen den StandardItems die Übergabevariablen Label und Tooltip wieder zu klauen. Zumal die eh nie richtig durchgezogen wurden. Cocoa meinte doch glatt bei dem Print- und bei dem Customize-Item nicht auf den Aufruf von [MyItem setPaletteLabel:MyLabel]; hören zu müssen und einfach trotzdem wieder die englische Übersetzung verwenden zu müssen. Wie dem auch sei, da es ja jetzt die ModifiyCocoaToolbarItem Funktion gibt, kann man die Labels und Tooltips nachträglich trotzdem noch ändern.

Apropos Ändern... Nachdem ich jetzt den ganzen Krams nahezu neu geschrieben habe, funktioniert das Enable/Disable Bool auch wieder. Um ehrlich zu sein habe ich nicht den leisesten Schimmer woran das jetzt gelegen haben könnte. Nun ja, die Items haben jetzt wieder eine Referenz auf die Toolbar. Alle, außer natürlich wieder mal das Print-und das Customize-Item. Die beiden können nach wie vor nicht geändert werden. Irgendwann werde ich de Grund dafür finden! Dann hau ich den beiden dermaßen eins auf die Rübe...

So, aus gegebenen Anlass hab ich dann bei allen AddItem-und bei der BeginCocoaToolbar auf den Einsatz von zu vielen Übergabevariablen verzichtet. BeginCocoaToolbar hat jetzt nur noch zwei. Wobei eine eben jetzt mit übermäßig vielen Flags gefüttert werden kann. So ähnlich, als wolle man ein Window mit CreateWindow erstellen und gibt dann bei Style alle möglichen Flags an.

Wie eben schon erwähnt, haben die meisten ToolbarItems nur noch zwei Übergabevariablen. Zumindest die, die ich bereits wieder einbaute.

Neue Events gibt auch noch bei den Toolbars. Wird ein Item vom System erstellt, wird nun ein EVENT_GADGETOPEN nebst dem Identifier des Items als EventExtra ausgegeben. Wird eines, mittels Customize-Palette oder mittels Remove Item im Kontext-Menü, aus der Toolbar gelöscht, gibt es ein EVENT_GADGETCLOSE.



War heut ne reine Märchenstunde ohne Bilder!

NSToolbarItem #3

Donnerstag, 16. Juli 2009 von d-bug
Wie im ersten Post zu den Toolbars schon angesprochen wurden bisher keine IconStrips unterstützt.
Sie werden es zwar immer noch nicht 100%ig, aber der Grundstein ist zumindest gelegt:

Aufruf:
BlitzMax: [AUSKLAPPEN]
Global TBMyItemArray:String[] = AddCocoaToolbarIconStrip (Toolbar, [MyIconStrip/MyIconStripPath])

Diese Function erstellt aus einem Image oder einem TIconStrip-Object einen Satz Items. Die Identifier der Items werden in einem String-Array zurückgegeben. Dieses Array enthält keine Lücken. Sollte man also ein leeres Icon in seinem Strip haben, dass ja bei MaxGUI dann als Separator dargestellt wird, so gibt es dafür keinen Identifier. Der Seperator wird aber trotzdem noch erstellt. Der ItemStrip kann entweder als Pfad zum Image oder als TItemStrip Object übergeben werden.

Ich werde wohl auch noch den FlexibleSpace integieren, in dem man einfach 2 freie Icons in dem Strip lässt.

Diese mauligen Toggle-Items werde ich allerdings nicht mehr mit rein nehmen, da die ohnehin von BRL nur rein gepfuscht wurden und es bei mir dann später was feineres geben wird, was ich aber jetzt mal noch nicht verraten werde.

Event:
Der übliche EVENT_GADGETACTION mit modifiziertem EventExtra

Screen:
user posted image
Wie man sieht funktioniert es wenigstens schon mal mit dem Iconstrip der MaxIDE. Rechts sieht man auch sehr gut, was passiert, wenn die Toolbar zu kurz für die vielen Items ist.

Abhängige Funktionen:
BlitzMax: [AUSKLAPPEN]
ModifyCocoaToolbarItem (MyToolbar, MyItemIdentifier, MyLabel, MyTooltip)

Dieser Befehl wurde gerade extra für die IconStrip-Geschichte eingeführt. Man kann mit ihm das Label und den Tooltip bearbeiten. Irgendwie will man ja nicht dauernd die automatisch generierten "MyItem0-n" Label sehen müssen.

Lecker Samplecode:
BlitzMax: [AUSKLAPPEN]
Global Window:TGadget 		= 	CreateWindow ("Toolbar-Iconstrip Sample", 100,100, 800, 300, Null, WINDOW_TITLEBAR)

Global Toolbar:TGadget = BeginCocoaToolbar (Window, NSToolbarDisplayModeDefault,NSToolbarSizeModeSmall, True)

Global IconStripItems:String[] = AddCocoaToolbarIconStrip (Toolbar, "data/iconstrip.png")

ModifiyCocoaToolbarItem (Toolbar, IconStripItems[0], "Hello", "Hello World")
ModifiyCocoaToolbarItem (Toolbar, IconStripItems[1], "World", "Hello World")

EndCocoaToolbar (Toolbar)




Schwerwiegender Bug #1:
Mir ist aufgefallen, dass man derzeit keines der Items nachträglich modifizieren kann. Seit drei Tagen suche ich bereits nach dem Grund, warum meine Enable/Disable Funktion in OBJ-C nicht fruchtet. Sie greift zwar das Item direkt an, aber die Toolbar als solches bleibt davon unberührt. Man sieht also nicht, ob das Item gesperrt ist oder nicht. Das gleiche Phänomen tritt dann auch jetzt bei der eben genannten ModifyCocoaToolbarItem Funktion auf.

Normalerweise sollte [MyItem toolbar]; in Obj-C mir den Identifier der Toolbar zurückgeben. Allerdings gibt sie "nil" zurück, was so viel heißt, dass dem Item die Toolbar unbekannt ist. Da muss ich noch ein wenig Schmalz rein investieren.

Kann eigentlich nichts wildes sein, aber gefunden hab ich es eben noch nicht.

Gehe zu Seite Zurück  1, 2, 3, 4, 5  Weiter