Klotzkopp

Nein, das ist ganz leicht. Hättest Du gleich gesagt, was Du willst, hätten wir das viel schneller lösen können. Statuszeilentexte und Tooltips sind nämlich schon eingebaut: Du musst nur in der Stringtabelle einen neuen String anlegen, mit derselben Ressource-ID wie der Menüeintrag. In diesem Text stehen zwei Texte, getrennt durch ein \n. Der Text vor dem \n erscheint in der Statuszeile, der nach dem \n im Tooltip, falls die Ressource-ID auch einem Toolbar-Button zugeordnet wurde. Beispiel: Das ist der Statuszeilentext\nDer Tooltiptext steht hier

Wer immer noch den Internet Explorer mit per Default eingeschaltetem Active Scripting benutzt, der ist IMHO selbst schuld. Whitelist führen und gut ist

Das ist normal. Eine Fensterklasse hat erst nach dem Create ein gültiges Handle. Aber wenn Du jetzt diese abgeleitete Klasse nicht mehr benutzt, ist auch klar, warum die Dialog nicht mehr angezeigt werden: Ein gewöhnliches CTabCtrl besteht nur aus den Tabs selbst. Um die Darstellung der Dialoge musst Du Dich selbst kümmern. Wahrscheinlich hat das diese Klasse aber für Dich gemacht.

Seltsam. Hast Du noch was anderes geändert? Wie hast Du die Tabs vorher hinzugefügt?

Du musst die Maske der TCITEM-Struktur setzen, damit die Methode weiß, welche Teile der Struktur gültige Daten enthalten. item.mask = TCIF_TEXT | TCIF_PARAM;

Die Funktion kannst Du auch selbst deaktivieren. Womöglich reicht es schon, HKCU\Control Panel\Desktop\ForegroundLockTimeout auf 0 zu setzen.

Üblicherweise speichert man beim Hinzufügen einen Zeiger auf die Instanz der Dialogklasse im lParam der TCITEM-Struktur.

Ruhig bleiben, kein Grund für Satzzeicheninflation Das ist ein Feature von Windows XP, gegen das Du codeseitig AFAIK nichts machen kannst. Mit TweakUI kann man das abstellen, unter General->Focus->Prevent Applications from stealing focus.

ADO ist ein Wrapper für OLEDB. ADO bietet Collections und Objekte, um damit die am häufigsten verwendeten Features von OLEDB aus jeder Sprache heraus nutzen zu können, die COM und Automatisierung unterstützt. Daraus folgt: - ADO kann nicht mehr bieten als OLEDB, wahrscheinlich eher weniger. - ADO ist langsamer als OLEDB. Aber auch: - ADO ist einfacher in der Verwendung. - ADO kann in vielen Sprachen verwendet werden.

Wahrscheinlich meint er CWnd::GetWindowText. Probleme sollten trotzdem nicht auftreten, auch wenn er ::GetWindowText verwendet, denn unter der Haube machen die MFC auch nichts anderes.

Du machst einfach genau das, was Du machen würdest, um den COM-Port zu öffnen: HANDLE hCom == CreateFile ( "COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if( INVALID_HANDLE_VALUE == hCom ) { if( GetLastError() == ERROR_ACCESS_DENIED ) { // war schon geöffnet } else { // anderer Fehler } } else { // war noch nicht geöffnet CloseHandle( hCom ); }[/CODE]

Wie gesagt, wenn der COM-Port schon geöffnet ist, wird CreateFile fehlschlagen.

Für Windows gibt es GetDateFormat und GetTimeFormat.

Da unter Windows eine Kommunikationsressource immer nur einmal geöffnet werden kann, wirst Du das am einfachsten dadurch feststellen können, dass Du den COM-Port gar nicht öffnen kannst.

Jede Viewklasse ist von CWnd abgeleitet, also kannst Du int CWnd::MessageBox( LPCTSTR lpszText, LPCTSTR lpszCaption = NULL, UINT nType = MB_OK ); verwenden. Dokumentklassen sind nicht von CWnd abgeleitet, also brauchst Du die WinAPI-MessageBox: int MessageBox( HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType ); In Deinem Fall sähe das so aus: int yesno = MessageBox( AfxGetMainWnd()->GetSafeHwnd(), messText, "Wert größer 5", MB_YESNO|MB_ICONEXCLAMATION);

Ich verstehe nicht wirklich viel von Javascript, aber das Leerzeichen zwischen "entscheid." und "htm" könnte Probleme bereiten.

Dann hast Du UpdateData( FALSE ) entweder ganz vergessen oder vor dem Replace gemacht.

\r\n

Wie kommst Du denn darauf? Es ist einfach eine Frechheit seitens des Schreibenden, dass er die Arbeit, die er selbst zu tun zu faul ist, den Lesern aufbürdet. Dass Standart ein nicht auszurottender Fehler ist, daran müssen wir uns wohl gewöhnen. Aber ich kann einen Text viel schneller erfassen, wenn Rechtschreibung und Zeichensetzung stimmen. Dementsprechend sinkt auch meine Hilfsbereitschaft, wenn jemand glaubt, sich diese Mühe nicht machen zu müssen. Tu Dir selbst und anderen einen Gefallen Zumindest die Treiber werden Dir ohne ein Betriebssystem nichts nützen. Pack doch einfach kurz DOS drauf.

Entweder ist das Flag CFM_COLOR in dwMask nicht gesetzt, oder das Flag CFE_AUTOCOLOR in dwEffects ist gesetzt. Versuch mal das hier: CHARFORMAT charformat; m_RichEditCtrl.SetSel(2, 12); m_RichEditCtrl.GetSelectionCharFormat(charformat); charformat.crTextColor = FontDialog.GetColor(); [color=darkred]charformat.dwMask |= CFM_COLOR; charformat.dwEffects &= ~CFE_AUTOCOLOR;[/color] m_RichEditCtrl.SetSelectionCharFormat(charformat);[/CODE]

Du selektierst den zu ändernden Text, und verschickst EM_SETCHARFORMAT (bzw. rufst CRichEditCtrl::SetSelectionCharFormat auf, falls Du die MFC verwendest). In der CHARFORMAT-Struktur, die als Parameter übergeben wird, gibt es einen COLORREF-Member namens crTextColor.

Es gibt diverse Tools, die die sogenannten Dependencies (Abhängigkeiten) anzeigen können, so z.B. Depends aus den Visual Studio 6 Tools, oder WinFM. Bei mspaint.exe Version 5.1.2600.1106 (XP SP1) sind es: MFC42U.DLL MSVCRT.DLL ADVAPI32.DLL KERNEL32.DLL GDI32.DLL USER32.DLL COMMDLG32.DLL OLE32.DLL OLEAUT32.DLL SHELL32.DLL IMM32.DLL

Dann gib die MessageBox doch da aus, und mach bei IDNO einfach return FALSE.

Aber wenn Du in CMeinProgrammView::OnInitialUpdate an "wert" herankommst, sollte es in CMeinProgrammView::PreCreateWindow doch auch gehen...

Ich zum Beispiel. Oh, Du willst wissen, wie es geht? itoa, mit 16 als Basis, oder sprintf mit "%x" als Format. Kommt drauf an, in welcher Form die Dualzahlen vorliegen. Zahl oder Text? Jedenfalls würde ich zuerst eine Dezimalzahl draus machen, und dann wie oben vorgehen.