Klotzkopp

@Terran Marine: Danke @Azubi 2002: Zum Zwecke der Informationsbündelung weiterführende Fragen bitte im verlinkten Thema stellen. @Thema: Zu bist du.

Wie ich schon sagte: Lass den zweiten Dialog durch dieselbe Funktion anzeigen, die auch den ersten anzeigt. Der Wert, den du bei EndDialog als Parameter angibst, erscheint als Rückgabewert von DoModal: ... Modalen2Dlg dlg2; if( [B]25[/B] == dlg2.DoModal() ) { Modalen1Dlg healthdlg; healthdlg.DoModal(); ... void Modalen2gDlg::OnZuruck() { CDialog::EndDialog( [B]25[/B] ); } [/CODE]

Sauber ist das sicher nicht. Warum übergibst du beim Aufruf von EndDialog nicht einen Wert, an dem die Funktion, die Modalen2gDlg::DoModal aufgerufen hat, erkennt, dass danach Modalen1Dlg angezeigt werden soll? Zu dem anderen Problem: Was für ein Fehler tritt auf?

Da kannst du mit kbhit (auch aus conio.h) testen, ob eine Taste gedrückt wurde. Wenn kbhit nicht Null zurückgibt, kannst du getch aufrufen, und sicher sein, dass es nicht blockiert.

Die gibt's mit Sicherheit, aber wie ich schon sagte, nicht mit Standard-C. Du musst uns also schon verraten, für welches Betriebssystem und mit welchem Compiler du arbeitest.

Volt * Ampère ist dann nicht mehr Watt, wenn man Wechselspannungen und Wechselströme betrachtet. Wenn da die Schwingungen von Spannung und Strom nicht in Phase sind, ist Volt * Ampère erstmal nur "Voltampère". Wieviel Watt das sind, hängt vom Phasenunterscheid ab.

#include <iostream> using namespace std; int main() {[/CODE]

Und damit das ziellose Rätselraten ein Ende hat, mache ich hier vorerst dicht. @Eli78: Wenn du dein Vorhaben etwas genauer beschreiben kannst, bitte eine PN an mich, dann mache ich wieder auf.

@SGDJens: Was du vorhast, ist AFAIK mit Standard-C nicht möglich. Es gibt aber betriebssystemspezifische Funktionen, die das können. Für die Abfrage könntest du z.B. Threads benutzen.

Wie kommst du auf 1,4? Der Wert sollte nicht konstant sein, sondern vom Winkel zwischen den Vektorgrößen Spannung und Strom abhängen.

Klar. Es sieht übrigens etwas anders aus als in meinem vorherigen Beitrag, weil ich nicht daran gedacht habe, dass der operator<<(int) ein Member von basic_ostream ist. operator<<( operator<<( operator<<( operator<<( cout.operator<<(x)," " ).operator<<(y)," " ).operator<<(z), " " ).operator<<(x=y=z=40)," " ).operator<<(x);[/CODE]

Nein, weil des dem Compiler überlassen bleibt, in welcher Reihenfolge die Argumente des operator<< abgearbeitet werden. Ich habe deinen Ausdruck mal so umgestellt, dass die operator<<-Aufrufe ausgeschrieben und die Leerzeichen weg sind: op<<(op<<(op<<(op<<(op<<(cout,x), y), z), x=y=z=40), x) Der Compiler kann sich jetzt aussuchen, welches Funktionsargument er zuerst auswertet. Die Reihenfolge, in der x, y, z, x (Ref. Nummer 2), cout und die Zuweisungen ausgewertet werden, ist undefiniert.

Bei mir funktioniert das mit MSVC 7 und Dev-C++ 4.9.7. Hast du die Zeilen vor das zweite scanf gesetzt? Wenn ja, zeig bitte mal deinen kompletten Code.

Der Standard gibt als Rückgabewerte von strcmp keine bestimmten Werte, sondern nur Null, größer als Null und kleiner als Null an. Diesbezüglich verhalten sich beide Compiler standardgemäß. Ein "Problem" kann da IMHO nur auftreten, wenn der Programmierer sich auf bestimmte Rückgabewerte verlässt oder die Werte noch irgendwie interpretiert.

Das geht. Schau mal hier rein.

Nach allem, was ich herausgefunden habe, ist es bei Outlook 2000 nicht möglich, das Kontextmenü zu modifizieren. Zu späteren Versionen habe ich nichts gefunden.

Das könnte z.B. folgendermaßen aussehen: Als erstes brauchst du eine Message-ID, die das Trayicon an dein Dialogfenster schickt: #define UM_TRAY_ACTION (WM_USER+0x100) Um das Fenster aus- und das TrayIcon einzublenden: ShowWindow( SW_HIDE ); NOTIFYICONDATA nid; memset( &nid, 0, sizeof( nid)); nid.cbSize = sizeof(NOTIFYICONDATA); nid.hWnd = GetSafeHwnd(); nid.uID = 0; nid.uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP; nid.uCallbackMessage = UM_TRAY_ACTION; wsprintf( nid.szTip, TEXT("TrayIcon ToolTip")); nid.hIcon = IrgendeinHICON; // z.B. m_hIcon der Dialogklasse Shell_NotifyIcon( NIM_ADD, &nid);[/CODE] Umgekehrt: [CODE]NOTIFYICONDATA nid; memset( &nid, 0, sizeof( nid)); nid.cbSize = sizeof(NOTIFYICONDATA); nid.hWnd = hWnd; nid.uID = 0; Shell_NotifyIcon( NIM_DELETE, &nid); ShowWindow( SW_SHOW ); Damit du aber von der Tray-Nachricht überhaupt etwas mitbekommst, brauchst du eine Behandlungsfunktion. Deklariere in deiner Dialogklasse: LRESULT OnTrayAction( WPARAM wParam, LPARAM lParam); (der Name ist dabei willkürlich gewählt, wenn der Compiler sich an LRESULT stört, nimm void) Die Funktion musst du in die Messagemap der Dialogklasse einfügen, am besten nach //}}AFX_MSG_MAP, damit der Wizard nicht durcheinanderkommt: ON_MESSAGE(UM_TRAY_ACTION, OnTrayAction) Die Funktion könnte so aussehen: LRESULT CDeinDlg::OnTrayAction( WPARAM wParam, LPARAM lParam) { if( lParam == WM_LBUTTONDBLCLK ) { // Hier den Code zum Entfernen des Trayicons // und Anzeigen des Dialogs einfügen oder // aufrufen. } return 0; }[/code]

Wenn CDialog::DoModal bei dir vom Typ int ist, dann musst du die Methode auch als int überschreiben. Offenbar haben wir unterschiedliche Versionen der MFC. Im Resource-Editor, wenn du dir die Eigenschaften des Dialogs anzeigen lässt.

Innerhalb von OnInitDialog ist es nicht möglich, mit ShowWindow oder ModifyStyle das Anzeigen zu verhinden, weil die MFC selbst dafür sorgt, dass der Dialog angezeigt wird, sobald es möglich ist. Das kann man nur verhindern, indem man CDialog::DoModal überschreibt. Dazu deklarierst du in deiner Dialogklasse die Methode public: INT_PTR DoModal(); Für die Implementierung übernimmst du den Code aus CDialog::DoModal (aus dlgcore.cpp, im MFC-Source-Verzeichnis), und machst die folgenden Änderungen: Zusätzlich: #include <afxpriv.h> Ersetzen (jeweils einmal): MLF_SHOWONIDLE durch 0 (das ist das Entscheidende) DELETE_EXCEPTION(e) durch e->Delete() (sonst gibts einen Compilerfehler) Nachtrag: Das Visible-Flag des Dialogs musst du natürlich auf False stellen.

@paule22: Um an das Fensterhandle zu kommen, kannst du den Fensterbaum mit FindWindowEx durchsuchen. Wenn du dabei sowohl für den Fenster- als auch für den Klassennamen NULL angibst, werden alle Fenster gefunden. Um überhaupt mitzubekommen, wann das Fenster, das du suchst, angezeigt wird, kannst du Hooks verwenden. Wenn es sich um einen modalen Dialog handelt (z.B. MessageBox), kannst du einen Hook für WH_CALLWNDPROC oder WH_CALLWNDPROCRET einsetzen und bei WM_INITDIALOG prüfen, ob das Fenster erschienen ist.

Es gibt (neben der Autorenedition) drei Editionen: Standard, Professional und Enterprise. Einen Featurevergleich kannst du hier finden. Einen Händler habe ich leider auf die schnelle auch nicht gefunden. Du kannst aber auch mit Visual C++ 7 normale (also nicht .net) Programme schreiben, falls es das ist, worum es dir geht. P.S.: Ich habe mir erlaubt, den Threadtitel zu ändern. Sah ein wenig nach einem Stellenangebot aus.

Übrigens: In welcher Reihenfolge hier die Operatoren ausgewertet werden, kann sich der Compilerhersteller aussuchen. Das kann also mit einen anderen Compiler schon wieder ganz anders aussehen. Wenn man portablen Code schreiben will, sollte man auf solche Konstrukte verzichten.

Hier steht etwas über Prefetching: http://www.serverworldmagazine.com/monthly/2002/03/fastboot.shtml

Um den Eingabepuffer zu leeren, kannst du diesen beiden Zeilen vor den scanf-Aufruf setzen: setvbuf( stdin, NULL, _IONBF, 0 ); setvbuf( stdin, NULL, _IOFBF, BUFSIZ );[/CODE]

Jetzt kommen wir der Sache näher. Hier liegt nämlich das Problem. Die Adresse des Puffers, die du übergibst, bezieht sich auf den Adressraum deines Prozesses. Damit kann der andere Prozess nichts anfangen. Möglicherweise kommst du mit VirtualAllocEx weiter. Damit kannst du Speicher im Adressraum eines fremden Prozesses reservieren. Schau mal hier rein, da hatte wohl jemand das gleiche Problem: http://www.experts-exchange.com/Programming/Programming_Platforms/Win_Prog/Q_20096218.html