Windows Ribbons API

Grafische Primitive, XbaseParts und Darstellungsfragen allgemein.

Moderator: Moderatoren

Antworten
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Windows Ribbons API

Beitrag von mikehoffmann »

Hallo,

ich fange mal ein neues Thema an. Vor fast 3 Wochen habe ich eine kleines Paket geschnürt, mit dem Ihr selber die Ribbons in Eure Anwendung einbauen konntet und habe um Rückmeldungen gebeten, wo es hakt. Zurück kam gar nichts. Doch kein Interessse an einem Ableger für Xbase Parts vorhanden oder keine Probleme?

Ich habe die Biester nun gezähmt, das war ein wilder Ritt. Wie immer stimmt die MS-Doku nicht so ganz und man muss sich erstmal ordentlich die Hörner abstoßen, bevor man rausgefunden hat, wie der Hase wirklich läuft. Jetzt fühle ich mich langsam wohl und ich kann die commands/controls auch schon aus der Applikation modifizieren/erweitern. Ich habe mich durch 3 Objektmodelle durchdesigned, das jetztige funktioniert echt prima und liefert automatisch an die Ribbons, was die so von Zeit zu Zeit anfordern. Die Command Properties sind nun als virtuelle ivars vorhanden und wenn man den Code liest, ahnt man gar nicht, auf welchem Wege die schließlich ins Ribbon-API gelangen. Das sieht alles easy aus, man muss aber ein bissel was beachten, damit es funktioniert. In der Zip-Datei ist auch eine kleine ReadMe.txt mit Tips, was ihr ausprobieren könnt. Um das Webboard nicht mit meinem Müll zu belasten, hier ein Link zur Download-Seite der XCockpit website.

http://www.xcockpit.com/download.html

Da findet Ihr die zip-Datei unter "Temporary Downloads / Windows Ribbon Sample Application".

Vielleicht funktioniert auch dieser direkte Link: http://www.xcockpit.com/files/RibZip.zip

Viele Grüße
Michael
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: Windows Ribbons API

Beitrag von Jan »

Hallo Michael,

nicht, das ich da kein Interesse für hätte. Ich hatte ja schon angemerkt, das ich da gerne von profitieren würde.

Aber ich arbeite weder mit eXpress++ noch mit 1.9. Also kann ich da leider bislang nicht viel mit anfangen.

"Temporary Downloads" macht übrigens garnichts, wenn man das anklickt ...

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

Hallo Jan,
2.0 habe ich auch schon auf einem anderen Rechner zu Testzwecken installiert, es geht alles, aber für meine Anwendungen brauche ich es gar nicht, da ich nur die Sprache und nicht das GUI nutze.
Es scheint vom Browser abzuhängen, was beim Draufklicken passiert. Der direkte Link funktioniert bei mir im Feuerfuchs und im Explorer.
Express++ braucht man nicht für die Ribbons. Nur Windows 7 oder später.
Viele Grüße
Michael
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: Windows Ribbons API

Beitrag von AUGE_OHR »

hi,

um ehrlich zu sein : mir ist das zu kompliziert mit XML

als Xbase++ User erwarte ich eine CLASS wo ich "alles" dort "einstellen" kann.
es gibt zwar nicht viele Beispiele aber "so" wie die Ribbon bei Codejock sind sollte die Syntax schon sein für einen Xbase++ User.

grob gesagt : ich will ja nicht meinen Code / Syntax ändern wenn ich das Control "austausche"
im optimalen Fall hänge ich eine #INCLUDE ein wo die #xtranslate für den "Austausch" sorgen was bedeutet das alle iVAR und Method(en) vorhanden sein müssen.

so denke ich ist der Ansatz nur für ein paar Spezies interessant die sich dafür interessieren "wie" es funktioniert.

p.s. wenn ich die neue Version starte bekomme ich das
Ribbon_Error.jpg
Ribbon_Error.jpg (105.5 KiB) 10000 mal betrachtet
gruss by OHR
Jimmy
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Windows Ribbons API

Beitrag von Rudolf »

Hallo Michael,
schaut sehr interessant aus, aber mir auch leider ein wenig zu kompliziert. Da könnte eXpress++ einiges an Komplexität rausnehmen. Hast Du vor mit Roger Kontakt aufzunehmen ? Wie schon gesagt, ich würdes es mir auch etwas kosten lassen wenn meine Programme ein wenig moderner aussehen.
Grüße
Rudolf
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

