Zweites Fenster / Hilfefenster nach ButtonClick



  • Hallo,

    @Doug_HH : danke für den Hinweis, ansttat auf dem Menüitem das Click - event zu legen, hatte ich es nur auf den Button, der davor war (und der ist ziemlich klein, so dass ich vermutlich einfach nie darauf geklickt habe).

    @nn: Ich habe den Post gelesen, und muss gestehen, die Auswirkungen habe ich so verstanden, dass zwei WindowsForms nicht unbedingt gut miteinandern 'reden' können. Ist diese Aussage korrekt? Für das Anzeigen der Hilfe (die ich als chm Datei, oder als PDF erstellen wollte) finde ich das nicht weiter tragisch, aber im weiteren Verlauf könnte mir das bei anderen Aufagebn auf die Füße fallen .... aber was ich bei dem Post nicht verstehe ist, welche Art von prijekt mit mehreren unterschiedlichen Forms ist denn das beste, wenn die einzelnen teile miteinader interagieren sollen? Ich habe mir das Buch "Visual C++ 2010" besorgt und das Kapitel 10 zu windows Anwendungen hilft mir auch nicht weiter, da hier schon erklärt ist, wie cih die Dialogfelder benutze, aber ich keinen Hinweis finde, der den Post, oder auch die Hilfe für mich verständlich macht ....

    Viele Grüße
    Mulan



  • Mulan81 schrieb:

    @nn: Ich habe den Post gelesen, und muss gestehen, die Auswirkungen habe ich so verstanden, dass zwei WindowsForms nicht unbedingt gut miteinandern 'reden' können. Ist diese Aussage korrekt?

    Nein, in C# oder Visual Basic können zwei WindowsForms sehr gut miteinander reden.

    In C++/CLI können sie das auf die gleiche Weise, aber es wird hundermal komplizierter hingeschrieben.

    In diesem Thread
    http://www.c-plusplus.net/forum/307661-10
    hat es dot sehr schön auf den Punkt gebracht

    dot schrieb:

    Von allen Programmiersprachen, die sich die Menschen bisher so ausgedacht haben, gibt es wirklich kaum eine, die für Anfänger weniger sinnvoll wäre, als C++/CLI. Es wäre unverantwortlich, dir einfach nur bei deinem Problem zu helfen, denn das würde bedeuten, dass du weiterhin C++/CLI verwendest. Und das ist so ziemlich das letzte ist, was du tun solltest.

    Wenn du C++ lernen willst, dann lern C++. C++/CLI ist nicht C++. Es ist unmöglich eine Windows Forms Anwendung in C++ zu schreiben. Die Tatsache, dass man Windows Forms in C++/CLI überhaupt verwenden kann, ist lediglich eine unvermeidbare Folge seines wirklichen Zwecks: Managed/Unmanaged Interop. C++/CLI war nie, ist nicht und wird niemals dafür gedacht sein, dass komplette Windows Forms Anwendungen bzw. überhaupt ganze .NET Anwendungen darin geschrieben werden und Microsoft hat wohl mit VS 2012 endlich versucht, es möglichst schwer zu machen, diesen Fehler zu begehen...

    Wenn du C++ lernen willst, dann lern C++. Wenn du Windows Forms Anwendungen zusammenklicken willst, dann verwend C#. C++/CLI ist in jedem Fall völlig ungeeignet für dich.

    Wie gesagt, du glaubst nur, dass du C++ programmierst, in Wirklichkeit schreibst du in sehr umständlicher Weise das Innenleben einer C#-Anwendung in C++/CLI nach.

    Dass es Bücher gibt, die das auch noch empfehlen, zeigt nur, dass wirklich jeder ein Buch schreiben und damit Geld verdienen darf.



  • Hi,

    ok, danke. Tja, da ich nicht so ganz frei bin bei der Auswahl von Tool und Sprache (Spracherweiterung) C++/CLI und Visual Studio sind gesetzt ist das Umschwenken auf c# keine Alternative.

    Aber vielen Dank für die Erklärung

    Viele Grüße
    Mulan



  • Es ist ja nicht so, dass man keine C++ Logik zusammen mit Windows Forms verwenden könnte. Das ist sogar üblich. Aber dann erstellt man innerhalb einer Visual Studio Projektmappe ein C# Projekt für die Formulare und ein C++/CLI Klassenbibliotheksprojekt oder eine native C++ DLL.

    Aus C# kann man sowohl aus einer DLL exportierte C++/CLI Klassen als auch native C-Funktionen aufrufen. Das erstere ist der Sinn von C++/CLI.

    An der Verwendung von C++/CLI in Formularen ist in soweit nichts "gesetzt", das ist schlicht Dummheit und Unwissen im Umgang mit Visual Studio.



  • nett mir gleich Dummheit zu bescheinigen .... naja, mein Button funktioniert über einen System Aufruf.



  • Mulan81 schrieb:

    naja, mein Button funktioniert über einen System Aufruf.

    Das zeigt ja, dass ich mit meiner Einschätzung richtig liege. Einfach ein anderes Programm aufrufen, wenn man es nicht in einem programmiert kriegt.

    Oder die tolle "Lösung" hier:
    http://www.c-plusplus.net/forum/310872
    Einfach das Standard PDF-Programm starten (hoffentlich ist eines installiert), sicher ganz tolle C++ Programmierung einer PDF Anzeige.

    Oder wo soll ich weitermachen ?
    Da http://www.c-plusplus.net/forum/312382
    oder da http://www.c-plusplus.net/forum/312483

    Wie oben von anderen gesagt: WindowsForms mit C++/CLI verwenden Leute, die nicht wissen, was sie tun. Du zeigst das mit jedem neuen Posting.



  • nn schrieb:

    Mulan81 schrieb:

    Oder die tolle "Lösung" hier:
    http://www.c-plusplus.net/forum/310872
    Einfach das Standard PDF-Programm starten (hoffentlich ist eines installiert), sicher ganz tolle C++ Programmierung einer PDF Anzeige.

    Hast Du ihm das nicht selber in Deinem 2. Posting vorgeschlagen!? 😕

    nn schrieb:

    Wie oben von anderen gesagt: WindowsForms mit C++/CLI verwenden Leute, die nicht wissen, was sie tun. Du zeigst das mit jedem neuen Posting.

    Mach ich auch, (zwar nur als Schnittstelle) lässt sich nicht immer vermeiden, und ich bin davon überzeugt das ich weiß was ich tue.

    Deine Antwort ist somit nicht ganz korrekt.

    Und zudem hatte Mulan81 bereits gesagt, dass er in C++/CLI schreiben muss.

    Gruß

    Doug_HH



  • Hallo Doug_HH,

    der Satz von nn ist doch eindeutig ironisch gemeint!

    Und man muß sicherlich niemals Oberflächen (WinForms) in C++/CLI schreiben, dafür gibt es zu viele bessere Alternativen.



  • Th69 schrieb:

    Hallo Doug_HH,

    der Satz von nn ist doch eindeutig ironisch gemeint!

    Mag sein, kannst Du recht haben ;o).

    Th69 schrieb:

    Und man muß sicherlich niemals Oberflächen (WinForms) in C++/CLI schreiben, dafür gibt es zu viele bessere Alternativen.

    War aber in diesem Fall schneller und demnach günstiger, mein Kunde arbeitet noch immer damit.
    Aber bei der nächsten Version werde ich komplett auf C# setzen.



  • Th69 schrieb:

    der Satz von nn ist doch eindeutig ironisch gemeint!

    Bedingt, am Sonntag waren da innerhalb kurzer Zeit drei Postings von ihm, dass er

    1. nach 2 Monaten jetzt das PDF über Process aufruft
    2. das zweite Formular jetzt über einen "System Befehl" (system ?) aufruft (auch nach 2 Monaten)
    3. nicht weiß, wie man an die Elemente einer List oder von vector herankommt.

    Natürlich ist da dann C++/CLI gesetzt, aber im Sinne von Brett vorm Kopf, entweder bei ihm oder dem der ihm die Aufgabe gegeben hat. Gründe für C++ gibt es nicht, es wird nur schlechtes C# in C++/CLI nachprogrammiert.

    Wenn man ihm diese Aufgabe gegeben hat, damit er programmieren lernt, wird er offenbar optimal betreut.

    Aber es ist ja gut, dass jetzt Experte erschienen ist, der weiß was er tut.

    Viel Spaß



  • @nn, Du bist schon ein Klugscheißer...

    Richtige Antworten hast Du keinem deiner post gegeben nur immer den selben blöden mist. Oft anders verpackt, aber im Grunde nur Dünnschiss.



  • Klugscheißer schrieb:

    Richtige Antworten hast Du keinem deiner post gegeben nur immer den selben blöden mist.

    Da waren ja auch

    http://www.c-plusplus.net/forum/311025
    oder
    http://www.c-plusplus.net/forum/312483

    Vor zwei Monaten will er u.a. WPF Controls einbinden, ich antworte mit Links und Literaturhinweisen. Jetzt ist er anscheinend so weit, dass er ein zweites WinForm über ein zweites Program mit system aufruft.

    Er kann aber, laut anderem Thread, den Zustand eines Panels als XML-Datei speichern und wiederherstellen.

    Im November fragt er nach "funktionalen Containern", im Januar kommt er nicht an die Elemente einer List. 😕

    Da soll man nicht patzig reagieren ? Das passt doch alles nicht zusammen.

    Aber egal, ich antworte ihm eh nicht mehr.


Anmelden zum Antworten