Re: Dialog as TopLevel window - C / C++ / MFC Discussion Boards

Stephen Hewitt1-Jun-06 23:22

1-Jun-06 23:22

This question is not clear. In COM interfaces can only be derived from one base class. IUnkown is an interface. Calculator clearly isn't a COM interface as it uses multiple inheritance. This suggests that this is an implementation hierarchy: Calculator is a C++ class that is using multiple inheritance to implement COM interfaces. It's still not clear what ADD and Multiply are. Their names suggest they are not interfaces. This question is too vague.

Steve

Re: COM Interview Question

Scorpio1-Jun-06 23:30

Scorpio

1-Jun-06 23:30

ADD and Multiply Are Interfaces

Re: COM Interview Question

Stephen Hewitt2-Jun-06 2:17

Stephen Hewitt

2-Jun-06 2:17

Then there is one implementation for each. This is how multiple inheritance works in C++.

Steve

Dialog as TopLevel window

mav.northwind1-Jun-06 22:45

mav.northwind

1-Jun-06 22:45

Hi!

Perhaps it's a silly question, but at the moment I'm really stumped:
I need a window to receive messages from a different application for synchronisation purpose.

In order to have an easy way of showing which messages were received, I've created a dialog (CDialog derived) with a ListBox to trace the messages.
Because I want to use SendMessage(HWND_BROADCAST,...) (and not explicitely find out the hWnd of my dialog), I'd have to make the dialog a TopLevel window.

Unfortunately, I've completely failed to achieve this so far. I thought creating the dialog without giving a parent window would create a TopLevel window, but obviously I was wrong - my SendMessage wasn't received and Spy shows a parent window for my dialog...

Can anyone please give me a little push in the right direction?

Regards,
mav

--
Black holes are the places where god divided by 0...

Re: Dialog as TopLevel window

Nibu babu thomas1-Jun-06 22:57

Nibu babu thomas

1-Jun-06 22:57

mav.northwind wrote:
Unfortunately, I've completely failed to achieve this so far. I thought creating the dialog without giving a parent window would create a TopLevel window, but obviously I was wrong - my SendMessage wasn't received and Spy shows a parent window for my dialog...

SetWindowPos(&wndTopMost, 0, 0, ....) creates a top most window. Is this what you want.

Nibu thomas
A Developer

Programming tips[^] My site[^]

Re: Dialog as TopLevel window

mav.northwind1-Jun-06 23:13

mav.northwind

1-Jun-06 23:13

Hi!
Thanks for your response, but this is not what I need.
I don't need the window to be top most (the dialog isn't visible at all in release mode), but TopLevel.
Only TopLevel windows receive messages sent with HWND_BROADCAST...

Regards,
mav

--
Black holes are the places where god divided by 0...

Re: Dialog as TopLevel window

Nibu babu thomas1-Jun-06 23:16

Nibu babu thomas

1-Jun-06 23:16

mav.northwind wrote:
but TopLevel.

All TopLevel windows have Desktop window as their parent. Use SetParent to set the parent to Desktop Window.

Nibu thomas
A Developer

Programming tips[^] My site[^]

Re: Dialog as TopLevel window

mav.northwind1-Jun-06 23:36

mav.northwind

1-Jun-06 23:36

Thanks, but that doesn't work either. I tried setting the parent to the desktop window but Spy++ still shows the main application's window as the parent.

I guess I'll opt for the own window class and FindWindow.

Regards,
mav

--
Black holes are the places where god divided by 0...

Re: Dialog as TopLevel window

Viorel.1-Jun-06 23:20

Viorel.

1-Jun-06 23:20

