CocoaExt

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

Worklogs CocoaExt

Die SplitView des Todes und anderer Müll

Sonntag, 18. Oktober 2009 von d-bug
Da ich hier so lange schon nichts mehr schrieb, werd ich mal kurz eine Zusammenfassung der aktuellen Geschehnisse bezüglich CocoaExt zum besten geben.

NSSplitView
Es ist mir nun endlich gelungen diese miese kleine Drecksklasse zu vollenden. Natürlich immer noch nicht ganz ohne Fehler. Man kann nun zwar nur noch zwei Views pro SplitView haben, aber dafür sind diese ausgereifter. Man kann der SplitView z.B. jetzt 3 Divider-Styles zuweisen, allerdings funktioniert der dritte nur ab SnowLeopard.

Außerdem kann man jetzt die Hauptview einklappen lassen. Das heißt bei OSX "collapse"... Einklappen ist in dem Fall nichts anderes, als wenn man den Divider über einen bestimmten Punkt hinaus zieht, die eine View komplett verschwindet. Ist schlecht zu erklären... Man kann der SplitView ebenfalls sagen, dass sie bei einem Doppelklick auf den Divider auch einklappen soll. Letzteres funktioniert aber auch erst ab SnowLeopard.

Man kann einer SplitView jetzt auch das automatische Speichern der Divider-Position als Flag zuweisen. Da ist allerdings ein riesen Bug drin, den ich auch nach stundenlanger Recherche im Netz nicht beheben konnte. Setzt man SplitView in SplitView speichert das System zwar alle Daten korrekt in die MyApp.plist ab, kann sie aber nur für die oberste (den Parent) wieder richtig setzen. Ich hab den SplitViews also einen Flag verpasst, bei dem man selbst entscheiden kann ob man die Daten speichern will oder nicht!

Es gibt auch noch einen Flag der bewirkt, dass die rechte bzw. untere View beim vergrößern der SplitView die angegebene Größe behält. Im Normalfall machen das die linke oder obere View. Dieses verhalten kann man sehr schön im Finder beobachten, wenn man mal das Fenster vergrößert/verkleinert. Die Linke View (die blau-graue) behält ihre Breite und die rechte wird angepasst.


NSWindow
So, um "ich" (den User) zu beruhigen, hab ich die ganze Fenstergeschichte ebenfalls überarbeitet. Nun ist es auch möglich den Brushed-Window-Style zu verwenden, damit man am ganzen Fenster ziehen kann, so wie wohl VLC das kann. Ich finde diesen Style zwar immer noch total widerlich, aber was man nicht alles tut für den Weltfrieden.

NSColorWell
Na, da hatte ich doch glatt übersehen, dass Cocoa bereits einen "ColorButton" besitzt... Nun ja, diesen hab ich dann jetzt mal implementiert. Der Vorteil ist, dass wenn man den anklickt springt der Farb-Requester auf und der Button passt im Hintergrund dynamisch seine Farbe der gewählten Farbe des Requesters an.

SystemVersion
Da ich eine Möglichkeit brauchte die Version von OSX abfragen zu können, hab ich mich mal mit "Gestalt" beschäftigt. Gestalt beinhaltet so ziemlich alles was man schon immer über das System wissen wollte. Da ich aber nur die Version benötigte hab ich auch nur das aus Gestalt extrahiert. Ausgegeben werden mir ausgehend von der aktuellsten OSX-Version "10.6.1" oder "1061".

Ich hab das ganze auch noch mal in ein mini-super-sonder-extra-modul namens chaos.gestaltwandler gepackt. Falls das jemand haben möchte kann er sich bei mir melden. Hier bekomme ich auch noch den Namen der Version ausgegeben, wenn mir danach ist.

Insgesamt...
...gabs gefühlte 3.000.000 Änderungen unter der Haube. Leider hab ich noch immer nicht alles durchgezogen, was ich durchziehen wollte. Es bedarf also noch einiger Zusatzarbeiten.

