|
Derek Lakin wrote:
I've tried extending the CButton class and handling either WM_PAINT or WM_ERASBKGND or WM_CTLCOLOR or WM_CTLCOLOR_REFLECT, but none of the handler's got called
Sounds strange. While there are some problems with WM_CTLCOLORBTN and push buttons, your WM_ERASEBKGND and WM_PAINT handlers should be called without problems.
You may have a look at May'97 issue of MSJ - in the C++ QA column there's a discussion about providing custom backgrounds for CFormView-derived classes.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Thanks Tom, I'll look into it
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Thanks Tom. THe problem was I hadn't added the relevant DDX_Control calls
The required handler was for WM_CTLCOLOR_REFLECT.
Derek Lakin.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Hello All,
How is it possible to add a ToolTip to a StaticText or an EditBox?
|
|
|
|
|
Hello All,
How is it possible to add a ToolTip to a StaticText or an EditBox?
SAS
|
|
|
|
|
Assuming that your controls are hosted in modal dialog, check KB article Q141758 HOWTO: How to Add Tooltips for Controls to an MFC Modal Dialog Box
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
|
The control needs a unique id and the SS_NOTIFY style set for it to have a tooltip.
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
A fool jabbers, while a wise man listens. But is he so wise to listen to the fool?
|
|
|
|
|
hi:
how to get the URL form the internet shortcut (the file in c:\windwos\history)?
I get the file name of the intetnet shortcut (the file in c:\windwos\history) through ISHellFolder,I think the filename is correct,because I can get the icon of the intetnet shortcut with the filename.but how can I get its tatget URL with this filename?
thanks;
benben
|
|
|
|
|
once you get the file, the structure is like an .ini file:
[InternetShortcut]
URL=http://www.amazon.com
Hope this helps.
|
|
|
|
|
Our Purpose is to Launch an application , once launched and when closed by the user it performs the task that we want that application to.
but if Terminate that application by TerminateProcess() , since its a abnormal closing , it does not perform what it should perform on a Gracefull exit.
Now what I was thinking of is , If we could some how get HWND of this Process which we have created by CreateProcess() , then we could send WM_QUIT to this Hwnd , which would then do the task Grace fully, see what I am saying .
Now problem is how to get this Damn HWND ..
Help !!
Abhishek Narula
"Learn to appreciate others ... World would appreciate you"
|
|
|
|
|
|
I feel embarassed
This is indeed the right solution.
Ignore my post please [which is the most round about way to do this ]
Nish
Bow wow wow,
Yippee yo yippee yay,
My miniputt high,
Is now 30 yay.
|
|
|
|
|
Use EnumWindows to enumerate all top level windows.
For each HWND do a GetWindowThreadProcessId to get the thread ID. Now compare with the dwThreadId you got from your PROCESS_INFORMATION struct that you passed to CreateProcess. If they match post a WM_CLOSE to that window
Nish
Bow wow wow,
Yippee yo yippee yay,
My miniputt high,
Is now 30 yay.
|
|
|
|
|
I try to destroy a modal dialog box on exiting a MFC application.
To do this, i use DestroyWindow on the dialog window's handle; as a result it allways generates a runtime error.
If you know how to handle it, please let me know.
rechi
|
|
|
|
|
I reckon the problem is it's trying to destroy it after you've already done so. If it's a modal dialog, it must be the main one, right ? The framework deals with this for you.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
No, it's not the main one; on debugging the problem seems to be a WM_KICKIDLE SendMessage for the - indeed - destroyed window's handle.
Unfortunately, i can't let the framework to do the job for me; i really have to destroy it "by hand".
rechi
|
|
|
|
|
For modal dialogs I think you must call EndDialog and not DestroyWindow
Nish
Bow wow wow,
Yippee yo yippee yay,
My miniputt high,
Is now 30 yay.
|
|
|
|
|
That's the answer (also for the modeless dialogs)!
Thanks.
rechi
|
|
|
|
|
bogdan_rechi wrote:
That's the answer (also for the modeless dialogs)!
Thanks.
For modeless dialogs don't call EndDialog. You must call DestroyWindow for modeless dialogs and EndDialog for modal dialogs
Nish
Bow wow wow,
Yippee yo yippee yay,
My miniputt high,
Is now 30 yay.
|
|
|
|
|
Is this true for HWNDs only? Because i call CDialog.EndDialog for modeless dialogs and it looks ok.
rechi
|
|
|
|
|
bogdan_rechi wrote:
Because i call CDialog.EndDialog for modeless dialogs and it looks ok.
EndDialog makes the dialog box invisible but does not actually destroy it. This won't have too many problems always. But sometimes, it will result in leaks. If you know what I mean
Nish
Bow wow wow,
Yippee yo yippee yay,
My miniputt high,
Is now 30 yay.
|
|
|
|
|
Ok. Now the problem is solved 100%.
Thanks.
rechi
|
|
|
|
|
When you create a Modal Dialog, windows creates its own message pump to handle the messages for your modal dialog. That means that the messages do not go through your message pump. MFC emmulates the modal message pump, but the effect is the same.
It is important that you call EndDialog for the modal dialog only, because it shuts down the modal message pump, and allows the execution to drop back into your normal application.
You need to call DestroyWindow on a modeless dialog because all that this window is, is a regular window created as a dialog class.
|
|
|
|
|
hello everybody!
huang chun shen
|
|
|
|