@Jimmy: Lies mal die Fehlermeldung genau. Da kann ein Hotkey (Strg+Alt+B) nicht registriert werden, Der Grund ist recht simpel: Das Programm läuft schon einmal. Mit diesem Hotkey (siehe auch EnableKeyboardBreakpoint() in Main) kann ich die Applikation jederzeit anhalten und nachsehen, wie es um sie steht. Den Debugger brauche ich seit Jahren nicht mehr. Wenn Du das Programm nochmal startest und dann mal auf das Hilfe-Fragezeichen drückst kommt dieser Dialog als Breakpoint. Dann klickste mal auf den Callt Trace-Reiter und schon siehste alle Variablen und Parameter inklusive initialen und aktuellen Werten (aus den prg-Modulen, die ich mit meiner CALLTRACE-Option compiliert habe). Da sind jetzt natürlich nur die aus ribbon.prg zu sehen, weil die Library nicht mit dieser Option kompiliert wurde. Das ist Meilen besser als der Debugger, weil sogar die Groß-Kleinschrift sichtbar ist und bei Klassen mit Stammbaum sieht man, welche erbende Klasse gerade tickt und aus welcher Klasse der gerade laufende Code geerbt wurde.

@Rudolf: Ja, Roger habe ich mal angemailt, aber nix gehört.

@ZuKompliziert: Die Komplexität ist moderat, das ist mal wieder eine Scheinriese. Am Ende geht es drum. Die Properties der Commands und Controls nach seinen Wünschen hinzubiegen (siehe RibbonWindow:OnCreate()) und am Ende auf einen Aufruf aus dem Ribbon-Framework zu reagieren (siehe RibbonWindow:RibbonCmd()). Wenn man nachträglich nichts mehr ändern muss oder will, dann reicht das XAML-File. Dann reden wir über 5 Zeilen Code und ein DO CASE-Statement.
Die Anzahl der Properties der Commands hält sich schwer im Rahmen. Das sind sie:

AAdd(::propKeyList,{UI_PKEY_Enabled, .T., "Enabled"} )
AAdd(::propKeyList,{UI_PKEY_LabelDescription, .F., "LabelDescription"} )
AAdd(::propKeyList,{UI_PKEY_Keytip, .F., "Keytip"} )
AAdd(::propKeyList,{UI_PKEY_Label, .F., "Label"} )
AAdd(::propKeyList,{UI_PKEY_TooltipDescription, .F., "TooltipDescription"} )
AAdd(::propKeyList,{UI_PKEY_TooltipTitle, .F., "TooltipTitle"} )
AAdd(::propKeyList,{UI_PKEY_LargeImage, .F., "LargeImage"} )
AAdd(::propKeyList,{UI_PKEY_LargeHighContrastImage, .F., "LargeHighContrastImage"} )
AAdd(::propKeyList,{UI_PKEY_SmallImage, .F., "SmallImage"} )
AAdd(::propKeyList,{UI_PKEY_SmallHighContrastImage, .F., "SmallHighContrastImage"} )
AAdd(::propKeyList,{UI_PKEY_CommandId, .F., "CommandId"} )
AAdd(::propKeyList,{UI_PKEY_ItemsSource, .T., "ItemsSource"} )
AAdd(::propKeyList,{UI_PKEY_Categories, .T., "Categories"} )
AAdd(::propKeyList,{UI_PKEY_CategoryId, .F., "CategoryId"} )
AAdd(::propKeyList,{UI_PKEY_SelectedItem, .T., "SelectedItem"} )
AAdd(::propKeyList,{UI_PKEY_CommandType, .F., "CommandType"} )
AAdd(::propKeyList,{UI_PKEY_ItemImage, .F., "ItemImage"} )
AAdd(::propKeyList,{UI_PKEY_BooleanValue, .T., "BooleanValue"} )
AAdd(::propKeyList,{UI_PKEY_DecimalValue, .T., "DecimalValue"} )
AAdd(::propKeyList,{UI_PKEY_StringValue, .T., "StringValue"} )
AAdd(::propKeyList,{UI_PKEY_MaxValue, .F., "MaxValue"} )
AAdd(::propKeyList,{UI_PKEY_MinValue, .F., "MinValue"} )
AAdd(::propKeyList,{UI_PKEY_Increment, .F., "Increment"} )
AAdd(::propKeyList,{UI_PKEY_DecimalPlaces, .F., "DecimalPlaces"} )
AAdd(::propKeyList,{UI_PKEY_FormatString, .F., "FormatString"} )
AAdd(::propKeyList,{UI_PKEY_RepresentativeString, .F., "RepresentativeString"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties, .F., "FontProperties"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_Family, .F., "FontProperties_Family"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_Size, .F., "FontProperties_Size"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_Bold, .F., "FontProperties_Bold"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_Italic, .F., "FontProperties_Italic"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_Underline, .F., "FontProperties_Underline"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_Strikethrough, .F., "FontProperties_Strikethrough"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_VerticalPositioning, .F., "FontProperties_VerticalPositioning"})
AAdd(::propKeyList,{UI_PKEY_FontProperties_ForegroundColor, .F., "FontProperties_ForegroundColor"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_BackgroundColor, .F., "FontProperties_BackgroundColor"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_ForegroundColorType, .F., "FontProperties_ForegroundColorType"})
AAdd(::propKeyList,{UI_PKEY_FontProperties_BackgroundColorType, .F., "FontProperties_BackgroundColorType"})
AAdd(::propKeyList,{UI_PKEY_FontProperties_ChangedProperties, .F., "FontProperties_ChangedProperties"} )
AAdd(::propKeyList,{UI_PKEY_FontProperties_DeltaSize, .F., "FontProperties_DeltaSize"} )
AAdd(::propKeyList,{UI_PKEY_RecentItems, .F., "RecentItems"} )
AAdd(::propKeyList,{UI_PKEY_Pinned, .F., "Pinned"} )
AAdd(::propKeyList,{UI_PKEY_Color, .T., "Color"} )
AAdd(::propKeyList,{UI_PKEY_ColorType, .T., "ColorType"} )
AAdd(::propKeyList,{UI_PKEY_ColorMode, .F., "ColorMode"} )
AAdd(::propKeyList,{UI_PKEY_ThemeColorsCategoryLabel, .T., "ThemeColorsCategoryLabel"} )
AAdd(::propKeyList,{UI_PKEY_StandardColorsCategoryLabel, .T., "StandardColorsCategoryLabel"} )
AAdd(::propKeyList,{UI_PKEY_RecentColorsCategoryLabel, .T., "RecentColorsCategoryLabel"} )
AAdd(::propKeyList,{UI_PKEY_AutomaticColorLabel, .T., "AutomaticColorLabel"} )
AAdd(::propKeyList,{UI_PKEY_NoColorLabel, .T., "NoColorLabel"} )
AAdd(::propKeyList,{UI_PKEY_MoreColorsLabel, .T., "MoreColorsLabel"} )
AAdd(::propKeyList,{UI_PKEY_ThemeColors, .T., "ThemeColors"} )
AAdd(::propKeyList,{UI_PKEY_StandardColors, .T., "StandardColors"} )
AAdd(::propKeyList,{UI_PKEY_ThemeColorsTooltips, .T., "ThemeColorsTooltips"} )
AAdd(::propKeyList,{UI_PKEY_StandardColorsTooltips, .T., "StandardColorsTooltips"} )
AAdd(::propKeyList,{UI_PKEY_Viewable, .F., "Viewable"} )
AAdd(::propKeyList,{UI_PKEY_Minimized, .F., "Minimized"} )
AAdd(::propKeyList,{UI_PKEY_QuickAccessToolbarDock, .F., "QuickAccessToolbarDock"} )
AAdd(::propKeyList,{UI_PKEY_ContextAvailable, .T., "ContextAvailable"} )
AAdd(::propKeyList,{UI_PKEY_GlobalBackgroundColor, .F., "GlobalBackgroundColor"} )
AAdd(::propKeyList,{UI_PKEY_GlobalHighlightColor, .F., "GlobalHighlightColor"} )
AAdd(::propKeyList,{UI_PKEY_GlobalTextColor, .F., "GlobalTextColor"} )