An alle Nutzer der alten Version noch mal der Hinweis:
Baut sie nicht zu fest ein, denn sobald ich die neue soweit habe, dass sie massentauglich wird, werd ich die alte SVN-Version überschreiben. Die neue ist zu ca. 99% inkompatibel zu der alten.

Einen noch für den Hyde:
EventCallbacks funktionieren jetzt wohl auch bei dir. Hatte eine kleine Krücke eingebaut, die allerdings durch Zufall bei mir funktionierte und bei dir nicht. Gaaaaanz tiefes Loch in dem ich versinken sollte!


...bitte geht weiter, heute gibts hier nichts zu sehen...

Event handling

Freitag, 2. Oktober 2009 von d-bug
Nun ja, da ich zu verschiedenen Anlässen auch schon mal verschiedene Arten des Event handlings benötige, kam ich zu dem Schluss, dass CocoaExt das können sollte, ohne dass man jedes mal einen tollen Hook dafür schreiben muss oder anderweitige Verränkungen anstellen muss. Außerdem läuft im Hintergrund ohnehin schon ein Hook, der einige Events von CocoaExt manipuliert, um es etwas einfacher zu gestalten.

Da ich also ein netter Mensch bin unterstützt CocoaExt nun 3 Arten des Event handling.

1. Event basierend
Das ganz normale Handling, dass MaxGUI von Haus aus schon mitbringt. Meiner bescheidenen Meinung nach sind diese ewig langen Select-Case abfragen super unübersichtlich und ultra nervig.

2. Callbacks
Jeder Instanz eines CocoaExt-Gadgets kann ein Callback pro Event zugewiesen werden, der aufgerufen wird, wenn der Event getrickert wird. Dieser Callback sollte als Übergabevariable immer Event:TEvent haben.

Kleines nicht all zu kompliziertes Beispiel:
BlitzMax: [AUSKLAPPEN]
'Der Application selbst einen Callback zuweisen
'NSApp ist ein vordefiniertes Gadget, dass nur auf EVENT_APP... Events reagiert.
CocoaRegisterEventCallback (NSApp, EVENT_APPTERMINATE, CallBack_EndApplication)

'Dem Fenster den gleichen Callback zuweisen
Global MyWindow:TGadget = CocoaCreateWindow (AppTitle, NSCenter,50, 800, 600,NSApp, NSWindowDocument, NSWindowHasTitlebar|NSWindowIsResizable, 32)
CocoaRegisterEventCallback (MyWindow, EVENT_WINDOWCLOSE, CallBack_EndApplication)

Function CallBack_EndApplication (Event:TEvent)
End
End Function

'der komplette Main-loop
Repeat
WaitEvent ()
Forever

Dieses Beispiel weist sowohl dem Event EVENT_APPTERMINATE und dem Event EVENT_WINDOWCLOSE den gleichen Callback zu. Ihr seht sicher den Vorteil, dass man nicht mehr Mühsam mit einer ellenlangen Select-Case Abfrage alle Fenster abklappern braucht um das Hauptfenster zu schließen. Man weißt dem Hauptfenster nur noch diesen Callback zu und das war es auch schon.

Der Callback kann jede X-beliebige Funktion sein, solange sie nur die eine Übergabevariable Event:TEvent hat. Immer wieder sehr schade, dass BlitzMax das Überladen von Funktionen und Methoden nicht unterstützt...



3. Methoden basierendes Event-Handling
Sozusagen die Unterstützung für subclassing. Damit ist es nämlich nun auch möglich von jedem CocoaExt Gadget ein Subklasse zu erstellen. In dieser kann man dann auf die Methoden reagieren die für einen bestimmten Event zuständig sind.

