MessageBox i pozycja buttona

Witam

W jaki sposób mogę wpłynąć na położenie buttona "OK" w messagebox?
Domyślnie ustawia mi się maksymalnie z prawej strony i nie wygląda to zbyt estetycznie.

Stwórz własny messagebox

Chwilka z Google:
http://ux.stackexchange.com/questions/8569/submit-buttons-on-the-left-or-the-right

MessageBox to nie żadna magia, tylko zwykła forma, i da się napisać po swojemu.

Bardzo na szybko i nie bardzo poprawnie:

    class MesydżBoks
    {
        public static DialogResult Show(string text, string caption)
        {
            var mb = new Form();
            mb.Text = caption;
            mb.Size = new Size(200, 100);
            mb.FormBorderStyle = FormBorderStyle.FixedSingle;
            mb.MinimizeBox = false;
            mb.MaximizeBox = false;
            
            var ok = new Button();
            ok.Text = "Okej";
            ok.Location = new Point(20, 30);
            mb.Controls.Add(ok);

            var lb = new Label();
            lb.Text = text;
            lb.Location = new Point(20, 10);
            mb.Controls.Add(lb);

            ok.Click += (object s, EventArgs e) =>
            {
                mb.DialogResult = DialogResult.OK;
                mb.Close();
            };

            mb.AcceptButton = ok;
            DialogResult result = mb.ShowDialog();
            mb.Dispose();
            return result;
        }
    }

kornik280 napisał(a):

Domyślnie ustawia mi się maksymalnie z prawej strony i nie wygląda to zbyt estetycznie.

Jeśli zamierzasz go ustawić na środku to pragnę przytoczyć cytat

Symetria jest estetyką głupców

Ja tylko podpowiem, że wycentrowanie przycisków w dialogach jest niezgodne z przyjętymi zasadami dotyczącymi UX na platformie Windows Desktop.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx#Dialogs20

Ktos napisał(a):

Ja tylko podpowiem, że wycentrowanie przycisków w dialogach jest niezgodne z przyjętymi zasadami dotyczącymi UX na platformie Windows Desktop.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx#Dialogs20

to chyba zależy od wersji Windows, bo jakoś przez lata buttony na message boxach były centrowane i nikomu to nie przeszkadzało, sam Windows w wielu swoich odsłonach łamie wszelkie możliwe wytyczne, np. w kwestii dialogów, DPI, clear-type, można ciągnąć to dalej i powiedzieć, że wytyczne, do których dałeś linka są w ogóle niepoprawne dla Modern UI (Metro), więc jak widzisz wszystko zależy od punktu siedzenia.

To są zasady dla Windows VIsta i nowszych. Dla desktopu, napisałem wyraźnie, nie dla Metro.
Fakt, że sami łamią (np. ikonografię), ale jak już zaczęto pracować, aby to było wspólne, to trzeba by się było trzymać, a nie każdy program z innej parafii, jak to czasami jest obecnie.

Sekcja "Disabling or removing controls vs. giving error messages"

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx#Dialogs20

obrazek:

http://i.msdn.microsoft.com/dynimg/IC368420.png

Widać po buttonach, że włączone jest clear type, natomiast elementy na dialogu już nie respektują ustawień systemowych. Jak tu ufać poradnikowi, który sam łamie zasady, o których mówi?

Kolejny przykład nierespektowania ustawień użytkownika to domyślne wygładzanie czcionek w aplikacjach WPF. W blogach pracowników MS można przeczytać np. na The Old New Thing, jak to programiści powinni respektować ustawienia użytkownika, a sam MS ma to głęboko w d...

Jak można ufać Microsoft przy projektowaniu GUI aplikacji i korzystać z ich poradników co do kontrolek, dialogów, gdy każda ich aplikacja bazuje na custom kontrolkach, własnych implementacjach buttonów, toolbarów, tabów, custom tematach graficznych - to szczyt chamstwa mówić innym jak mają korzystać z ich bazy kontrolek UI podczas gdy sami nawet ich nie używają?

Prosty przykład - dodatkowe style graficzne dla ListView czy TreeView z Explorera, które powodują, że aplikacje wyglądają nowocześnie, bez cudowania z OpenThemeData()/SetWindowTheme() z UXTHEME.dll nie ma szans na uzyskanie dobrze wyglądających aplikacji ze standardowymi kontrolkami Windows na Vista/7/8, nie rozumiem jakie przeszkody stały na drodze, żeby te wszystkie nowe style domyślnie zastosować do istniejących aplikacji (ta zaraz ktoś rzuci - wsteczna kombatybilnośc, ale do cholery to tylko kwestia wizualnego wyglądu).

Kolejny przykład nierespektowania ustawień użytkownika to domyślne wygładzanie czcionek w aplikacjach WPF.
Ale przynajmniej to zaimplementowali (w 4.0 bodajże). Za to Office 2013, IE11 i kafelki w Win8 już w ogóle nie mają wygładzania podpikselowego i tekst wygląda krapiasto.

bez cudowania z OpenThemeData()/SetWindowTheme() z UXTHEME.dll
Sytuację komplikuje fakt, że dopiero w Win8 masz gwarancję, że uxtheme.dll działa. Pod Vistą i Win7 funkcja OpenThemeData ma prawo zwrócić błąd.

Mam podobny problem.
Mam formę główną o wymiarach znacznie mniejszych niż ekran. Po wciśnięciu przycisku chciałbym, aby się pojawiała nowa forma(własny messagebox). Zależy mi, aby nowa forma pojawiła się w obrębie starej formy. Ja to uzyskać? Przykładowo jeśli forma główna będzie w górnym lewym rogu, to nowa forma też w tych okolicach powinna być. Jeśli główna będzie w dolnej części ekranu to nowa gdzieś na dole.

Trzeba zrobić to po prostu ręcznie.
Czyli pobrać pozycję i rozmiar okna głównego, wyliczyć środek, i obliczyć pozycję nowej formy.

Tak właśnie myślałem, tylko nie wiem jak się dobrać do pozycji okna głównego?

this.Top

i this.Left

Dzięki wielkie.

Chyba coś źle robię, bo nowe okienko pojawia się zawsze w tym samym miejscu niezależnie od pozycji głównego.

 
private void button1_Click(object sender, EventArgs e)
        {
                int x = this.Left;
                int y = this.Top;
                Form mb = new Form();
                mb.Location = new System.Drawing.Point(x+50, y+100);
                mb.Size = new System.Drawing.Size(200, 100);
                mb.Show();
                //clear();
        }

Brakuje jeszcze

 mb.StartPosition = FormStartPosition.Manual;