Home » U++ Library support » U++ Widgets - General questions or Mixed problems » DHCtrl, Ctrl NoBackPaint ignored?
| DHCtrl, Ctrl NoBackPaint ignored? [message #49843] |
Wed, 16 May 2018 16:06  |
luoganda
Messages: 205
Registered: November 2016
|
Experienced Member |
|
|
Using NoBackPaint or BackPaint(EXCLUDEPAINT) seems to be ignored(on DHCtrl for sure,on Ctrl probably the same).
When main window is resized, flickering is seen.
This could be probably solved on wPlatform with overriding WM_ERASEBKGND(just ret TRUE) if main Registered hBrushBack!=NULL.
|
|
|
|
| Re: DHCtrl, Ctrl NoBackPaint ignored? [message #49854 is a reply to message #49843] |
Fri, 18 May 2018 14:55  |
 |
mirek
Messages: 14112
Registered: November 2005
|
Ultimate Member |
|
|
luoganda wrote on Wed, 16 May 2018 16:06Using NoBackPaint or BackPaint(EXCLUDEPAINT) seems to be ignored(on DHCtrl for sure,on Ctrl probably the same).
When main window is resized, flickering is seen.
This could be probably solved on wPlatform with overriding WM_ERASEBKGND(just ret TRUE) if main Registered hBrushBack!=NULL.
Well, if you are using DHCtrl, you are sort of supposed to override
virtual LRESULT WindowProc(UINT message, WPARAM wParam, LPARAM lParam);
BTW, what is your reason to use DHCtrl?
Mirek
|
|
|
|
| Re: DHCtrl, Ctrl NoBackPaint ignored? [message #49855 is a reply to message #49843] |
Sun, 20 May 2018 09:09 |
luoganda
Messages: 205
Registered: November 2016
|
Experienced Member |
|
|
Ok, then for DHCtrl it must be overriden(it's more like a sort of wild western movie  ),
but what about regular Ctrl? i am not 100% sure, but i think it's the same(NoPaint,EXCLUDEPAINT ignored).
I am using DHCtrl so that native plugins(dll's) can be written, so this is a must.
2nd reason for using DHCtrl is that i can implement a buggy-less plugin through it,
because upp plugins(dll) are buggy, because usually upp dll's won't work out of the box(eg adding ScrollBars via dll error).
You already mentioned in one of the posts that USEMALLOC can be used to resolve heap alloc/free problems via dll's.
I doubt that this solves this kind of problems - because two different compilers(one for main app,one for dll)
will probably produce similar error. But there is a workaround - like passing dll's allocator to mainapp and using it.
Also - you mentioned that by using USEMALLOC will reduce speed. Hmm, then i probably won't use this - even if it works.
|
|
|
|
Goto Forum:
Current Time: Sat Nov 09 03:57:42 CET 2024
Total time taken to generate the page: 0.00470 seconds
|
Members
Pages
Help
Register
Login
Home