Auch hierzu noch ein kleines Beispiel:
BlitzMax: [AUSKLAPPEN]
'Subklasse von TCocoaExtWindow erstellen
Type TMeinDrolligesFenster Extends TCocoaExtWindow

Method New ()
init (AppTitle, NSCenter,50, 800, 600, NSApp, NSWindowDocument, NSWindowHasTitlebar|NSWindowIsResizable, 32)
End Method

'Method die für den Event EVENT_WINDOWCLOSE zuständig ist
Method onClose (Event:TEvent)
End
End Method

End Type

'Neue Instanz der Subklasse erstellen
Global MeinFenster:TMeinDrolligesFenster = New TMeinDrolligesFenster

'der komplette Main-loop
Repeat
WaitEvent ()
Forever

Also eher die oopige Variante des Event-Handling...


So, generell gesehen schraube ich immer noch an den Innereien von CocoaExt herum. Hab schon einige Bugs aus der alten Version beseitigen können und einige Features, die mir nicht gefielen, anders gestaltet (z.B. geben Toolbaritems jetzt keine Strings mehr zurück sondern sind vollwertige Gadgets). Das Umbauen auf einzelne Klassen pro Gadget ist nicht umbedingt die Erfüllung meines Lebens, aber nur so kann ich eben alles gestalten wie ich es will.


Ich hoffe es gefällt soweit...

Bis dann!

NSMenuItem - Custom MenuItems

Sonntag, 27. September 2009 von d-bug
Hurra, gerade hatte ich noch mal so ein kleines Erfolgserlebnis. Ich hatte mich schon immer gewundert, wie Apple wohl diesen Sucheintrag in ihr Hilfe-Menü bekommen haben... Ihr wisst schon, der der aussieht wie SpotLight, aber nur in der Hilfe sucht. Bislang hatte ich völlig übersehen, dass Menüs auch NSView basierende Gadgets als Menüeintrag verwenden können. Das macht die Sache doch gleich viel interessanter. Da ich ohnehin gerade die ganze Menügeschichte umbaute, habe ich noch die Möglichkeit eingebaut diese View-Items zu erstellen.

user posted image

Nachteil an der Geschichte ist allerdings, dass der Button vorher auf ein NSView-Gadget gelegt werden muss, um ihn auf dem Menü zu zentrieren. Macht man dies nicht, liegt er ganz links am Rand und kann auch nicht mehr verschoben werden!

Noch ein kleiner Codeschnipsel:
BlitzMax: [AUSKLAPPEN]
Global MyCustomMenu:TGadget = CocoaCreateMenu ("Custom", MyWindow)
Global MyView:TGadget = CocoaCreateView (0,0,200,50)
Global MyViewButton:TGadget = CocoaCreateButton ("View Gadget",NSCocoaExtCenter,NSCocoaExtCenter,100,24, MyView, NSTexturedRoundedBezelStyle)
Global MyViewButtonItem:TGadget = CocoaCreateMenuView (MyCustomMenu, MyView)


Man kann hier gut erkennen, dass dieses NSView-Gadget keinen Parent hat. Das ist so, da ich es gerade auf die schnelle zusammen gepfuscht habe, um was testen zu können.

Weiterhin kann man sehen, dass die Funktion CocoaCreateMenu auf den Einsatz von Tags verzichtet. Brl nennt die Int-Identifier für Menüs eben Tag... Wenn es gewünscht ist, dass ich diese Tags drin lassen soll, dann sagts mir. Also ich brauch die Dinger auf jeden Fall nicht! Ich finde die eher umständlich, weil man meistens ja doch die Daten vom Gadget selbst braucht und nicht den Identifier des MenuItems... Wozu die eigentlich gut sind weiß ich bis heute nicht...

Man kann übrigens der Funktion CocoaCreateMenuView noch einen Modus namens NSCloseMenuAfterViewAction übergeben, der dafür sorgt, dass das Menü nach drücken des Buttons (in diesem Fall) auch wieder geschlossen wird. Dieser Modus ist standard!


