Zweites Fenster / Hilfefenster nach ButtonClick

Mulan81

Hallo,

ich bin gerade beim Umstieg von ABAP zu C++ und stoße auf ein Problem, dass ich in ähnlicher Weise hier bereits gelesen habe, aber leider bringen die Antworten mich nicht zu einer funktionierenden Lösung.

Eigentlich möchte ich gerne eine Hilfedatei (oder pdf Datei) beim Klick auf einen Button öffnen.
Ich habe eine Methode für den Klick auf den Menüeintrag erstellt:

System::Void Hilfe_Click(System::Object^  sender, System::EventArgs^  e)

als erstes habe ich versucht hier den Aufruf der Hilfe mit dem Befehl:

Help::ShowHelp( this, "file://c:\.....chm", HelpNavigator::Index )

versucht. Aber leider passiert garnichts, wenn ich den Code ausführe.
(Am liebsten hätte ich ja vorher eine zweite Form gemacht und diese dann anstelle von this eingegeben, aber da 1. noch nicht funktioniert hat).

Danach habe ich versucht einfach eine zweite Form zu öffnen, wenn ich auf den Eintrag klicke. habe die Form in der Hauptform includiert und dann mit Hilfe der FAQ des Forums folgendes gemacht:

Form2^ formneu = gcnew Form2();
 formneu->ShowDialog();

in der Methode zum Klick => es passiert wieder nichts
in der Methode load => zweite Form wird nach der ersten aufgemacht.

Kann mir jemand sagen, was ich falsch mache?

Vielen Dank
Mulan

nn

Mulan81 schrieb:

Kann mir jemand sagen, was ich falsch mache?

Du verwendest C++/CLI und hälst es für C++. Man sollte C++/CLI nur noch für Interfacing zwischen .net und nativem C++ einsetzen.

Unser Klassiker:
http://www.c-plusplus.net/forum/263084
und die passende Stelle aus der Hilfe von Visual Studio 2012

The following project templates no longer exist:
- Windows Forms Application
- Windows Forms Control Library

Although we recommend that you do not create Windows Forms applications in C++/CLI, maintenance of existing C++/CLI UI applications is supported. If you have to create a Windows Forms application, or any other .NET UI application, use C# or Visual Basic. Use C++/CLI for interoperability purposes only.

Wenn du trotzdem C++/CLI WindowsForms machen willst und es nicht funktioniert, dann ist das gut so. Es hält dich von weiterem Unsinn ab.

Wenn du mit Windows Forms arbeiten willst, nimm C#. Ein PDF im damit verknüpften Leseprogramm anzuzeigen, geht dort übrigens so:
http://www.csharp-examples.net/open-file-with-default-application/

Doug_HH

Gehe mal bitte mit dem Debugger durch den Code.
Das sieht danach aus, als wenn der Button keine Click - Event besitzt.

Mulan81

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

nn

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.

Mulan81

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

nn

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.

Mulan81

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

nn

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.

Doug_HH

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

Th69

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.

Doug_HH

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.

nn

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

nach 2 Monaten jetzt das PDF über Process aufruft
das zweite Formular jetzt über einen "System Befehl" (system ?) aufruft (auch nach 2 Monaten)
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.

nn

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.