ich möchte gerne eine Editbox (über den Ressourceneditor erstellt) in einem Dialog transparent auf eine Bitmap zeichnen. Den Rahmen konnte ich schon per Styleflags entfernen, aber wenn ich auf WM_CTLCOLOREDIT reagiere, indem ich SetBkMode(wParam, TRANSPARENT) aufrufe und anschließend noch einen HOLLOW_BRUSH zurückgebe, gibt es Probleme beim Zeichnen: Zwar hat die Editbox keinen Rahmen und keine Hintergrundfarbe mehr, aber wenn ich ein Wort eingebe und dieses wieder löschen will, bewegt sich nur das Caret wieder zurück. Der Text wird aber nicht entfernt.

Anscheinend gibt es ein Problem beim Neuzeichnen der Editbox. Ich vermute mal, dass irgendeine DefWndProc() mit meinem übergebenen HOLLOW_BRUSH die Editbox "übermalen" will, was natürlich erfolglos bleibt.

Hat jemand eine Idee, wie man dieses Problem lösen könnte? Bei google fand ich nur eine Umsetzung per MFC (ich hab keine Ahnung davon) und außerdem war da irgendwie nichts beschrieben, sondern lediglich ein kompletter Sourcecode des ganzen Projekts verfügbar.

ph4nt0m

ph4nt0m

Du musst also veranllasen, dass beim WM_ERASEBKGND im Edit Control der Parent Hintergrund neu gezeichnet wird.

ph4nt0m

Ich habe jetzt der Editbox eine eigene Fensterprozedur zugeordnet (Subclassing) und dann dort bei WM_ERASEBKGND ein Neuzeichnen des Parentfensters mit
InvalidateRect(GetParent(hWnd), NULL, TRUE);
veranlasst.

Nun wird aber das gesamte Fenster anscheinend extrem oft neugezeichnet, obwohl ich noch gar nichts in die Editbox eingegeben habe und damit eigentlich kein Grund für zahlreiche Aufrufe von WM_ERASEBKGND besteht. Dennoch scheint diese Nachricht sehr oft an die Editbox gesendet zu werden...

Hat denn sonst vielleicht noch jemand einen Vorschlag?

ph4nt0m

Mfg Ominion

Leider funktioniert es bisher immer noch nicht. Ich habe jetzt einmal ein RECT entsprechend gefüllt und dann
InvalidateRect(GetParent(hWnd), &rc, TRUE);
UpdateWindow(GetParent(hWnd));
als Reaktion auf WM_ERASEBKGND des Editfensters aufgerufen. Im Bereich des RECTs berfindet sich nun aber ein dauerhafter Streifen in dem standard "Dialoggrau".

Auch ein Aufruf von
SendMessage(GetParent(hWnd), WM_ERASEBKGND, wParam, 0L);
Bewirkt dieselbe graue Farbe, nur auf dem ganzen Dialog und nicht nur innerhalb des Clippingrechteckes.

Ich habe nach wie vor irgendwie den Verdacht, dass WM_ERASEBKGND extrem oft an die Editbox gesendet wird und daher durch das viele Löschen ein dauerhaftes Grau entsteht. Ist WM_ERASEBKGND vielleicht die falsche Nachricht, auf die ich beim Editcontrol reagieren sollte?

ph4nt0m

@Martin Richter, deine sehr spezifische Frage, wo ich denn den Hintergrund zeichne, klang für mich so, als hättest du eine Lösung Wäre sehr nett, wenn du dich da nochmal melden würdest.

ph4nt0m

Aber was soll ich sagen: Es geht einfach immer noch nicht: Die eingegebenen Zeichen werden zwar angezeigt, aber beim anschließenden Löschen befinden sie sich immernoch auf dem Hintergrund. Ich hab echt keine Ahnung mehr, was da noch falsch sein könnte

ph4nt0m

Es geht mit zwei simplen Handlern. WM_CTLCOLOREDIT wird abgefangen und WM_ERASEBKGND.

IMPLEMENT_DYNAMIC(CTransparentEdit, CEdit)

CTransparentEdit::CTransparentEdit()
{

}

CTransparentEdit::~CTransparentEdit()
{
}

BEGIN_MESSAGE_MAP(CTransparentEdit, CEdit)
	ON_WM_ERASEBKGND()
	ON_WM_CTLCOLOR_REFLECT()
END_MESSAGE_MAP()

// CTransparentEdit message handlers

BOOL CTransparentEdit::OnEraseBkgnd(CDC* pDC)
{
	return static_cast<BOOL>(::SendMessage(GetParent()->GetSafeHwnd(),WM_ERASEBKGND,reinterpret_cast<WPARAM>(pDC->GetSafeHdc()),0));
}

HBRUSH CTransparentEdit::CtlColor(CDC* pDC, UINT /*nCtlColor*/)
{
	Default();
	pDC->SetBkMode(TRANSPARENT);
	return reinterpret_cast<HBRUSH>(GetStockObject(HOLLOW_BRUSH));
}

static LONG_PTR prevEditProc;

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
	return DialogBox(hInstance, MAKEINTRESOURCE(IDD_DIALOG1), NULL, DialogProc);
}