Ein Strich!

Freitag, 25. September 2009 von d-bug
-----------------------------------------------------------------------------------------------------------------------------------
Symbolischer Schlußstrich für diese Version


So, ab hier gibt es jetzt Infos zu der nächsten Generation!

Um dem gerecht zu werden was ich von CocoaExt verlange, hab ich mal angefangen ein zwei Sachen zu ändern. Zum einen werden alle Gadgets jetzt in eigene Types gestopft. Das macht mir das Erweitern um einiges einfacher, auch wenn ich erst mal den ganzen alten kram nachziehen muss.

Zum Thema Lokalisierung gibts was neues feineres als maxgui.localization. Diese wird zwar unterstützt, kann aber leider keine Requester übersetzen und wird es nach dem jetzigen System auch nie können. Stattdessen habe ich mich näher an das eigentliche Lokalisierungs-Gedöns von Cocoa ran gewagt. Dieses hat verschiedene Vorteile. Es kann eine Applikation direkt Übersetzen, ohne großen Umwege über so genannte Tags dazu bedarf es aber eines *.strings-file in dem Applikations-Paket selbst. Dem Gadget wird einfach der englische Text zugewiesen und in dem strings-file steht dann die Übersetzung ins Deutsche. Das App-Paket braucht für jede Sprache die unterstützt werden soll ein strings-file. Wie man die anlegt werde ich noch genauer in der Dokumentation erklären.

Im Zuge der Lokalisierung hab ich mir gedacht, dass es doch auch ganz nett wäre andere Dinge direkt ins App-Paket zu legen. Leider funktioniert das im Moment nur mit Dateien, auf die direkt von Cocoa aus zugegriffen werden kann z.B Images. Der Plan sieht so aus: Man wird mit einem prefix, ähnlich wie "incbin::" diese resourcen laden können. Dies wird aber nur mit CocoaExt möglich sein, da hier die Images ohnehin nur als Pointer zu einem NSImage existieren. Wahrscheinlich wird es auch bei den Images bleiben müssen.

Aus diesem Grund habe ich mir (und den CI Leuten die zum testen verdammt sind) eine neue BMK-Version zurecht geschnitzt, der alle Daten aus einem Ordner namens "Resources", der im gleichen Ordner liegen muss wie das Hauptfile des Projekts, beim kompilieren in das App-Paket kopiert. Danach wird dieser Ordner nur noch zum neu kompilieren benötigt. Darin kann man auch das Wunsch-Icon für sein Projekt verstauen. Da der BMK ohnehin frei verfügbar ist (source liegt ja bei) werd ich den wohl irgendwann auch mal veröffentlichen. Aber erst muss ich ein wenig länger testen.

So, aus Gründen der nationalen Sicherheit, habe ich auch den kompletten NameSpace mal etwas umgebaut. ALLE öffentlichen Funktionen werden ab jetzt mit "Cocoa" beginnen. Die Types fangen alle mit "TCE an"

Nach dem großen blalbla nun mal einen Screen der übersetzten Customize-Palette von Toolbars:
user posted image

dazu noch ein Schnipselchen aus dem strings-file:
Code: [AUSKLAPPEN]
/* Palette label for show colors toolbar item.
   Toolbar label for show colors toolbar item. */
"Colors"            = "Farben";

/* Palette label for show fonts toolbar item.
   Toolbar label for show font toolbar item. */
"Fonts"               = "Schriften";

/* Palette label for the generic print toolbar item.
   Toolbar label for the generic print toolbar item.*/
"Print" = "Drucken";

/* Tooltip for show colors toolbar item. */
"Show Color Panel" = "Farbfenster anzeigen";

/* Tooltip for show font toolbar item. */
"Show Font Panel" = "Schriftfenster anzeigen";

/* Tooltip for the generic print toolbar item. */
"Show Print Panel" = "Druckfenster anzeigen";