Das UI_PKEY-Zeugs sind die Konstanten des Ribbon Frameworks und rechts sind die virtuellen ivars meiner UIPropertyBag-Klasse im Xbase. Eigentlich easy. In meinem Testcode probiere ich natürlich alles aus, was geht. Normale Programme sehen anders aus.

Und wem das immer noch zu wild ist: Das nochmal zu wrappen ist auch kein Problem. Aber um den XAML-Code kommt man nicht rum. Der macht mir allerdings die wenigsten Sorgen. Das ist Formularausfüllen.

Ach ja, das Fenster ist resizeable. Schiebt das Ding mal langsam kleiner und genießt, wie alles dynamisch angepasst wird. Das mach richtig Freude. Aber das Programm nur einmal starten...

Viele Grüße
Michael
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: Windows Ribbons API

Beitrag von AUGE_OHR »

mikehoffmann hat geschrieben:@Jimmy: Lies mal die Fehlermeldung genau.
Danke, ich kann lesen
mikehoffmann hat geschrieben:Der Grund ist recht simpel: Das Programm läuft schon einmal.
Nö !
Ordner angelegt und ZIP ausgepackt und 1 x gestartet. kann die BUG jederzeit produzieren.

aber ich kann verstehen wieso du darauf kommst nachdem ich es mal unter virtualBox gestartet habe mit der VHD Datei ... also wohl der PC mit Windows 7, 32bit

---

was Rudolf und ich zu sagen versuchen : du bist auf einen viel höheren Level als ein durchschnittlicher Xbase++ User.

ob sich Roger mit dem Stuff beschäftigt ... auch mein "native" Stuff hat er noch liegen ... irgendwann.

also habe ich angefangen einen Express++ "Wrapper" z.b. für mein "native" Progressbar zu schreiben.
die Syntax ist nun genau "so" wie eine Express++ User es "erwartet" wie er es "gewohnt" ist.

bei "pure" Xbase++ verwende ich lediglich ein #xtranslate XbPart => DXE_Control da ich die Syntax von Alaska übernommen habe.

