Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Widgets - General questions or Mixed problems » Problem with DHCTRL on Windows
Problem with DHCTRL on Windows [message #50304] Sat, 15 September 2018 13:25 Go to next message
mdelfede is currently offline  mdelfede
Messages: 1242
Registered: September 2007
Senior Contributor
Hi, here an animated gif explaining the problem:

index.php?t=getfile&id=5664&private=0

when I move the cursor over ANOTHER UPP widget, my DHCTRL, which is embedded into a TabCtrl, blanks.
No refresh nor paint is triggered on it, so it must be something in Upp which repaints a white background.
I tried to set a red background on StaticRect container which is inside TabCtrl, but my DHCTRL still gets a white background
when moving the mouse outside.

I'm out of ideas... some hint on where to look ? On Linux, both X11 and GTK, it doesn't show this behaviour.

Ciao

Massimo
  • Attachment: myimage.gif
    (Size: 999.35KB, Downloaded 61 times)
Re: Problem with DHCTRL on Windows [message #50305 is a reply to message #50304] Sat, 15 September 2018 15:34 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1242
Registered: September 2007
Senior Contributor
Weird... if I change the WindowProc like this :

LRESULT DHCtrl::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
	DEBUG_INFO("WindowProc:" << message);
-->	if(message == WM_ERASEBKGND)
-->		return true;
	GuiLock __;
	return DefWindowProc(hwnd, message, wParam, lParam);
}


The problem disappears. Don't know why, but that's a solution at least.
Re: Problem with DHCTRL on Windows [message #50451 is a reply to message #50305] Wed, 31 October 2018 15:17 Go to previous message
mirek is currently offline  mirek
Messages: 11508
Registered: November 2005
Ultimate Member
mdelfede wrote on Sat, 15 September 2018 15:34
Weird... if I change the WindowProc like this :

LRESULT DHCtrl::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
	DEBUG_INFO("WindowProc:" << message);
-->	if(message == WM_ERASEBKGND)
-->		return true;
	GuiLock __;
	return DefWindowProc(hwnd, message, wParam, lParam);
}


The problem disappears. Don't know why, but that's a solution at least.


Hi,

I have to say I am now in intense period of OpenGL development. I will probably cause you some problems, right now I suppose that "picking" does not work anymore (but IMO it should have been implemented separately anyway).

Things I have changed (so far just in Win32):

There is now just single OpenGL context. That is all that is required - OpenGL can switch context between windows. So it is faster and more importantly, textures etc.. can now be shared between windows safely.

I have noticed that if OpenGL view is part of application, some things are less snappy (e.g. when Splitter is involved), so I was playing with WM_PAINT a bit.

BTW, I think that I have did the same fix as you suggest independently, so perhaps you just updated to some intermediate variant.
Previous Topic: problem with IEBrowser from Control4U
Next Topic: Add compilable testcases for nontrivial problems!
Goto Forum:
  


Current Time: Thu Nov 22 11:53:42 CET 2018

Total time taken to generate the page: 0.00720 seconds