Das sind ALLE zu übersetzenden Strings für die komplette Lokalisierung der ganzen Toolbar-Funktionalität. Alle weitern werden direkt vom System übersetzt, OHNE das man sie selbst angeben muss. (aber es braucht trotzdem das strings-file, auch wenn es leer ist) Falls es wer nicht kennt: Alles was mit "/* */" umgeben ist sind Kommentare.





Eine neue Version im Repository wird es wohl die nächste Zeit nicht geben, da die, an der ich gerade knechte, zur alten nicht mehr kompatibel sein wird.

MaxGUI 1.34 und CocoaExt

Mittwoch, 9. September 2009 von d-bug
Erst mal die Gute Nachricht, CocoaExt läuft mit MaxGUI 1.34 zusammen! Es gibt keinerlei Probleme beim kompilieren.

Die schlechte Nachricht ist, dass Sebs neues maxgui.localization Modul zwar grundsätzlich importiert wird, aber nicht auf alle CocoaExt Gadgets angewendet werden kann. Der Tag {AppName} wird wohl zu Problemen führen, genau wie die Tatsache, dass Seb die ganze Lokalisierung der Gadgets auf die Methode TGadget.SetText ("blub") beschränkt hat, die ich nicht mal Ansatzweise verwende, da ich ja die alternativen Labels auch anbiete.

Kurzum, ich würde die Lokalisierung vorerst nicht auf mit CocoaExt erstellte Gadgets anwenden. Ich werde dieses Manko noch beheben, allerdings weiß ich nicht, ob dass so schnell gehen wird, da ich nächste Woche erstmal in Urlaub bin!

Wie auch immer, wenigstens läuft CocoaExt mit MaxGUI 1.34 zusammen. Ihr müsst nur CocoaExt neu kompilieren, falls die MaxIDE es nicht automatisch machte. (Das müsst ihr eh bei neuen MaxGUI Versionen immer machen Razz)

Grüße

NSScrollView #1

Sonntag, 6. September 2009 von d-bug
Lange Zeit war es sehr ruhig hier, aber ich musste mir erstamal ein Strategie überlegen, wie ich das leidige Thema NSTableView wohl angehen könnte. BRL machte es sich da einfach, indem es der ListBox nur eine Spalte gönnte. Eigentlich kann die TableView allerdings viel mehr...

Nun hab ich allerdings erst mal begonnen den Teil zu machen, der dabei für das Scrollen zuständig ist. Um das ganze zu testen hab ich auch noch ein neues Gadget implementiert, dass einfach nur ein Bild darstellt. Aber fangen wir erst mal von vorne an... :



- entfallen / + hinzu / #geändert

+ CreateCocoaScrollView (X, Y, W, H, Parent, Style, Modes)
Die ScrollView ist eigentlich nur ein dummes Gadget, was von alleine noch nicht sehr viel kann. Es dient dazu einem Dokument oder auch einem zu groß geratenen Gadget das Scrollen zu ermöglichen. BRL hat die Scrollview direkt mit in die TreeView und in die ListBox eingebaut, haben aber leider nicht daran gedacht, dass es dem User auch Spaß machen würde andere Dokumente darstellen zu wollen.

Außerdem besitzt eine Scrollview drei verschieden Arten einen Rahmen darzustellen. BRL hat den komplett abgeschaltet. Mit der Übergabevariable Style kann man nun mit NSLineBorder, NSBezelBorder und NSGrooveBorder diese Rahmen auswählen oder mit NSNoBorder abschalten.

Scrollviews können auch nur eine der beiden Scroller haben, oder zwischen automatisch ausblendenen oder immer eingeblendeten Scrollern unterscheiden. Dies wird hier mit der Übergabevariable Modes bewerkstelligt. Wird NSScrollViewAutohidesScrollers werden die Scroller automatisch ausgeblendet, wenn es nichts zu scrollen gibt. Mit NSScrollViewHasNoVerticalScroller und NSScrollViewHasNoHorizontalScroller kann man die Scrollbars abschalten wenn man das möchte.