It seems that an MFC application cannot have more than one top-level windows. Therefore, the messages sent by SendMessage(HWND_BROADCAST,...) always reach the main application window instead of your dialog. (Information about how to extend MFC to support multiple top-level windows con be found at http://www.codeproject.com/docview/multitop.asp[^]).

As a possible solution of your problem, since you surely will process broadcasted messages in your main application doing main synchronization tasks, you can simply call there a member function of your debug dialog. (For instance, you can keep a pointer to your debug dialog, which should be null when the dialog is not displayed).

Hope this will help.

Re: Dialog as TopLevel window

mav.northwind1-Jun-06 23:30

mav.northwind

1-Jun-06 23:30

Hi and thanks alot!

It seems as if I have to say goodbye to my initial idea Sigh | :sigh:

. The dialog is part of a DLL that's being loaded by a third-party application I cannot influence.

Then I guess I'll try to give my dialog a special window class I can use in a FindWindow() from the external application and not use HWND_BROADCAST.

Regards,
mav

--
Black holes are the places where god divided by 0...

Re: Dialog as TopLevel window [modified]

mav.northwind2-Jun-06 0:04

mav.northwind

2-Jun-06 0:04

Unfortunately, my other idea (setting the class name of the dialog) doesn't work either, because PreCreateWindow (where the class name can be modified) doesn't get called for CDialog derived classes. Mad | :mad:

Is there anything else I can try?

Regards,
mav

--
Black holes are the places where god divided by 0...

-- modified at 5:21 Friday 2nd June, 2006

Although I don't really like the solution, I think I'll go for FindWindow with a special window title. That way I can at least find the dialog...
Thanks für the help.

Re: Dialog as TopLevel window [modified]

Viorel.2-Jun-06 0:41

Viorel.

2-Jun-06 0:41

If you just need a dialog box for simple passive spying of your broadcasted messages, I think you can try to create a separate dialog-based application. In this case the dialog window is expected to be the top-level one. You will be able to start this debugging dialog only when you need it, even if the main receiver application is stopped.

Re: Dialog as TopLevel window [modified]

mav.northwind2-Jun-06 6:31

mav.northwind

2-Jun-06 6:31

Thanks for the suggestion, but (as always) it's not as simple as that.
I have the dialog in my DLL because I need to raise events to the hosting application from within the same thread that loaded my DLL.
Some events I get come in via remoting from a different thread, so I have to "marshal" (big word for sending a message Smile | :)

) them to the other thread by sending a message to the dialog and have the dialog raise the event.
Now I not only have to send messages to the dialog from within the DLL (where I have access to the dialog's HWND), but from other applications as well. That's the whole reason for my problems...

Well, the constant window title at least works, so I think I'll have to use it for now until I find a better way.

Regards,
mav

--
Black holes are the places where god divided by 0...

Form's Button not responding

Y_Kaushik1-Jun-06 22:39

Y_Kaushik

1-Jun-06 22:39

Hai to all of you
i am new in VC++ and i have make a simple application But
one of the form of that application contain some error..........

Like Whenever i click any button of that form then MessageBox Generate a Message Could not add new member

Note: I have also write the code of button ,yet its not responding accordingly . i don't know where i am lacking

Plz Tell me.....

mailing me
Yogi

Re: Form's Button not responding

Hamid_RT1-Jun-06 23:35

Hamid_RT

1-Jun-06 23:35

can you show error message and you get this error only in this application or all projects

whitesky

Customize ColorDialog

velayudhan_raj1-Jun-06 22:21

velayudhan_raj

1-Jun-06 22:21

how to change the background color of a custom color dialog

Re: Customize ColorDialog

Hamid_RT1-Jun-06 22:37

Hamid_RT

1-Jun-06 22:37

of course its not a good way but maybe its some helpful to you

<br />
class CMyDialog: public CColorDialog<br />
{<br />
public: <br />
	DECLARE_DYNCREATE(CMyDialog)<br />
	CMyDialog();<br />
	~CMyDialog();<br />
	DECLARE_MESSAGE_MAP()<br />
<br />
	afx_msg HBRUSH OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor);<br />
};<br />
<br />
<br />
<br />
<br />
IMPLEMENT_DYNCREATE(CMyDialog, CColorDialog)<br />
<br />
BEGIN_MESSAGE_MAP(CMyDialog, CColorDialog)<br />
	ON_WM_CTLCOLOR()<br />
END_MESSAGE_MAP()<br />
<br />
CMyDialog::CMyDialog()<br />
{<br />
<br />
}<br />
<br />
CMyDialog::~CMyDialog()<br />
{<br />
}<br />
<br />
<br />
HBRUSH CMyDialog::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)<br />
{<br />
	HBRUSH hbr = CColorDialog::OnCtlColor(pDC, pWnd, nCtlColor);<br />
LOGBRUSH logBrush;<br />
logBrush.lbStyle = BS_HATCHED;<br />
logBrush.lbColor = RGB(100, 192, 192);<br />
logBrush.lbHatch = HS_CROSS;<br />
if(pWnd==this)<br />
SetWindowText("Test");<br />
return CreateBrushIndirect(&logBrush);<br />
}<br />

whitesky

Re: Customize ColorDialog

suja sreekumar2-Jun-06 0:31

suja sreekumar

2-Jun-06 0:31

is there any way to change the color of the buttons and the static texts??

Re: Customize ColorDialog

Hamid_RT2-Jun-06 2:08

Hamid_RT

2-Jun-06 2:08

See WM_CTLCOLORSTATIC

whitesky

User interface problem -- check a point is inside a polygon or not

George_George1-Jun-06 22:15

George_George

1-Jun-06 22:15

Hello everyone,

I have a UI application and I need to display context menu according to whether user clicks inside a polygon or not. So, I think I need to use some algorithms which can check whether a point is inside a polygon.

Does anyone have any ideas or reference materials?

thanks in advance,
George

Re: User interface problem -- check a point is inside a polygon or not

Stephen Hewitt1-Jun-06 22:20

Stephen Hewitt

1-Jun-06 22:20

Using Win32 this can be done using regions. Create a region in the shape of the polygon then use the PtInRegion function.

Steve

Re: User interface problem -- check a point is inside a polygon or not [modified]

George_George1-Jun-06 22:50

George_George

1-Jun-06 22:50

Thank you Steve,

Seems that you like using system internal functions other than implement them by yourself. Smile | :)

Actually, I think I need to implement the algorithm by myself -- a portable algorithm works for both Win32 and Linux. Any ideas or reference materials?

regards,
George

-- modified at 3:51 Friday 2nd June, 2006

Re: User interface problem -- check a point is inside a polygon or not [modified]

Cedric Moonen1-Jun-06 22:57

Cedric Moonen

1-Jun-06 22:57