bei einem "neuen" Control, was Xbase++ nicht hat, ist es im Prinzip "schwieriger" ... man muss sich was "passendes" ausdenken.
wenn es z.b. eine activeX Ausführung gibt versuche ich die Property,Method,Event "Namen" zu übernehmen (Wiedererkennen)


wenn ich ein Ribbon schreiben wollte dann würde es 2 CLASS geben

Code: Alles auswählen

   DXE_RibbonBar()
   DXE_RibbonMenu()
damit stehen auch die iVAR und (Minimum) Methoden fest ( XbpMenuBar()/ XbpMenu() )
alles was sonst noch "interne" passiert interessiert kaum einen User und was neues "lernen" ...

wenn man aber ein XbpMenuBar()/ XbpMenu() gegen ein DXE_RibbonBar() / DXE_RibbonMenu() "austauschen" könnte ...
"so" könnte ein Xbase++ User es IMHO sofort benutzen ohne seinen Code umzuschreiben oder neu zu "lernen".

klar hat ein Ribbon noch mehr zu bieten als ein normales Menü aber da muss der User eben doch erst noch "lernen".

p.s. üblicherweise mögen die User keine LIB ohne Source ... was wenn der Autor verstirbt.
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

Hallo Jimmy,

--- snip ---
Ordner angelegt und ZIP ausgepackt und 1 x gestartet. kann die BUG jederzeit produzieren.
--- snap ---

Dann hat sich bei Dir ein anderes nettes Programm mit dem Hotkey Ctrl-Alt-B registriert. Ich hab's rausgenommen.

Außerdem habe ich ein neues Zip online gestellt, das nun auch die MRU (Liste der zuletzt verwendeten files) vorbelegt. Hat mich 2 Tage meines Lebens gekostet und sind am Ende 10 Zeilen Code. Der Teufel hat die SafeArrays und mich fehlbar gemacht, oder ist es vielleicht doch das Alter? Das neue ribbon.prg besteht aus der FUNCTION Main, der RibbonWindow-Klasse und einer Klasse, die aus UICommandHandler erbt. Das sind 3 Dinge. Bitte sag nicht wieder, das wäre kompliziert, sondern sag konkret, was Du nicht verstehst.

--- snip ---
was Rudolf und ich zu sagen versuchen : du bist auf einen viel höheren Level als ein durchschnittlicher Xbase++ User.
--- snap ---

Das würde ich mir nicht unterstellen. Auch Ihr habt Anwendungen am Markt, mit denen Ihr Geld verdient. Mich hat das XBase++ GUI genervt und deswegen habe ich meine eigenes GUI geschrieben, das direkt auf dem API basiert. Natürlich kenne ich Windows nun fast wie meine Westentasche und lebe in einer anderen Welt als Ihr. Ich habe es nie bereut, vor allem, wenn ich sehe, wie Ihr unter wild gewordenen aktiven Nixen und anderem Zeug leidet, das im Xbase++ GUI nicht funktioniert.

--- snip ---
ob sich Roger mit dem Stuff beschäftigt ... auch mein "native" Stuff hat er noch liegen ... irgendwann.
also habe ich angefangen einen Express++ "Wrapper" z.b. für mein "native" Progressbar zu schreiben.
die Syntax ist nun genau "so" wie eine Express++ User es "erwartet" wie er es "gewohnt" ist.
--- snap ---

Mach sowas nur, wenn Du genau weißt, wie Windows und Xbase++ mit den Messages umspringen. Siehe Goethes "Der Zauberlehrling". Das ist massiv komplizierter als das GetMessage/DispatchMessage, was man immer sieht. Been there, got the T-Shirt.

---snip ---
bei "pure" Xbase++ verwende ich lediglich ein #xtranslate XbPart => DXE_Control da ich die Syntax von Alaska übernommen habe.

bei einem "neuen" Control, was Xbase++ nicht hat, ist es im Prinzip "schwieriger" ... man muss sich was "passendes" ausdenken.
wenn es z.b. eine activeX Ausführung gibt versuche ich die Property,Method,Event "Namen" zu übernehmen (Wiedererkennen)

wenn ich ein Ribbon schreiben wollte dann würde es 2 CLASS geben

Code: Alles auswählen
DXE_RibbonBar()
DXE_RibbonMenu()

damit stehen auch die iVAR und (Minimum) Methoden fest ( XbpMenuBar()/ XbpMenu() )
alles was sonst noch "interne" passiert interessiert kaum einen User und was neues "lernen" ...

wenn man aber ein XbpMenuBar()/ XbpMenu() gegen ein DXE_RibbonBar() / DXE_RibbonMenu() "austauschen" könnte ...
"so" könnte ein Xbase++ User es IMHO sofort benutzen ohne seinen Code umzuschreiben oder neu zu "lernen".

--- snap ---