+ SetCocoaScrollViewDocument (ScrollView, Document)
Mit dieser Funktion legt man nun ein Dokument auf die ScrollView. Aber obacht, dass geht nicht mit jedem Gadget als Dokoment. Ich muss allerdings noch rausfinden, welche nicht funktionieren und sie vorher filtern.



+ CreateCocoaImageView (X, Y, Image, Parent)
Eigentlich erstellt diese Funktion nur ein Panel und legt mit SetPanelPixmap ein Image drauf. Allerdings wird im Unterschied zur normalen Methode hier das Panel in der Größe des Bildes erstellt. Außerdem kann man auch die NSNamedImage, also die vom System bereitgestellten Images verwenden.


Da das alles noch nicht ganz ausgereift ist, hab ich das mal noch nicht im SVN geupdatet. Das behalte ich mir noch vor, bis alles ohne zu zicken geht.


Natürlich noch ein Screen:
user posted image
Hier hab ich eine ScrollView erstellt und mittels CreateCocoaImageView und SetCocoaScrollViewDocument
ein zu großes Image drauf gelegt.



Ich weiß, dass es bereits ein ScrollView ProxyGadget von SebHol gibt, aber seien wir mal unbescheiden, dieses hier ist irgendwie schneller :>. Außerdem brauche ich es um andere Gadgets erstellen zu könnnen z.B. die TableView.


cheers

~edit 06.09.2009 / ca. 14:30~

user posted image

# CreateCocoaScrollView (X, Y, W, H, Parent, Style, Modes, Units)
Mit den Styles NSScrollViewHasHorizontalRuler und NSScrollViewHasVerticalRuler können jetzt noch sogenannte Ruler angezeigt werden. Diese Lineale können auch noch verschiedene Einheiten haben, die man mit der Übergabevariable Units setzen kann. Im Moment gibt es da nur die vorgefertigten Einheiten: NSRulerInches, NSRulerCentimeters, NSRulerPoints, NSRulerPicas und NSRulerPixels. NSRulerPixels ist die gleiche Einheit wie NSRulerPoints, soll aber dem besseren Verständnis dienen.

# HideCocoaGadget, ShowCocoaGadget und GadgetCocoaHidden
Da man bei einer ScrollView die verschiedenen Unter-Views einzeln ausblenden sollen kann, gibt es für diese drei Funktion, die ja zum aus/einblenden auch einen Identifier nutzen können, nun die extra Konstanten NSScrollViewScrollerHorizontal, NSScrollViewScrollerVertical, NSScrollViewRulerHorizontal und NSScrollViewRulerVertical. Gibt man keinen Identifier an, wird die komplette ScrollView mit Dokument ausgeblendet.

Enable/Disable ist bei einer ScrollView im Moment nicht möglich! Vielleicht find ich ja noch was darüber.


cheers^2


~edit 06.09.2009 / ca. 17:30~
SVN Repository Update ist oben!

cheers^3

NSDrawer #1

Montag, 31. August 2009 von d-bug
Huhu,

sicher kennt ihr auch diese komischen, veraltet anmuteten Gadgets, die bei Fenstern links, rechts und unten schon mal dran kleben. Das sind sogenannte Drawer. Meist sind sie ausfahrbar...

- entfallen / + hinzu / #geändert

