DockingPanes, RibbonBar,...

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

DockingPanes, RibbonBar,...

Beitrag von satmax »

Gibt es für Xbase++ V2 vernünftige Ansätze für RibbonBars, DockingPanes und eine CaptionBar? Sollte natürlich ThreadSave sein.
Gruß
Markus
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: DockingPanes, RibbonBar,...

Beitrag von AUGE_OHR »

satmax hat geschrieben:Gibt es für Xbase++ V2 vernünftige Ansätze für RibbonBars, DockingPanes und eine CaptionBar?
was soll sich mit der v2.x gegenüber v1.9x verändert haben das die üblichen 3-PP Tools (ActiveX, DllCall) sich anders verhalten sollten ?

Ribbonbar :
eine "statische" Ribbonbar ist "out" wenn man Richtung (Full-Screen) Kachel-Design denkt.
vielmehr müsste die Ribbonbar ein-/aus-geblendet werden wenn man mit der Maus in den Bereich fährt ...

DockingPanes :
hm ... im Grunde ein "abgeteilter" Bereich -> wie wäre XbpSplitbar() ? ( in XppUi3.dll enthalten )

CaptionBar :
du meinst den oberen Platz gleich unter der Titlebar ?
unter Windows 7 sah das nett aus wenn man den Bereich, mit DWM, auch transparent machte wie die Titlebar.
unter Windows 8x / 10 wird zwar auch die "Farbe" der Titlebar übernommen aber es sieht aus als eine XbpStatic().

Die Tools die nun wirklich optisch massive Änderungen bringen sind die "Skin" Tools womit man eigene Themes,
statt dem OS() Theme, für "seine" Xbase++ Application verwenden kann.


mit Codejock Skinframework habe ich nur mit dem horizontalen Ownerdraw Menu ein Positions-Problem ...
und mit meinen native Controls in der DXE LIB weil ich den visual Style selbst setze ( aber es gibt ja Ownerdraw ... )
satmax hat geschrieben:Sollte natürlich ThreadSave sein.
wenn mehrere Instanzen verwendet werden sollte das doch kein Problem darstellen (oder woran hast du gedacht) ?
gruss by OHR
Jimmy
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von Herbert »

satmax hat geschrieben:Sollte natürlich ThreadSave sein.
Ein neuer Begriff? Meinst du z.B. das Ein- und Ausblenden bestimmter Elemente je nach Situation (obwohl ich das eher störend empfinde, wenn eine Option mal in der Mitte erscheint, mal weiter rechts oder gar nicht...), die dann plötzlich falsch dastehen?
Jimmy hat geschrieben:eine "statische" Ribbonbar ist "out" wenn man Richtung (Full-Screen) Kachel-Design denkt.
Ich denke nicht unbedingt. Denn es gibt kaum eine Applikation für alles. Alleine die unterschiedlichen Auflösungen und Grösssen der Bildschirme verhindern ein Generaliesieren. Für mich sind Kacheln unschön und unflexibel.
Wenn schön, möchte ich die Kacheln in Grösse veränderbar haben oder sogar in 3D. So hätte ich immerhin 6 verschiedene Funktionen auf einer "Kachel".
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von satmax »

AUGE_OHR hat geschrieben:was soll sich mit der v2.x gegenüber v1.9x verändert haben das die üblichen 3-PP Tools (ActiveX, DllCall) sich anders verhalten sollten ?
Weniger mit 2.x, eventuell gibt es ja neue AddOns, ActiveX oder ähnliches. Ich Forum sind die letzten Einträge dazu doch schon einige Jahre alt. Meine Hoffnung war das es eventuell da etwas neues gibt (ActiveX, DllCall) .
AUGE_OHR hat geschrieben:Ribbonbar :
eine "statische" Ribbonbar ist "out" wenn man Richtung (Full-Screen) Kachel-Design denkt.
vielmehr müsste die Ribbonbar ein-/aus-geblendet werden wenn man mit der Maus in den Bereich fährt ...
Für die nächste 2-(3) Jahre wäre mir eine "einfache" RibbonBar schon recht. Eventuell heißt dann die Zukunft wirklich Windows Universal Apps. Im Moment ist es mir dazu etwas zu früh. Wobei hier könnte man mit Hausmittel einiges machen.
AUGE_OHR hat geschrieben:DockingPanes :
hm ... im Grunde ein "abgeteilter" Bereich -> wie wäre XbpSplitbar() ? ( in XppUi3.dll enthalten )
Aber nur im Grunde, mit Docking ist da nichts. Aber eventuell würde es reichen.
Ich würde halt gerne die normalen Fenster mit TabViews ersetzen, mit der Möglichkeit, diese abzudocken und als eigenes Fenster darzustellen. Im Moment mache ich das mit eigenen Fenstern, jedes Fenster bekommt im Mainframe unterhalb des Menüs einen Button, ähnlich einem Tab.
AUGE_OHR hat geschrieben:CaptionBar :
du meinst den oberen Platz gleich unter der Titlebar ?
Ja so ungefähr, auch das würde man unter Xbase++ halbwegs hinbekommen
AUGE_OHR hat geschrieben:Die Tools die nun wirklich optisch massive Änderungen bringen sind die "Skin" Tools womit man eigene Themes, statt dem OS() Theme, für "seine" Xbase++ Application verwenden kann.
Was sind die Skin Tools?