Zu viele Gänsefüßchen. Ich probier's trotzdem. Die Ribbons sollen die Menus ersetzen, so wollen es die Meikrosoftis. Genau wie die guten alten Menus bieten die Ribbons Command IDs, die ihr im Xbase++ nicht kennt, weil ihr Eure Codebock Slots und überladbaren Methoden habt. Bei den Ribbons ist es so, dass jedes Command im Ribbon einen Handler (COM-Objekt) in der Anwendung hat, mit dem es spricht. Das sind meine UICommandHandler. Wenn im Ribbon was gewählt wird, dann wird die Method "Execute" im zugeordneten Handler aufgerufen. Aus dem UICommandHandler kann man erben und die Methode Execute überladen oder eine abgeleitete Klasse basteln, die eine IVar für einen Codeblock hat, der dann ausgeführt wird. Nix anderes als bei Euch. Allerdings: Das GUI und auch das Ribbon ticken im EVM-Thread und man muss die Messages noch rübermakeln in den Applikations-Thread. Fummelkram, aber machbar. Ich habe da ganz andere Sorgen.

Schreib doch mal eine nette kleine Xbase Anwendung mit Menu. Bitte nur ein prg-file. Ich versuch' dann, sie auf Ribbon umzustellen.

--- snip ---
klar hat ein Ribbon noch mehr zu bieten als ein normales Menü aber da muss der User eben doch erst noch "lernen".
--- snap ---

Lernen ist etwas passives, wird aber durch einen aktiven Prozess ausgelöst. Hast Du schon die Ribbon-Doku auf der Microsoft-Website gelesen, zumindest die Basics? Das ist wie mit den Übungen, die mir der Physiotherapeut gestern aufgetragen hat. Die sind gut und schön, wirken bei mir aber nur, wenn ich sie mache. "100 mal am Tag" hat er gesagt. Schöner Mist.

--- snip ---
p.s. üblicherweise mögen die User keine LIB ohne Source ... was wenn der Autor verstirbt.
--- snap ---

Dann macht mein Firmenmitinhaber mit meinem Entwicklungskollegen weiter und die beiden freuen sich, dass die Payroll kürzer geworden ist. COMPAR gibt es nun über 25 Jahre und alle Sourcen sind in unserem Versionskontrollsystem vorhanden. Was ist mit Alaska und den Herstellern aller anderen Tools die Ihr verwendet?

Frohe Ostern
Michael
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: Windows Ribbons API

Beitrag von Rudolf »

Hallo Michael,
mich würde interessieren wieso Du noch mit Xbase++ arbeitest ? Bei Deinen Kenntnissen könntest Du mit jeder anderen Sprache auch weiterkommen. Und Jimmy hat schon recht, ich verwende Xbase++ nur wegen eXpress++, vielen Topdown Usern wirds ähnlich gehen. Reines Xbase++ hat keine Vorteile für gegenüber anderen Sprachen. Also sind wahrscheinlich Wrapper für eXpress++ und Topdown für viele wichtig. Mal sehen ob Roger in die Gänge kommt, vielleicht sollten ein paar User ein wenig nachhelfen.
Grüße
Rudolf
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Windows Ribbons API

Beitrag von HaPe »

Hallo Michael !

Zuerst ziehe ich meinen virtuellen Hut vor dem was du machst :blob8:

Eine Frage habe ich zur Windows Ribbons API

Bild

Sehen Applikationen die mit der Windows Ribbons API "ausgestattet" sind unter Windows10 genauso aus wie Office2016?
Also gaaanz flach und ohne Farbverlauf?
Oder gibt es da Unterschiede?
--
Hans-Peter
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

@ Rudolf:
ich arbeite nicht nur mit Xbase++. Mein letztes Projekt mit Was zum Anfassen, bei dem ich eine Steuerung für ein Beschriftungsgerät gebaut habe, so richtig mit Elektronikdesign, Löten und Fräsen des Gehäuses, verlangte nach C++. Also habe ich halt in C++ programmiert. Aber die Grundlagen der objektorientierten Programmierung und die Übung darin, zielsicher schnell eine schönes Objektmodell zu bauen, das nachher funktioniert, habe ich mit Xbase++ erlernt.
Das Gerät steht jetzt in Paris und bekommt seine Daten von einer Anwendung, die mein Kollege in Xbase++ geschrieben hat und die via VNC voll in die Maschinensteuerung integriert ist.
Und sich sage gleich noch was dazu. So schön, wie in Xbase++, kann man in KEINER anderen (mir bekannten) Sprache objektorientiert programmieren. Stichwort Mehrfachvererbung. Was nicht heißt, dass Xbase++ perfekt wäre, aber wenn man sauber programmiert, ist es der reinste Traum. Und der Preprozessor ist ein Gedicht. Xbase++ hat aus Sprachsicht alles, was ein Dottnettchen oder Java zu bieten hat. Es wird aber höchste Zeit für 64-Bit-Unterstützung und ein erweiterbares Typensystem. Auch würde ich mich sehr über nativen Unicode-Support freuen. Meine Cockpit-Librarys verwenden übrigens die Unicode-Funktionen des Betriebssystem und ich habe einen Datentyp (=Klasse) namens WideCharacter für Unicode-Strings, mit dem ich echte Unicode-Programme schrieben kann. Aber lockere Statements wie IF a >= "ä" funktionieren dann leider nicht mehr so einfach.

