Hmm, wenn noch etwas mehr reinbauen möchtest nutzt System.Globalization.NumberFormatInfo .String("C", oNumberFormatInfo);

Dann bekommst auch Euro rein usw. hat den Vorteil das wenn mal Sprache ändern musst das ganze nur noch an einer Stelle zu ändern brauchst. 😃

Auch das von Azrael Masters mit verwenden, dann spaarst dir die Schleife.

Aufpassen unter VS2005 wegen: „\v“ Tabulator, vertikal \v Tabulator.
Hatte da letztens auch nicht schlecht gestaunt..

Hm, was noch fehlt ist eine Nomenklaturliste.
Sprich, wie möchtest deine Lokalen- / Globalen- / Umgebungs- / Parameter usw. - Variablen bennen. Wie kennzeichnest du deine Klasse, deine Interfaces, COMObjecte usw. Oder wie möchtest du Dokumentieren „///“ empfiehlt sich zum Beispiel dafür um ein XMLDoc zu erstellen was man mit diversen Tools wieder in eine Hilfedatei umgewandelt werden kann.
Oder wie trennst du deinen Namespace, machst du für Interface, Klassen oder Core-Klassen oder für Formulare usw. jeweils eigene Namespace Bereiche.

Kenne leider nur keine wirklich eindeutigen Nomenklaturlisten, eigentlich werdee diese in der jeweiligen Firma vorgegeben 😠

Such dir einfach wenn das nur privat für dich zu Hause machst etwas aus. Wenn bereist C++ intus hast kennst dort ja bestimmt ein paar Normenklaturen, finde es auch persönlich nicht mal so schlecht davon die Nomenklaturen zu nutzen. Bin kein Freund von CamelCase usw. (bin zu doof dafür das gescheit dann lesen zu können).

Also empfehle dir wenn das vorrhast auf keinen Fall nur die Objektorientierte Programmierung anzugehen. Der Quellcode explodiert und wird unübersichtlich.

Schau dir mal Design Pattern Programming an. Es kostet zu beginn Zeit und war zumindest für mich sehr verwirrend. Aber es spart später unglaublich viel Zeit und erleichtert das Kommunizieren ungemein von Controls oder Formularen. Ein Kollege zeigte mir zum Glück wie so etwas geht.

Ich habe leider kein kleines Beispielprojekt dazu, aber in zwei Wochen gäbe es die Möglichkeit mal eines reinzustellen. In der Suche wird man sicher über ‚Design Pattern’ etwas finden.

Der Grobe Ansatz davon: Du brauchst ein Interface für deine Commands die du den controls mitgeben möchtest. Das Control selbst braucht ein Objekt das ein solches Interface kapseln oder sich merken kann (daher leider eigene Controls oder solche Sachen wie den Tag vom MenuStripItem nutzen). Jede deiner Klassen die eine Action ausführen muss braucht die Ableitung von diesen Interface. Es empfiehlt sich aber eine abstrakten Klasse zu erstellen die das Inetrface beinhaltet. Nun kann man wie folgt vorgehen, jede der Klassen welche Actions ausführen soll beinhaltet als Ableitung die abstrakte Klasse. Das heißt dass alle vom selben Typ sind. Mit einen eigenen Delegate kannst dann das Command transportieren und sich selbst über eine methode die eben im Interface von Command definiert ist die Kalsse sich selbst ausführen lassen. Es geht noch schöner wenn man die Methode dann überladet und sie als DelegateTarget für zum Beispiel ein Klick Event nimmt.

Das Lustige dran, deine Formulare bekommen die Informationen mit Sender aber müssen sie nicht mal verarbeiten 🙂

/ps
Klasse ist es dann noch einen Eventhandler einzubauen in der Hauptaplication in dem man dann via Consolenausgabe dann die einzelnen Commands ausgibt. Sieht klasse aus da man immer weis, was wurde grade gemacht und das bei jeder Action.

Original von talla
Außer dem Framework wars die gleiche Maschine? Ich finds nur seltsam weil SetParent ja ne WinApi Funktion ist und nichts mit dem Framework zu tun hat. Dann könnts ja nur an den Handles liegen die anders gehandhabt werden in den verschiedenen FW Versionen.