@Jimmy&Herbert
Mit ThreadSave meinte ich, das jedes DockingWindow (DockingPane, TabWindow) als eigener Thread möglich sein sollte.
Gruß
Markus
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von Tom »

Hallo, Markus.

Der Quasi-Standard für derlei ist die CodeJock Suite Pro, die von umfangreichen Button-Klassen über Kalender-Controls und Docking Panes, Skins und RibbonBars alles enthält, was man sich in diesem Bereich wünschen könnte. Es gibt sie u.a. als .NET-Library, aber auch als AX-Komponente:

www.codejock.com

Ich habe sie mir vor vier oder fünf Jahren gekauft und besitze deshalb eine etwas ältere Version (13.5), aus der ich anfangs die DockingPanes, das SkinFramework, die CommandBars (Ribbon) und anderes verwendet habe. Inzwischen sind nur noch der TaskDialog und ein paar vereinzelte Buttons übrig. Das liegt vor allem daran, dass die Ansteuerung frickelig, langsam und nicht immer verlässlich war. Vielleicht sollte ich mal aktualisieren, denn ich denke darüber nach, etwas der RibbonBar zumindest ähnliches anzubieten. Ob ich das mit Codejock mache, ist eine andere Frage, denn ich habe mir inzwischen viele Controls per Ownerdrawing selbst nachgebaut, darunter ein sehr umfangreiches und ungeheuer flexibles Kalender-Control.

Microsoft hat mit Windows 10 nicht ohne Grund einen großen Schritt zurück gemacht. Kacheln und Vollfenstertechnik sind in einigen Bereichen sehr sinnvoll, aber Fenster - auch überlagernde/überlappende - sind es zuweilen eben auch. Großflächige Dialoge mit vielen Informationen erschweren die Konzentration und die Suche nach den richtigen Informationen. Sich situationsabhängig anbietende (kleinere) Fenster sind mittelfristig viel produktiver. Wer Anwendungen hat, die sich für Kacheln und Vollfenstertechnik eignen - z.B. Kassensysteme -, der sollte das machen, aber andere sollten sich keineswegs verrückt machen lassen, weil irgendwer erzählt, dass das die Zukunft wäre. Weil es nicht stimmt. Insofern sind Ribbons und ähnliche Controls längst nicht am Ende. Weshalb die Office-Komponenten und fast alle anderen MS-Programme auch damit arbeiten.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von Tom »

Ach so: Skinning ist einfach nur Bullshit. Das ist ein lustiges Gimmick für Vorführungen, aber im täglichen Einsatz völlig belanglos. Und es hat einen originellen Nebeneffekt, den wir erleben mussten: Einige Anwender hatten sich wirklich, wirklich hässliche Skins ("Wooden Style", "Neon" und ähnliche) ausgewählt. Neue Mitarbeiter, die unsere Anwendung in dieser Optik sahen, fanden das in einigen Fällen so hässlich, dass sie sich gegen die Nutzung der Software gewehrt haben. :wink:
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von Jan »

Tom,

da stimme ich Dir zu. Wenn auch aus einem anderen Grund. Ich finde es für (produktives) Arbeiten total ätzend, wenn der Entwickler der Software meinte er müsste sich grafisch in der Oberfläche austoben und zeigen, was der so alles drauf hat. Nix Windows-konformes. Und vor Allem: Nicht die Farben, die ich mit in "meinem" Windows eingestellt habe. Wie kommt der dazu mir vorschreiben zu wollen, wie sein Programm auf meinem Bildschirm aussehe soll?