+ CreateCocoaDrawer (Size, Window, Side)
Die Funktion erstellt diese oben genannten Gadgets. Da NSDrawer schon beim erstellen eine NSView benötigt, habe ich kurzerhand ein Panel genommen und drauf gelegt. Dieses Panel wird auch zurückgegeben. Macht aber nix, HideCocoaGadget, ShowCocoaGadget und GadgetCocoaHidden wurden darauf trainiert das zu erkennen und den Drawer einfahren zu lassen. Mit Size wird nur die Höhe bei den Drawern oben oder unten am Fenster, oder die Breite der Drawer links und rechts am Fenster angegeben. Den Rest macht das Gadget selbst. Bei Side kann man zwischen NSDrawerLeft, NSDrawerRight, NSDrawerAbove, NSDrawerBelow wählen, welches jeweils die Seite des Fensters meint, an der der Drawer dargestellt werden soll.

Screen:
user posted image
Sieht irgendwie aus wie die Abwicklung einer Kiste...

cheers

NSLevelIndicator #1 / NSProgressIndicator #3

Sonntag, 30. August 2009 von d-bug
Heute mal ohne viel TamTam und große Worte:

- entfallen / + hinzu / #geändert

+ CreateCocoaLevelIndicator (X, Y, W, H, Parent, Style, MaxValue, TickMarkAmount, MajorTickMarkAmount)
Erstellt einen sogenannten Level-Indicator, mit dem man z.B. die Lautstärke oder denn Füllstand einer Batterie anzeigen lassen kann. Mit dem NSDiscreteCapacityLevelIndicatorStyle kann man die Unterteilung setzen (siehe Indikator 3-6 auf dem Screen) . TickMarkAmount setzt wie bei CreateCocoaTracker die Skala, nur kann man hier auch noch markante Punkte setzen (siehe Indikator 1 auf dem Screen)

+ CreateCocoaRatingIndicator (X, Y, Parent, MaxValue)
Kennt man aus iTunes! Ist das 5-Star-Ranking, mit dem man die Tunes bewerten kann. (Nr. 7 auf dem Screen)

+ CreateCocoaRelevanceIndicator (X, Y, W, Parent, MaxValue)
ist ähnlich wie CreateCocoaRatingIndicator nur werden hier Linien statt Sterne angezeigt. Man nutzt es eben um die Relevanz eines Eintrags in einer Liste anzuzeigen. z.B. Bei Ergebnissen von Suchbegriffen.

+ SetCocoaLevelIndicatorAlertValues (LevelIndicator, Warning, Critical)
Hiermit kann man Werte auf einen LevelIndicator setzen, bei denen gewarnt (gelb) oder bei denen es kritisch (rot) werden soll. Bei Ranking- und RelevanceIndicator funktioniert da gar nichts.

# CreateCocoaProgressIndicator
Hier hab ich noch die Möglichkeit eingebaut einen anderen Maxmimalwert als 1.0 zu verwenden. Jetzt ist es auch Möglich direkt mit Prozenten zu arbeiten. Man setzt einfach die Übergabevariable MaxValue auf 100 und ab gehts.

# SetCocoaGadgetMaxValue
Wurde ja schon bei Steppern eingeführt, hat aber jetzt auch Unterstützung für die ganzen Indikatoren.

Ein Screen:
user posted image

und wieder raus...

NSSlider #1 / NSScroller #1

Samstag, 29. August 2009 von d-bug
... und als wäre es heute noch nicht genug gewesen...

- entfallen / + hinzu / #geändert

+ CreateCocoaSlider (X, Y, Size, Parent, Style, MinValue, MaxValue)
Kleiner Beipass für CreateSlider und SetSliderRange, außerdem werden horizontale und vertikale Slider in Höhe oder Breite begrenzt. Bei Style kann nur noch SLIDER_VERTICAL oder SLIDER_HORIZONTAL angegeben. Horizontal ist standard.

+ CreateCocoaScroller (X, Y, Size, Parent, Style, MinValue, MaxValue)
Nun ja, der gleiche Beipass allerdings inklusive der SLIDER_SCROLLBAR variable. (Das Ding heißt bei Cocoa wirklich nur Scroller)