Wird es leider auch aber es gibt trotzdem einen weg, denke am Montag weis ich da mehr. Ein Kollege hat das schon mal denke ich gelöst bekommen.

Du könntest von der Klasse ToolStripButton / ToolStripItem ableiten und bei der OnPaint Methode etwas anderes Zeichnen und neue Verhaltensweisen hinzufügen / verändern.

Im schlimmsten Fall machst ein UserControl und fügst es über Controls.Add oder UserControl.Parent = ToolStrip oder durch SetParent hinzu.

Oh habe da ein UserControl gemacht mit TableLayout da sind die Resize Probleme nicht mehr da. Aber dein weg würde mich mehr reizen 🙂

Hatte leider nur nicht genug Zeit 🙁

Wie versprochen das Control, hatte mich letztens etwas verlesen.

Kannst bei diesen Control noch etwas rumspielen was das Design betrifft

Hm, du könntest einfach ein UserControl erstellen.

Tip:

Leite von der Klasse Buttons ab, erstelle das Propertie PaneLevel vom Typ int,
Leite von Klasse Panel ab, erstelle das Propertie PaneLevel vom Typ int.

Erstelle ein UserControl und zeichne ein TableLayoutPanel, mach dir dann eine Collection Liste (super wäre in einer eigenen Klasse von CollectionBase). Schreib eien Add und eine Remove Methode in der du dann Colums erstellst in die du die Abgeleitete Klasse von buttons hinzufügst und in der unteren Row jeweils von der abgeleiteten Klasse Panel. Verseh beim Constructor der jeweiligen Ableitungen sie mit dem Atribut PaneLevel = Column.Count -1;

Initialisiere den Eventhandler Button Klick bei dem dann vom Sender her das PaneLevel rausholst und immer das Panel anzeigst mit dem selben PaneLevel.

/ps

Wenn sich bis nächste Woche Freitag noch niemand gemeldet hat, kann ich dir das Control erstellen.

