Announcement

Collapse
No announcement yet.

TMainMenu weiterentwickeln...

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • TMainMenu weiterentwickeln...

    Hi!
    Ich möchte gerne das TMainMenu etwas weiterentwickeln. Ich möchte, dass man Background/Selected-Color und auch Schrift bzw. Schriftfarbe einstellen kann. Ich habe keine Ahnung wie ich die Komponente angehen soll, also wäre ich über jegliche Tips bzgl. der Komponente dankbar!

    Gruß Yheeky

    PS: Am wichtigsten sind erst einmal die Funktionen, wie man den Background/Selected-Color verändern kann, aber wenn jemand auch weiss, wie man den Rest ändern kann, kann er das auch ruhig schreiben

  • #2
    TMainMenus beinhalten auch die horizontale "Leiste" in einem fenster. Diese wird NICHT von einem menuhandle gezeichnet sondern von dem Non-Client-Bereich des fensters selber. D.h. um ein TMainMenu vollständig zu verändern, und das wirst Du müssen um die Hintergrundfabe abzuändern, muss auch die Fensterfunktion INDEM sich das Tmainmenu befindet abgeändert werden. LEIDER gibt es keinerlei Funktionen um von einem Mainmenu Handle auf das dazugehörige Fensterhandle zu kommen. Nur umgekehrt geht das, also das fensterhandle kann sein menu ermitteln. Das fenster und dessen fensterprocedure=Wndproc muss also umgeschrieben werden.

    Gruß hage

    Comment


    • #3
      Hier also auch, Christian?! )
      Beim Thema Farben sind wir ja gerade, was?

      Hallo Hagen, so wie´s aussieht wird am Ende dieses Topics wohl wieder ein kompletter Code von dir hier zu finden sein?! *hoff* Also, würde mich freuen. )

      Gruß,
      Mathias

      Comment


      • #4
        Nein, diesmal nicht. Um's genauer zu sagen hab ich mir auch schon die zähne dran ausgebissen, für nichts. Die Sache ist komplizierter als man glaubt. Das Windows System kapselt das hauptmenu vollständig, aus gutem Grund nehme ich an. Es ist nämlich beschissen. Alle Frame/Caption/Menu Zeichenroutinen/Maus/Keyaktionen eines fensters unterscheiden sich vollständig vom normalen Windowskram. Alles was gezeichnet wird wird im NC=Non Client bereich gezeichnet. Alleine schon die korrekte Dimensionsberechnungen für die verschiedenen fensterstile ist komplex, da eben nicht korrekt, vollständig und logisch dokumentiert. Jede Aktion, z.B. der Maus im NC-Bereich läuft in vielen Bereichen in durch eine eigene Message-Loop. In dieser Loop ist es durchaus üblich direkt im NC Bereich zu zeichen. Gut zu beobachten ist dies wenn man unter Win95 versucht hat die Caption Bar mit einem Farbverlauf zu versehen. In solchen Fällen ist es durchaus zu bemerken das die farbe UNTER den fensterbuttons und diese Buttons selber beim drüberfahren einfach mal neu gezeichnet wird, aus einer separaten Loop heraus. Das gleiche noch viel extremer geschiet beim fenstermenu. Auch dieses wird durch all diese NC-Loops behandelt. Wird also z.B. das Menu aktiviert wird intern in eine pseudomodale Messageloop verzweigt. In dieser Loop wird dann direkt auf die keys/Mause usw. reagiert. Erst wenn das menu/fenster deaktiviert wird oder eben ein Kommando ausgelösst wurde, erst dann wird dieses menuloop beendet. Diese komplette Menuloop MUSS vollständig neu entwickelt werden, dazu gehört alles wie fenstercontrolling/zeichenroutinen usw.<br>
        Diese starke Kapselung durch M$ ermöglicht aber andersherum mal eben diese internen Routinen schnell auszutauschen (nur durch M$ wohlgemerkt) und "segnet" uns mit dem ständig geänderten design bei jeder neuen windows version. Für M$ ist es also ein leichtes die Verpackung ständig zu ändern, um als kommerzielle Firme oder private person da mithalten zu können muss man schon wesentlich mehr Aufwand treiben. M$ Lösungen ändern also direkt den kern der Sache, unser Versuch muss aber immer von außen herumbasteln und das wird nicht gelingen können, da eben die verschiedene Windowsversionen ja auch noch berücksichtigt werden.<br>

        Gruß hage

        Comment


        • #5
          Du hast recht, Hagen. Siehe das Menü von OfficeXP. Ich kann mir nicht vorstellen, dass Microsoft auch mit einem Hook arbeitet, um das Teil so hinzukriegen. Tja, aber die Jungs haben ja auch den Quellcode.

          Man könnte ja mal nachfragen. ) Was für ein Wunsch, eyh? Die Mail an die Office-Entwickler dürfte wohl unbeantwortet bleiben. Bestenfalls landet sie im Registrationszentrum, wo man meine Absenderdaten auseinandernimmt und speichert.

          Mathias

          Comment


          • #6
            Schau mal unter http://www.shagrouni.com/ vorbei. Dort gibt es eine freie Komponente namens XPMenu, welche das Verhalten von Office XP in Bezug auf Menüs nachbildet. Da der Quellcode dabei ist, kann man ja mal dort nachsehen, wie dort das gelößt wird

            Comment


            • #7
              Jo gut gesagt, XPMenu versucht es nachzubilden. Meine test's zeigten ein sehr unsauberes Verhalten das eben NICHT zum OfficeXP identisch ist. Das eigentliche Menubar-Problem ist wie ich's sagte durch die Nutzung eines TToolbar Ersatzes "gelösst", d.h. NICHT durch eine neue TMainMenu Komponente.

              Gruß Hage

              Comment


              • #8
                @Bernhard: Ich kenne die Komponente. Ich schlug Hagen vor, er soll seinen "Flach-Mach"-Code für den Rand von Menüs an den Entwickler schicken, damit der das einbauen kann. Laut seiner Webseite will er nämlich wissen, wie das geht. Hagen weiß es ... )

                @Hagen: Es ist aber schön zu sehen, dass auch Microsoft nicht perfekt ist ... (äh, im Sinne von Konsenz, meine ich; also nicht zu früh grinsen, Leute :-D). Zumindest unter meiner WinXP-Testversion ist es so, dass die Menüs zwar schön flach und schick aussehen. Bis auf das Favoriten-Menü. Das "erstrahlt" im alten Win2k-Klassik-3D-Rahmen-Look ...

                So, jetzt dürft ihr lachen, denn wir alle wissen ja, wie perfekt Microsoft ist. )

                Mathias

                Comment


                • #9
                  Ich bin mir nicht sicher, meine aber das das neue XP menustyle komplett neu ist. Erstens scheint es COM orientiert zu arbeiten, zweitens ist das komplette Styling per XLM Files konfigurierbar und drittens unterstützen nicht alle MS produkte XP Styling, d.h. diese müssen erst nachgerüstet werden. Meine Vermutung ist das das XP Styling eine Weierentwicklung der Toolbars/Menus vom WinWord ist.

                  Gruß Hage

                  Comment


                  • #10
                    Wenn du die Komponente meinst, Hagen - sie hat nach wie vor die selben Probleme. Die ersten paar Menüeinträge erhalten die neue Höhe, die die Komponente einstellt (dürfte wohl XP-mäßig 24 sein). Der letzte Eintrag ist dadurch ein wenig beschnitten.

                    Wenn du die Microsoft´schen OfficeXP-Menüs meinst: wo kann man das Design von denen ändern?

                    Mathias

                    Comment


                    • #11
                      Bei MS gibts ne Page die das XP Style beschreibt und auch wie die XML Konfigurationen auszusehen haben.

                      Gruß Hage

                      Comment


                      • #12
                        Hi!

                        Sorry, dass ich mich solange hier nicht mehr blicken lassen habe. Ich habe es in der Zwischenzeit leider auch noch nicht hinbekommen :-(. Normalerweise dürfte es doch garnicht so schwer sein die Farben in dem Menü ein bisschen umzustellen, aber wenn du Hagen schon sagst, dass du dir die Zähne dran ausgebissen hast...oje!

                        Gruß Yheek

                        Comment


                        • #13
                          Also nochmal. Um die Farbe des MainMenu's zu ändern, wir reden hier von dem horizontalen Balken mit Einträgen wie "datei" usw. (nur um sicher zugehen), muss die komplette zeichenroutine geändert werden. Für dieses Zeichnen ist aber das Fenster und dessen Standard Non-Client zeichenroutine zuständig. D.h. wenn das menu andersfarbig gezeichnet werden soll muss die komplette NC zeichenroutine neu gecodet werden. Das betrifft den KOMPLETTEN Non-Client bereich mit dem Rahmen, Caption, Menu, System Button und fensterbutton.Für alle diese Operationen benötigst Du aber jetzt eine KORREKTE Dimensionsberechnung mit GetSystemMetrics() die sehr diffuse ist, sehr abhängig vom Typ/Classe des Fenster (MDI Child/MDI Frame/ Popup usw.). Haste das einmal ALLES hinbekommen treten die nächsen probleme auf. Wird z.B. auf die Fensterbuttons/Caption/SystemMenu/Menu oder Frame geklickt gibt es öfters mal den Effekt das die M$ Coder mal eben diese Statusänderung anzeigen indem teilweise neu in den NC-Bereich gezeichnet wird. Beispiel: Du hast Dein menu nun in blau. Der user wählt den ersten Eintrag an. das System geht intern in eine Menu-Message-Loop für den NC bereich. Der user fährt mit der maus den zweiten Menueintrag an. Das System muss nun den ersten Eintrag neuzeichnen da dieser ja eben noch selektiert war. Genau in diesem Moment zeichenet die menu-Message-Loop DIREKT dieses Item neu, OHNE Deine Routine überhaupt zu berücksichtigen, und zwar alles wieder in clBtnFace. Fazit: neben der kompletten zeichenroutine für den kompletten NC Bereich darfst noch ALLE anderen Funtionen wie Mausklicks/Keyboard/Focus/Activation/Minimiren/Maxmimieren selber koden, oder in anderen Worten: es wäre einfacher das grundverhalten der Fenster komplett neu zu coden.

                          gruß hage

                          Comment

                          Working...
                          X