Von daher bin ich ein Fan davon, nach Möglichkeit alles so zu lassen, das die Einstellungen, die der Kunde/Anwender für seinen Desktop eingestellt hat, auch in meiner Software wiederzufinden.

Um aber auf die Eingangsfrage zurückzukommen: Es stimmt, das Alaska nicht sehr flott darin ist, aktuelle Gestaltungselemente, die Windows bietet, in eigene XBParts zu übertragen. Ich denke auch das da nichts mehr kommen wird. Aus dem einfachen Grund das Alaska sich auf die WebUI konzentriert. Wenn die irgendwelche Sachen neu einbauen, dann in dieser Darstellung, aber nicht mehr als XBPart. Das Einzige, was ich in der 2.0 neu gefunden habe, war die Splitbar. Die aber aus einem XBPack übernommen worden ist, also auch nicht wirklich sooo neu. Halt nur ohne Zusatzbibliotheken nutzbar.

Tom, warst Du es nicht, der früher mal auf die Problematik der Ribbons hingewiesen hat? Das die Office-Ribbons von MS geschützt sind, und wer die verwendet, muß das immer in der gerade aktuellen Form machen, die MS herausgegeben hat? Da war doch mal irgend sowas in irgendeiner uralten Diskussion. Was einen natürlich nicht daran hindern muß, sich seine eigenen Ribbons zusammenzuschreiben. Muß doch nicht immer alles nach MS Office aussehen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von satmax »

Tom hat geschrieben:Hallo, Markus.

Der Quasi-Standard für derlei ist die CodeJock Suite Pro, die von umfangreichen Button-Klassen über Kalender-Controls und Docking Panes, Skins und RibbonBars alles enthält, was man sich in diesem Bereich wünschen könnte. Es gibt sie u.a. als .NET-Library, aber auch als AX-Komponente:

http://www.codejock.com
Wäre interessant ob es im Forum hier jemanden gibt der die aktuelle Version von Codejock einsetzt und uns seine Erfahrungen mitteilen könnte.
Gruß
Markus
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: DockingPanes, RibbonBar,...

Beitrag von AUGE_OHR »

satmax hat geschrieben:Wäre interessant ob es im Forum hier jemanden gibt der die aktuelle Version von Codejock einsetzt und uns seine Erfahrungen mitteilen könnte.
Das Problem waren weniger die Codejock Controls sondern Xbase++ ...
Jan hat geschrieben:Nix Windows-konformes. Und vor Allem: Nicht die Farben, die ich mit in "meinem" Windows eingestellt habe.
die Skin Tools verwenden Theme was Windows konform sein muss ... sonst würde der visual Style nicht funktionieren und hat nichts mit "Farben" zu tun hat.
besonders bei Windows 10 ist der visual Style teilweise nicht zu sehen ( aktive Fenster, aktiver Tab etc. ) und da hilft es enorm wenn man einen anderen visual Style hat wo man was erkennen kann.
p.s. klar kann man "on-fly" das Theme auswählen so wie ein User sein Desktop Bild.
Tom hat geschrieben:Insofern sind Ribbons und ähnliche Controls längst nicht am Ende. Weshalb die Office-Komponenten und fast alle anderen MS-Programme auch damit arbeiten.
ich sagte nicht das die am Ende sind sondern das eine "feste" Ribbonbar "out" ist. gerade im "Vollbild" Modus soll ja nichts mehr stören und Platz wegnehmen.
Satmax hat geschrieben:Ich würde halt gerne die normalen Fenster mit TabViews ersetzen, mit der Möglichkeit, diese abzudocken und als eigenes Fenster darzustellen. Im Moment mache ich das mit eigenen Fenstern, jedes Fenster bekommt im Mainframe unterhalb des Menüs einen Button, ähnlich einem Tab.
du meinst so wie bei Firefox wo ich einen Tab "abdocke" und ein neues Fenster ensteht ?
das "abdocken" ist doch "nur" der Wechsel des Parent ...
gruss by OHR
Jimmy
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: DockingPanes, RibbonBar,...

Beitrag von satmax »

satmax hat geschrieben:du meinst so wie bei Firefox wo ich einen Tab "abdocke" und ein neues Fenster ensteht ?das "abdocken" ist doch "nur" der Wechsel des Parent ...
Ja, das kommt schon in etwa hin. Habe da aber null Plan wie das in Xbase++ gehen sollte.
Gruß
Markus
Antworten