BOOL CALLBACK DialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{		
	HDC hDC;
	static IPicture * back;

	switch(message)
	{
	case WM_INITDIALOG: 
		prevEditProc = SetWindowLongPtr(GetDlgItem(hDlg, IDC_EDIT_NAME), GWLP_WNDPROC, (LONG_PTR) EditProc);
		back = LoadPicture(MAKEINTRESOURCE(IDB_BACKGROUND));
		return TRUE;

	case WM_ERASEBKGND:
		hDC = GetDC(hDlg);		
		DrawPicture(hDC, back, 0, 0);		
		ReleaseDC(hDlg, hDC);		
		return TRUE;

	case WM_CTLCOLOREDIT:		
		SetBkMode((HDC) wParam, TRANSPARENT);
		SetTextColor((HDC) wParam, RGB(255,255,255));
		return (BOOL) GetStockObject(HOLLOW_BRUSH);

	case WM_DESTROY:
	case WM_CLOSE:   
		SetWindowLongPtr(GetDlgItem(hDlg, IDC_EDIT_NAME), GWLP_WNDPROC, (LONG_PTR) prevEditProc);		
		EndDialog(hDlg,0);
		return TRUE;
	}
	return FALSE;
}

LRESULT CALLBACK EditProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	switch(message)
	{
	case WM_ERASEBKGND:		
		return SendMessage(GetParent(hWnd), WM_ERASEBKGND, wParam, 0L);

	default:
		break;
	}
	return CallWindowProc((WNDPROC) prevEditProc, hWnd, message, wParam, lParam);
}

Eigentlich müsste ich meines Wissens nach alles so gemacht haben wie du (mal von MFC->WinAPI abgesehen). Mir ist nur irgendwie aufgefallen, dass du WM_CTLCOLOREDIT beim Editcontrol selbst zu verarbeiten scheinst!? Ich mache das in der Dialogprozedur, aber daran kanns eigentlich nicht liegen, weil der Hintergrund ja schließlich transparent ist. Das Problem ist halt, dass das Hintergrundbitmap nicht neu gezeichnet wird, wenn sich der Inhalt der Editbox ändert...

ph4nt0m

Was könnte ich denn noch ausprobieren? Ich bin für jeden Vorschlag dankbar. Mittlerweile hänge ich schon seit fast einer Woche an dem Problem und würde dafür so gerne endlich mal eine Lösung haben

ph4nt0m

Was ist denn jetzt noch Dein Problem. Mein Code funktioniert relativ gut. Besser wäre er noch wenn ich das Clipping auf das rect des Edit Controls beschränke.
Ich habe aktuell aber keine Lust das ganze runterzuschreiben...

Allerdings habe ich folgendes entdeckt: Spy++ auf das Editcontrol angewandt zeigt bei Löschen des Inhalts nie WM_ERASEBKGND an. Und jetzt kommts noch besser: Ein direkter Breakpoint auf die Anweisung unter WM_ERASEBKGND des Editcontrols stoppt die Programmausführung nicht, wenn ich einen eingegebenen Text lösche. Ist das nicht ein Beweis dafür, dass WM_ERASEBKGND gar nicht an meine Editbox gesendet wird, wenn ich Text darin lösche, und somit auch keine Weiterleitung an das Parent geschieht -> Hintergrund wird NICHT neu gezeichnet?

ph4nt0m

Such doch nochmal bei www.codeproject.com

ph4nt0m

Hab Dir bei Codeproject mal das rausgesucht, das sieht ganz gut aus:
- http://www.codeproject.com/dialog/pellucid.asp
- http://www.codeproject.com/staticctrl/transparentstatic.asp?df=100&forumid=13858&exp=0&select=431984

PS: Das ist auch alles (leider ) MFC, aber ich bin der Meinung, wer die WinAPI und C++ beherrscht (naja, mit dem Begriff sollte man wohl vorsichtig umgehen), kann auch MFC-Code verstehen.

Leider geht es mit SetLayeredWindowAttributes *nicht*...das wäre ne schöne Sache :p gewesen.

Probleme gibt es aber leider noch, wenn ich den Text in der Editbox mit der Maus durch Ziehen erst markiere und anschließend den blau markierten Bereich wieder durch Ziehen verkleinere. Dann bleibt die blaue Markierung leider bestehen. Gibt es da eventuell auch eine weitere Nachricht, bei der man den Hintergrund löschen könnte?

Eine andere Frage: Ich habe neben dem Hintergrundbitmap auch zwei Bitmapbuttons in meinem Dialog. Das sind normale Buttons, allerdings ist das Flag BS_OWNERDRAW gesetzt. Als Reaktion auf WM_DRAWITEM werden diese dann gezeichnet.

Da aber zwischendurch ja jetzt durch das Editcontrol ein WM_ERASEBKGND an das Parent weitergeleitet wird, wird mein Bitmaphintergrund neugezeichnet, OHNE dass die Bitmapbuttons danach neugezeichnet werden. Sie sind also kurz gesagt nicht mehr zu sehen. Es wird nach dem WM_ERASEBKGND weder WM_DRAWITEM, noch WM_PAINT aufgerufen. Wie könnte ich diese Problem lösen?

ph4nt0m

Oder WS_CLIPCHILDREN verwenden für den Dialog.

Es tut mir leid, wenn ich da langsam mit nerve. Ich hänge jetzt hier schon ewig mit diesem "eigentlich" trivialen Problem rum und halte dich damit irgendwie auf. Ich hätte am Anfang wirklich gedacht, dass das alles einfacher geht und nicht bei jedem Schritt wieder neue Probleme auftauchen

ph4nt0m