@ HaPe:
Danke für die Blümchen. Das Ribbon Framework im Betriebssystem, das ich wrappe, ist wohl eine Auskopplung aus Office 2007 oder so. Daneben gibt es noch jede Menge andere Anbieter (inklusive Microsoft), die ihre eigenen Ribbon-Systeme anbieten, die die optische Haute Côture darstellen. Aber da reden wir wieder über hyperaktive Nixen oder MFC-Klassen oder..., die ein Runtimesystem voraussetzen, das wir nicht haben. Wenn Du wissen willst, wie der API-Ribbon auf Windows 10 aussieht,. musst Du mein Progrämmchen da anwerfen. Ich weiss es nicht und habe gerade kein W10 zur Hand.

Viele Grüße
Michael
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: Windows Ribbons API

Beitrag von AUGE_OHR »

hi Michael,
mikehoffmann hat geschrieben: Dann hat sich bei Dir ein anderes nettes Programm mit dem Hotkey Ctrl-Alt-B registriert. Ich hab's rausgenommen.
ich gehöre zu den Leuten die viele Icons auf dem Desktop liegen haben die man per Hotkey aktivieren kann.
Shortcut_HotKey.jpg
Shortcut_HotKey.jpg (62.58 KiB) 9867 mal betrachtet
Frage : gibt es eine "umgekehrten" Function womit man "auslesen" kann welche Shortcuts registriert sind und zu welchem Link die gehören ?
mikehoffmann hat geschrieben:Außerdem habe ich ein neues Zip online gestellt, das nun auch die MRU (Liste der zuletzt verwendeten files) vorbelegt.
Danke
mikehoffmann hat geschrieben:Das neue ribbon.prg besteht aus der FUNCTION Main, der RibbonWindow-Klasse und einer Klasse, die aus UICommandHandler erbt. Das sind 3 Dinge. Bitte sag nicht wieder, das wäre kompliziert, sondern sag konkret, was Du nicht verstehst.
ich denke schon das ich verstehe was du meinst da ich mich mit dem Codejock Commandbars beschäftigt habe wie auch einige andere User hier im Forum.

deine Lösung als Ersatz für das ActiveX von Codejock wäre natürlich potenziell für die Leute interessant die schon Ribbons haben.
das Roger ja auch Xcodejock auf die Syntax abgestimmt hat könnte jeder Express++ User die dann ebenfalls einsetzten.
mikehoffmann hat geschrieben: Das würde ich mir nicht unterstellen. Auch Ihr habt Anwendungen am Markt, mit denen Ihr Geld verdient.
Mich hat das XBase++ GUI genervt und deswegen habe ich meine eigenes GUI geschrieben, das direkt auf dem API basiert. Natürlich kenne ich Windows nun fast wie meine Westentasche und lebe in einer anderen Welt als Ihr. Ich habe es nie bereut, vor allem, wenn ich sehe, wie Ihr unter wild gewordenen aktiven Nixen und anderem Zeug leidet, das im Xbase++ GUI nicht funktioniert.
das schreiben von eigenen XbParts erfordert IMHO einen Level das einen normalen Xbase++ User nicht hat ... und auch gar nicht haben will (lernen)
ein User hätte doch am liebsten ein "ich_kann_alles" Modul was er "ohne viel Arbeit" in seine App einbauen kann.
mikehoffmann hat geschrieben: Mach sowas nur, wenn Du genau weißt, wie Windows und Xbase++ mit den Messages umspringen. Siehe Goethes "Der Zauberlehrling".
Das ist massiv komplizierter als das GetMessage/DispatchMessage, was man immer sieht. Been there, got the T-Shirt.
jeder Meister hat auch als Lehrling angefangen. ich gehe ja den ot4xb Weg und Pablo sagt oft das ich "Spagetti und Maccaroni" vermische ... aber wenn es "satt" macht ;-)

und da wären wir wieder beim Level / Anspruch : welche Software ist 100% Fehlerfrei !?
mikehoffmann hat geschrieben: Zu viele Gänsefüßchen. Ich probier's trotzdem. Die Ribbons sollen die Menus ersetzen, so wollen es die Meikrosoftis.
Genau wie die guten alten Menus bieten die Ribbons Command IDs, die ihr im Xbase++ nicht kennt, weil ihr Eure Codebock Slots und überladbaren Methoden habt.
Bei den Ribbons ist es so, dass jedes Command im Ribbon einen Handler (COM-Objekt) in der Anwendung hat, mit dem es spricht. Das sind meine UICommandHandler.
Wenn im Ribbon was gewählt wird, dann wird die Method "Execute" im zugeordneten Handler aufgerufen.
Aus dem UICommandHandler kann man erben und die Methode Execute überladen oder eine abgeleitete Klasse basteln, die eine IVar für einen Codeblock hat, der dann ausgeführt wird. Nix anderes als bei Euch. Allerdings: Das GUI und auch das Ribbon ticken im EVM-Thread und man muss die Messages noch rübermakeln in den Applikations-Thread.
Fummelkram, aber machbar. Ich habe da ganz andere Sorgen.