Also hier die Lösung, geht auch ohne Subclassing sehr einfach.

   using System.Runtime.InteropServices;

        [DllImport("user32.dll")]
        private static extern IntPtr FindWindowEx(IntPtr hwndParent, IntPtr hwndChildAfter, string lpszClass, string lpszWindow);

        [DllImport("user32.dll")]
        private static extern bool GetWindowRect(IntPtr hWnd, out Rectangle lpRect);

        [DllImport("user32.dll")]
        static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X,
           int Y, int cx, int cy, uint uFlags);

        [Flags]
        public enum SWP
        {
            SWP_NOSIZE = 0x0001,
            SWP_NOMOVE = 0x0002,
            SWP_NOZORDER = 0x0004,
            SWP_NOREDRAW = 0x0008,
            SWP_NOACTIVATE = 0x0010,
            SWP_FRAMECHANGED = 0x0020,
            SWP_SHOWWINDOW = 0x0040,
            SWP_HIDEWINDOW = 0x0080,
            SWP_NOCOPYBITS = 0x0100,
            SWP_NOOWNERZORDER = 0x0200,
            SWP_NOSENDCHANGING = 0x0400,
            SWP_DEFERERASE = 0x2000,
            SWP_ASYNCWINDOWPOS = 0x4000
        }

        public static Rectangle m_oRec;

        public static bool HideTaskbar()
        {
            IntPtr Task = FindWindowEx(IntPtr.Zero, IntPtr.Zero, "Shell_TrayWnd", "");

            // falls der handle der taskbar nicht gefunden wurde
            if (Task == IntPtr.Zero)
                return false;

            // dieses rectangle einfach irgendwo merken damit die höhe später wiederhergestellt werden kann
            GetWindowRect(Task, out m_oRec);

            // setzt die Windows possition auf null und lässt die Taskbar verschwinden
            return SetWindowPos(Task, IntPtr.Zero, 0, 0, 0, 0, (uint)SWP.SWP_HIDEWINDOW);
        }

        public static bool ShowTaskbar(Rectangle _oRec)
        {
            // suche taskbar handle
            IntPtr Task = FindWindowEx(IntPtr.Zero, IntPtr.Zero, "Shell_TrayWnd", "");

            // falls der handle der taskbar nicht gefunden wurde
            if (Task == IntPtr.Zero)
                return false;

            // zeigt die taskbar wieder an
            return SetWindowPos(Task, IntPtr.Zero, _oRec.X, _oRec.Y, _oRec.Height, _oRec.Width, (uint)SWP.SWP_SHOWWINDOW;
        }

Brauchst das natürlich nicht static setzen, auch einfach dann beim TaskHide die ClientSize mit Hilfe von PointToScreen über die gesamte Bildschirm-Fläche legen..
Dafür war ich aber etwas zu faul🙂

Hm, schade.

Ansonsten über Spy++ mal die Taskbar auswählen, schauen wie sich das Ding verhält. Wüde es über Window Subclassing dann versuchen.

Denk nur dran das WINSDK gut anzusehen, wirst statt einen intPtr dafür einen Delegate für den Callback brauchen.

public delegate void HookProcessedHandler(int code, 
                                      UIntPtr wparam, IntPtr lparam)

Aber vielleicht hat jemand noch eine etwas einfacherere / schönerere Lösung für das Problem.

Original von dgroeser
genau die will ich ausblenden bzw. das Fenster einfach davor damit mehr platz auf der form ist?

Kopier mal den Code in deine Form.
Klicke dann mal auf den Maximieren Button deines Fensters.

Die Taskleiste wird überblendet und ein Formular ist wie im Vollbildmodus.
Ist einfach ein kleiner Trick. Nur die Controls der Titlebar verschwinden.

/PS

Habe es in VS2005 erstellt und Probiert, evtl. liegt es ja daran das es nicht geht?

Hallo hatte das selbe Problem, allerdings wollte ich den Effekt nur wenn das MDI Container Fenster maximiert wird.

Aber aufgepasst, ich habe die Control Boxen selbst gemalt, auf einer normalen Form sind die nicht mehr sichtbar.

public enum WindowMessages
    {

        WM_SYSCOMMAND = 0x0112
    }

public enum SystemCommands
    {
      
        SC_MAXIMIZE = 0xF030
    }

protected override void WndProc(ref Message m)
        {
            if (m.Msg == (int) WindowMessages.WM_SYSCOMMAND)
            {

                if (m.WParam.ToInt32() == (int)SystemCommands.SC_MAXIMIZE)
                    this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;
                else
                    this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.Sizable;
            }

            base.WndProc(ref m);
        }

Hallo, habe das auch schon Probiert, der gewünschte Effekt tritt ein.
Problem ist nur dass der maximieren Status nicht mehr gesendet wird.

Also das Fenster weis dann nicht mehr das es sich grade im Maximieren Zustand befindet.
Somit befindet sich das Fenster immer im FormWindowState.Normal Zustand. Die Windows Message WM_Restore geht dann leider nicht mehr.

Hallo, arbeite zurzeit an einem GUI für eine BDE Maske.
Hierfür verwende ich einen MdiContainer und MdiChilds.

Ich habe schon einige Dinge ausprobiert komme aber an einer Stelle leider nicht weiter, beim maximieren des MdiChild dockt sich das MdiChilds im MenuStrip des MdiContainer (MdiParent) ein.

Habe bereits versucht in der WndProc die Windows Message mit WM_SYSCOMMAND und den WParam mit SC_MAXIMIZE abzufangen, was auch ohne Probleme klappt. Gebe ich nun einfach einen return mit, wird das fenster nunmehr nicht maximiert. Aber die Nachricht für den WindowState (FormWindowState.Maximized) geht dann natürlich auch verloren.

Habe auch versucht mit der Windows API funktion LockWindowUpdate(this.Handle) das MDI Fenster zu sperren, leider erscheinen dennoch das Icon wie die Maximieren-, Minimieren- und Close Buttons im MenuStrip.

Habe leider keine Idee welche WindowsMessage ich hier abgreifen muss, oder welches Tool es evtl erleichtern würde die entsprechende Windows Message zu finden. Oder welche Windows API funktion es erlaubt das WindowState zu setzen.

Hat jemand vielleicht einen Tipp für mich?

/ps
Im Anhang befindet sich Screenshoot des Testprojekts bzw. der Effekte.