ich habe das problem bereits anders gelöst.
der fehler lag an der art wie ich das menu geladen habe, was wohl mit dem dialog zusammenhängt.
void CMachineStatusDlg::OnUpdateFileClosedatabase(CCmdUI *pCmdUI)
{
// Falsche Variante
// CMenu oMenu;
// oMenu.LoadMenu(IDR_MENU1);
// Richtige Variante
CMenu *poMenu;
poMenu = GetMenu();
CMenu* poSubMenu;
poSubMenu = poMenu->GetSubMenu(0);
poSubMenu->EnableMenuItem(ID_FILE_CLOSEDATABASE, MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
}
trotzdem danke für die hilfe
So wird in den Tray minimiert:
void CMainFrame::OnSize(UINT nType, int cx, int cy)
{
CFrameWnd::OnSize(nType, cx, cy);
if (nType == SIZE_MINIMIZED)
{
ShowWindow(SW_HIDE);
}
}
So, hier noch eine Ergänzung: http://www.c-plusplus.net/forum/viewtopic-var-t-is-167656.html
Da findet man, wie man den Pfad auch auch einem CString rausholen kann und wie man den Speicher aufräumt.
Nachschlag: Ich hab noch ein bissl mit den Ressoucendateien rumgespielt, weil ich gern mit dem Ressourceneditor ein paar kleine Änderungen vornehmen möchte. Der Dialog soll also keine richtig "externe" Ressource, nur gut importierbar. Deswegen hab ich noch ein paar Änderungen an LowFly's Ansatz vorgenommen.
1. Statt die Dialogressource (SchickerDialog.rc) bei der Projektressouce (MyProject.rc) bekannt zu machen, hab ich die Dialogressoure einfach in das Projekt importiert (SolutionExplorer->MyProject->RessourcenDateien->Add->ExistingItem). Damit wird die Dialogressource eigenständig kompiliert, was jedoch zu Fehlern führen kann. Deswegen:
2. Einfügen der Resource.h des Projekts in die Dialogressource:
// SchickerDialog.rc
#include "SchickerDialogResource.h"
#include "../resource.h" // Auf den Pfad achten
#include "afxres.h"
// ..
Damit kann der Dialog im Ressourceneditor bearbeitet werden (Bei der ersten Änderung überarbeitet MS die Datei).
estartu schrieb:
CodeFinder schrieb:
Hm Du willst also auf einem Fenster (sowohl Childs als auch Parents) verschiedene ToolTips unterbringen ?
Ich habe ja z.B. mehrere Edits in einem View.
Dann übergib einfach als Handle an die ToolTip-Info-Struktur den Handle des betroffenen Edit-Controls.
Dann wird automatisch der Client-Bereich des entsprechenden Edits genommen .
Vgl. Code hier:
// unter WM_CREATE...
// [...]
tiToolInfo.hwnd = hWnd;
// [...]
komisch, ich hab mal in VS2003 eine klasse von CToolTipCtrl abgeleitet - da hab ich es auch zur auswahl
=TTN_SHOW
und der erstellt mir auch die selbe messagemap
BEGIN_MESSAGE_MAP(COwnToolTip, CToolTipCtrl)
ON_NOTIFY_REFLECT(TTN_SHOW, OnTtnTooltipShow)
END_MESSAGE_MAP()
in vs6 hab ichs noch nicht probiert - install hab ichs, aber arbeite damit nie #gg
Ich finde es auch keine Tragik und die MS-Entwickler haben sich sicherlich etwas dabei gedacht 0=FALSE und 1=TRUE äquivalent für die Buttonstates zu verwednden.
Tückisch wird es einfach eil es auch BST_INDETERMINATE == 2 gibt bei einem Tristate Button und noch tückischer wird es wenn man BOOL statt bool verwendet.
BOOL bTrue = 4;
m_bButton.SetCheck(bTrue);
führt dann zu evtl. zu einem undefiniertem Verhalten.
Während:
bool bTrue = 4;
m_bButton.SetCheck(bTrue);
trefflich funktioniert!
Entsprechend sollte man wirklich schreiben was man meint:
BOOL bTrue = 4;
m_bButton.SetCheck(bTrue ? BST_CHECKED : BST_UNCHECKED);
Just my 2 cents!
Hier noch ein interessanter Link dazu:
http://www.codeproject.com/debug/XCrashReportPt1.asp
*Introduction
One of the biggest challenges for a developer is to debug a program that has been put into production or shipped to a customer. On the developer's workstation, the program works fine. But on the customer's system, there are random crashes. There is often no direct access to the customer's system, because of distance. Writing to the event log or other log file may be helpful, but can only point in a direction, not give a precise location.
This was the state I was in when I read Bruce Dawson's paper on Release Mode Debugging. Dawson's paper discusses several techniques that I had never encountered before, including how to capture the instruction pointer (ip) of a crash, and how to plug the ip into VC++ and go directly to the source line of the crash. (I am talking about VC++ 6.0 here, not .Net).
These new techniques led me toward the holy grail of developers: being able to see a stack trace of each function that led up to the crash. At several points along the way, I thought to myself, "Well, this is pretty complete, there's nothing more to add." But then I would see there was another approach, another API I had overlooked, and I kept on.*
... mehr auf der Seite
estartu schrieb:
Ist es echt nur beim Richedit?
Ich hatte den Verdacht, dass man das an mehr Stellen beachten sollte.
Du hast vollkommen Recht estartu! Das gilt für alle Windows Nachrichten, die man verändert, d.h. mit anderen wParam/lParam Werten, an die Basisklasse weitergeben möchten.
So etwas wie: "Ändern der Nachrichten Argumente vor Aufruf der Basisklasse"
o.ä.