Schreib doch mal eine nette kleine Xbase Anwendung mit Menu.
Bitte nur ein prg-file. Ich versuch' dann, sie auf Ribbon umzustellen.
ich habe mit Roger 2010 an den Codejock ActiveX gearbeitet und die Geschichte mit "Execute" miterlebt.
das Alaska Sample zu XbpMenuBar() "deutet an" wie man mit ID arbeiten kann.

ich müsste auch irgendwo noch den Demo Code rum liegen haben. bei Express++ hat Roger XCodeJock.ch und die Demos beigelegt.
überhaupt habe ich, durch meine eigenen native COntrols, den Einsatz von den ActiveX reduziert nur noch 1 Modul in Betrieb : Codejock Skinframework***.

*** eigenes Theme z.b. iTunes Style für die Xbase++ App
mikehoffmann hat geschrieben: Lernen ist etwas passives, wird aber durch einen aktiven Prozess ausgelöst.
Hast Du schon die Ribbon-Doku auf der Microsoft-Website gelesen, zumindest die Basics?
na ja, MSDN ist schon die Quelle aber die Source Code Beispiele sind ja nicht Xbase ...
ein C Programmierer hätte sicherlich damit keine Probleme mit den Beispielen aber ob er einen Wrapper für Xbase++ schreiben könnte ?

"learing by doing" hat aber auch was mit "try and error" zu tun was dann wieder Zeit kostet. 3-PP Tools sollen ja helfen Zeit zu sparen.
wer schon Codejock Commandbars (Ribbon) einsetzt würde dann natürlich am liebsten die gleiche Syntax haben wollen, deshalb mein Hinweis.
mikehoffmann hat geschrieben: Dann macht mein Firmenmitinhaber mit meinem Entwicklungskollegen weiter und die beiden freuen sich, dass die Payroll kürzer geworden ist. COMPAR gibt es nun über 25 Jahre und alle Sourcen sind in unserem Versionskontrollsystem vorhanden. Was ist mit Alaska und den Herstellern aller anderen Tools die Ihr verwendet?
ich wünsche dir gute Gesundheit und ein langes Leben und freue mich über deine Beiträge hier im Forum.
gruss by OHR
Jimmy
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

Hallo Jimmy,

--- snip ---
Frage : gibt es eine "umgekehrten" Function womit man "auslesen" kann welche Shortcuts registriert sind und zu welchem Link die gehören ?
--- snap ---

Antwort zum Auslesen: Ja, gibt es. Im IShellLinkInterface gibt es die Methoden SetHotKey und GetHotKey. Auflistung der registrierten: Keine Ahnung.

--- snip ---
deine Lösung als Ersatz für das ActiveX von Codejock wäre natürlich potenziell für die Leute interessant die schon Ribbons haben.
das Roger ja auch Xcodejock auf die Syntax abgestimmt hat könnte jeder Express++ User die dann ebenfalls einsetzten.
--- snap ---

Verwendet denn jemand wirklich die CodeJock Ribbons?

---snip ---
das schreiben von eigenen XbParts erfordert IMHO einen Level das einen normalen Xbase++ User nicht hat ... und auch gar nicht haben will (lernen)
ein User hätte doch am liebsten ein "ich_kann_alles" Modul was er "ohne viel Arbeit" in seine App einbauen kann.
--- snap ---

Meine Sicht: Wieso eigene Xbase-Parts schreiben? Die Rechner haben inzwischen soviel Dampf und das O/S kann mal für ein paar Sekunden ohne Anwendungsrückmeldung leben, so dass die Xbase-Parts nicht mehr nötig sind. Das ständige Message-Schicken zwischen verschiedenen Threads bringt nur Ärger. Und man schafft es nicht mal, verschiedene GUI-Threads ticken zu lassen. Was soll das? Aber: Das ist nur meine Sicht.

--- snip ---
jeder Meister hat auch als Lehrling angefangen. ich gehe ja den ot4xb Weg und Pablo sagt oft das ich "Spagetti und Maccaroni" vermische ... aber wenn es "satt" macht
und da wären wir wieder beim Level / Anspruch : welche Software ist 100% Fehlerfrei !?
--- snap ---

Aua. Die Zeit, die Du damit verbracht hast, Dir Deinen Kopf an den verschiedenen Windows-Wänden abzuflachen und nachher immer noch im Dunklen zu tappen, hättest Du besser anders verwendet und auf die Lehren des großen Meisters Petzold gehört. Die Erkenntnis, dass Software nicht fehlerfrei sein kann, darf nicht dazu führen, dass man diese Fehler während der Programmierung zulässt.