+ CreateCocoaTracker (X, Y, Size, Parent, Style, TickMarkAmount, TickMarkModes, MinValue, MaxValue)
Ebenfalls eine Slider, allerdings mit Skala und anderem Knopf. Außerdem kann die Skala an verschiedene Seiten gesetzt werden und der Rückgabewert auf die Skale limitiert werden.

+ CreateCocoaCircularSlider (X, Y, Parent, MinValue, MaxValue)
Ein runder Slider eben... wobei die Größe hier immer 30x30 ist.

+ CreateCocoaCircularTracker (X, Y, Parent, TickMarkAmount, TickMarkModes, MinValue, MaxValue)
...natürlich auch rund... wobei die Größe hier wegen der Skala immer 34x34 ist.

Bildchen noch:
user posted image
noch ohne Scroller, aber den kennt ja eh jeder...

und wieder raus

Sheets für jeden!

Samstag, 29. August 2009 von d-bug
Hallo,

quasi als Abfallprodukt des Quicklook-Features hab ich gelernt, wie man Custom-Sheets erstellen kann, ohne die ganze WindowView bzw. ToolView Klasse von BRL umschreiben zu müssen. Daraus entstand nun folgendes:

- entfallen / + hinzu / #geändert

+ CreateCocoaSheet (W, H, Style)
Erstellt ein neues unsichtbares Sheet und gibt es als TGadget Objekt zurück. W und H dürften klar sein, Style sind die Styles, die auch bei CreateWindow angegeben werden können. Allerdings wird derzeit davon nur WINDOW_RESIZABLE unterstützt. Alle anderen machen auf einem Sheet keinen Sinn.

+ OpenCocoaSheet (Sheet, Window)
Öffnet das Sheet, lässt es also unterhalb der Title- und/oder Toolbar einblenden. Sheet ist das Sheet das eingeblendet werden soll und Window das Fenster auf dem es eingeblendet werden soll.

+ CloseCocoaSheet (Sheet)
Schließt das Sheet wieder.

WICHTIG:
Man muss unbedingt darauf achten, dass man dem Sheet einen Button verpasst, der die Funktion CloseCocoaSheet aufruft. Ansonsten hat man keine Chance mehr das Sheet zu schließen. Einfach Parent-Fenster zu schließen ist auch nicht möglich, da ein Sheet modal ist, also das Fenster deaktiviert wird.



Außerdem hatte ich irgendwie keine Lust mit den Sheets anzufangen und hab mal eine Funktion geschrieben, die das Dock-Icon hüpfen lässt. Leider sieht Cocoa nicht vor, dass man das auch will, wenn das Fenster auch aktiv ist. Geht also nur bei deaktivierten Fenstern.

+ RequestCocoaUserAttention (Critical)
Lässt das Dock-Icon ein mal springen, solange das Fenster inaktiv ist. Critical lässt es kontinuierlich springen.


Noch flott ein Screen zum Sheet:
user posted image


Als letztes ist noch zu berichten, dass es nur einen Fehler nach dem Update auf Snow Leopard gab und auch noch gibt, da er aus einer Funktion aufgerufen wird, die sich in dem Modul brl.system befindet. Bei RequestCocoaDir erscheint in der Konsole eine Cocoa-Fehlermeldung, aber das Programm läuft weiter. Dies betrifft eigentlich die BRL Funktion RequestDir. Wird also nicht von mir gefixt werden. Der Fehler ist gemeldet und Brucey hat wohl dafür gesorgt, dass er in der nächsten Version von BlitzMax behoben ist.


bis dann...


Flux noch hinterhergeworfen:

+ SetCocoaDockIconBadgeLabel (Label)
Wir kennen doch alle die tollen Nachrichten Anzeigen, die AppleMail da auf seinem Dock-Icon produziert?! Das können wir jetzt auch (siehe Screen)! Möchte man den Text wieder los werden ruft man die Funktion einfach noch mal auf ohne ein Label zu übergeben.

user posted image

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