--- snip ---
ich habe mit Roger 2010 an den Codejock ActiveX gearbeitet und die Geschichte mit "Execute" miterlebt.
--- snap ---

Was ist denn da Schreckliches passiert?

--- snip----
das Alaska Sample zu XbpMenuBar() "deutet an" wie man mit ID arbeiten kann.
--- snap ---

„Deutet an?“ Eher nicht, auch wenn ich das Beispiel nicht kenne. Die Xbase Menus unterstützen keine IDs.

--- snip ---
ich müsste auch irgendwo noch den Demo Code rum liegen haben. bei Express++ hat Roger XCodeJock.ch und die Demos beigelegt.
überhaupt habe ich, durch meine eigenen native COntrols, den Einsatz von den ActiveX reduziert nur noch 1 Modul in Betrieb : Codejock Skinframework***.

*** eigenes Theme z.b. iTunes Style für die Xbase++ App
--- snap---

OK, dann eben keine Anwendung für eine Umstellung auf Ribbons. Du tust Dir das Active-X Zeug echt an, damit Deine Anwendungen anders aussehen? Und wenn Du mit den Native Controls asynchron arbeitest, dann spielst Du mit dem Feuer. Damit stellst Du sicher, dass Deine Software nicht 100% fehlerfrei ist.

--- snip ---
na ja, MSDN ist schon die Quelle aber die Source Code Beispiele sind ja nicht Xbase ...
ein C Programmierer hätte sicherlich damit keine Probleme mit den Beispielen aber ob er einen Wrapper für Xbase++ schreiben könnte ?
--- snap ---

Um das Zeug zu verwenden, musst Du verstehen, was da steht. Der Source-Code ist nur ein kleiner Teil davon, wenn überhaupt.

--- snip ---
"learing by doing" hat aber auch was mit "try and error" zu tun was dann wieder Zeit kostet. 3-PP Tools sollen ja helfen Zeit zu sparen.
--- snap ---

LBD und TAE sind dauerhaft zu vermeiden. „Verstehen und Anwenden“ ist das richtige Motto.

--- snip ---
wer schon Codejock Commandbars (Ribbon) einsetzt würde dann natürlich am liebsten die gleiche Syntax haben wollen, deshalb mein Hinweis.
--- snap ---

Roger that. Danke!

Viele Grüße
Michael
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

Hallo,

zwei Wochen habe ich mich jetzt wieder mit den Ribbons und der gräuslichen Doku rumgeschlagen. Jetzt funktioniert das Ribbon aber super. Ich werde nun beginnen, das Ribbon produktiv zu verwenden.
Das Testprogramm-Zip habe ich auf der Cockpit-Webiste up-ge-dated.Ich habe auch den Source auch "farbcodiert" als pdf miteingepackt, so kann man ihn viel besser lesen.

Hier nochmal die Links:

http://www.xcockpit.com/download.html

Da findet Ihr die zip-Datei unter "Temporary Downloads / Windows Ribbon Sample Application". Achtung: Doppelklicken erforderlich!

Oder nehmt diesen direkten Link: http://www.xcockpit.com/files/RibZip.zip

Viele Grüße
Michael
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Windows Ribbons API

Beitrag von brandelh »

Welche Xbase++ DLL (version) braucht die EXE ?
Benötigt die Ribbons Bar die cockpit Umgebung ?
Gruß
Hubert
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

1.90.355 und ja. Die Cockpit dlls sind in der zip-Datei dabei.
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: Windows Ribbons API

Beitrag von Tom »

Mal so am Rande. Gab's da nicht irgendeine urheberrechtliche Sache mit der Ribbons-API? :?
Herzlich,
Tom
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: Windows Ribbons API

Beitrag von mikehoffmann »

Du hast Dich auch mit dem Stichwort "Ribbon" durch die Welt gegoogelt, oder? Ich kann mich erinnern, auf meinen Weltumrundungen ein Posting gesehen zu haben, in dem es um einen Ribbon-Anbieter ging, den Microsoft verklagt hatte. Der hatte sich gewagt, die Mircrosoft-Resource-Daten für seine Ribbons zu verwenden, die mit Visual Studio erzeugt werden können. Visual Studio enthält einen kompletten Editor für die MFC-Ribbons, der hier im Forum auch schon mal auftauchte. Wenn die MFC-Implementierung der Ribbons genauso gräuslich ist, wie die der O/S-Ribbons, hat der Drittanbeiter eine prima Markposition gehabt. Microsoft liefert den Editor, er liefert die Software, die ihn nutzt. Ob es nun Fake-News ist oder nicht, und ob ich mich irre, kann ich nicht sagen. Ganz abwegig ist es aber nicht.
Viele Grüße
Michael
Antworten