|
|
nope that i don't want i don't want to show dialog noe model nor modeless.
is any way to recieve window message without showing the modelor modelless dialog boxes.
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
The message mechanism builds on HWNDs, so, for all practical purposes, no.
But there might be an alternative way, if you describe what you want to accomplish rather than how to accomplish it.
|
|
|
|
|
"first thanks for reply "
now let me explain my problem.
i am creating the window service(which is desktop interractive).i am also created Winlogon dll which notify me that some user is logged on or logged on the Work Station.
now problem arise to comuunicate between these two services i am using RegisterWindowMessage to pass information.
here the problem arise the Service can't receive a until dialog is displayed in case of modol dialog
and the in case of modelless dialog ,from wher i will get the desktop window pointer,without that it will not going to listen my registered message.
i think i have explained my problem
thanks,now any suggesstion
ps(socket create some problem in winlogon,so i can't use socket to sned or recieve message)
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
In this case, I would have tried a hidden modeless window. You normally don't need any pointers to the desktop window to get registered messages, why is that in your case?
|
|
|
|
|
first of all thanks for reply.
now back to problem:-
Yeah i tried that also but it not working.,i don't why the service not getting any registered messages.
thanks any way
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
First of all, you could try making a non-service application with a hidden, modeless main window - trying to send registered messages to it.
|
|
|
|
|
Oh my goodness YES. Always get as much functionality as possible working in a basic application, console, windowless whatever before integrating it into a service or COM component. For Services make sure you have logging working also.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
A nice side-effect is that you also quickly learn to write reusable code 
|
|
|
|
|
"Oh my goodness YES. Always get as much functionality as possible working in a basic application, console, windowless whatever before integrating it into a service or COM component. For Services make sure you have logging working also.
"
What logging,i can't understand what you quoted
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
sir with all due respect,
i have created a Non service Application.but when i try to send or post registered message ,it not handle by that application.
have you tried that your self(soory if that is rude)
thanks for concern shown by you to help me out
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Alok the programmer wrote:
have you tried that your self(soory if that is rude)
It's ok, I know I sound patronizing
I've sent, posted and broadcasted registered messages, WM_APP- and WM_USER-based messages to applications, windows and dialogs in every combination you might imagine, as well as some you wouldn't want to hear of.
You mention that you need a pointer to the desktop to receive messages, which makes me suspect that you either have some fundamental misconceptions about the message driven structure of Windows, or that you have some really unusual needs or structure of your application that you might need to explain.
So, what kind of non-service application did you create? How did you send/post/broadcast the message? Where and how did you try to handle it in the application? Inquiring minds needs to know
|
|
|
|
|
i created simple dialog based Application
if you want i will send you code of that application
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
The dialog-based application is only one part of the communication - how do you identify it when sending the message? It's quite enough if you start by posting the code registering and sending the message from the sender, and the code registering the message, the message handler and the message map entry here.
|
|
|
|
|
Again Sir With all Due respect
here you quoted "The dialog-based application is only one part of the communication - how do you identify it when sending the message? It's quite enough if you start by posting the code registering and sending the message from the sender, and the code registering the message, the message handler and the message map entry here"
My Answer to above
i have created Two Dialog Based Application and both register the Window message using Api's
UINT Message=::RegisterWindowMessage("alok");
and one application post message using either PostMessage or sendMessage Api's.
and other application is handlling the register message
ON_REGISTERED_MESSAGE()
ok
thanks
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Sir With All due respect.
you wrote" you could try making a non-service application with a hidden, modeless main window - trying to send registered messages to it."
yes i am created the application.but it's not receiving any registered message.
has you have tested that(soory if that sound rude)
thanks for reply
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Did you read my answer above? Yes, I have.
How are you sending the message? How do you identify the window you are sending it to? How are you trying to handle the message?
|
|
|
|
|
Sir,again with all due respect and thanks for taking concern for answering me again and again
now back to problem You have Quoted this
"How are you sending the message?"
Using both SendMessage And PostMessage apis
you quoted " How do you identify the window you are sending it to?"
what that's
you quoted " How are you trying to handle the message?"
Using MACRO in ON_RESTRIED_MESSAGE()
one note also,when i give it curent desktop pointer,it working fine in non service based application.
thanks
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Alok the programmer wrote:
you quoted " How do you identify the window you are sending it to?"
what that's
The window you send the message to. If you don't get this right, you'll of course never receive any messages in your application.
Now, for practicalities:
Create a dialog application called "Sender". Add a button and a button handler. In the button handler, add the following code:
void CSenderDlg::OnButton1()
{
HWND hwnd = ::FindWindow( _T( "#32770" ), _T( "Receiver" ) );
UINT hello = ::RegisterWindowMessage( _T( "TEST_MESSAGE" ) );
if( hwnd )
::PostMessage( hwnd, hello, 0, 0 );
}
You don't have to register the message everytime, and should use something more sensible as the id string. FindWindow is the interesting part here, it looks for a dialog (window class "#32770") with the title "Receiver".
Create another dialog application, called "Receiver". Either create it modeless, pumping messages yourself or a modal dialog. Let's start with a modal one (the default).
Register the message so:
UINT hello = ::RegisterWindowMessage( _T( "TEST_MESSAGE" ) );
Add a messsage map entry:
<pre
on_registered_message(="" hello,="" onhello="" )
<="" pre="">
Declare <code>OnHello </code>in the header:
<pre>
LRESULT OnHello( WPARAM, LPARAM );
Implement OnHello:
LRESULT CReceiverDlg::OnHello( WPARAM, LPARAM )
{
AfxMessageBox( _T( "Message received" ) );
return 0;
}
Now, start the application. Also start Sender. Press the button in Sender, and you'll see the message box pop up.
If you want it modeless, you must pump your own messages, use this in the application InitInstance:
CReceiverDlg dlg;
m_pMainWnd = &dlg;
dlg.Create( CReceiverDlg::IDD );
while ( PumpMessage() )
;
You'll also need to override OnCancel in the dialog class, calling DestroyWindow instead of the base class implementation.
Finally, make the window invisible. You'll now have to enumerate all the windows on the desktop, as you don't have the title to look for. You can also start by broadcasting the HWND from receiver as the application starts - and handle this message in Sender, this depends on the final structure of the application.
Alok the programmer wrote:
one note also,when i give it curent desktop pointer,it working fine in non service based application.
I can make no sense out of this, what are you giving the desktop window?
|
|
|
|
|
AGAIN SIR,WITH ALL DUE RESPECT
here is Come the problem
I am Broadcating the message using this Api command
<br />
UINT hello = ::RegisterWindowMessage( _T( "TEST_MESSAGE" ) );<br />
::PostMessage( HWND_BROADCAST, hello, 0, 0 );
ok,now i think you can understand the problem,also now tell me How i use to Findwindow() to find the dialog of my service.
till now our discussion is going great thanks
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Ah, finally, we are getting somewhere!
HWND_BROADCAST is something that should be used with some care - all windows receive it and you must make sure that the registered message does not conflict with any other messages in the system (that is, someoneelse has registered the same message). It will, however, not make any difference for the receive mechanism. Do the steps I outlined, replace the PostMessage with our own broadcast, and you will see the message box, the message is received.
You find the window the way I showed - by calling FindWindow. Enter the class of the dialog (normally #32770, use Spy++ to get the class of your dialog) and the title.
|
|
|
|
|
Johan Rosengren wrote:
You find the window the way I showed - by calling FindWindow. Enter the class of the dialog (normally #32770, use Spy++ to get the class of your dialog) and the title.
BUT AGAIN A BIG PROBLEM HOW TO GET CLASS OF DIALOG WHICH IS NOT VISBLE,IS SERVICE WITH HELP OF SPY++
THANKS AGAIN,I THINK THIS DICUSSION IS ENRICHING OUR KNOWLEDGE
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Tsk, tsk, Alok, you are kidding me
Make it visible, then. It will only be to get the class name - so it need not be permanent. Or call GetClassName in the code somewhere along with a convenient breakpoint. Or test any dialog box, they all have the same class!
|
|
|
|
|
Johan Rosengren wrote:
Make it visible, then. It will only be to get the class name - so it need not be permanent. Or call GetClassName in the code somewhere along with a convenient breakpoint. Or test any dialog box, they all have the same class!
now again with all due respect,
let go back i have told you i am creating a service ok.now if i show the dialog box of service it will shown after the login ok.
now what the problem is winlogindll(that is creted by me have to post the message ok) now how will it find the Classname .
i think now you understand my problem better,thank for nice and polite long disscusion.
it very nice to meet a intelligent guy like you,hat off
-----------------------------
"I Think It will Work"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
Alok,
Alok the programmer wrote:
now what the problem is winlogindll(that is creted by me have to post the message ok) now how will it find the Classname .
It's no matter if you hide a window, if you move the class and display it in another application, or whatever you do, the class name will always be the same. The class name (now I mean class in the Windows sense, not a C++-class) will in fact be the same for all dialogs in the system. This is normally "#32770" for a dialog, something that you can verify with Spy++ on your system. You can also move your dialog to a normal application, and add a call to ::GetClassName. The name will be the same if you use the dialog in another application, from a DLL, a service, or whatever, so the result of that experiment will be valid for the "real" code as well.
You must have a window if you are going to send, post or broadcast a message. It does not matter the kind of application, or if it is a DLL, a control panel applet or whatever. To reiterate: to handle a registered message, you must have a window.
I have shown how to find a window, given the general dialog class "#32770" and the title of the dialog. I've also mentioned EnumWindows and EnumChildWindows as a way of getting invisible windows - it's also of use if you are not sure of the title (such as if you have a dialog that will be translated to different languages) or if the window you are trying to find for some reason will not have the normal dialog class (in the case where, for example AfxRegisterClass has been used to register the window class - now note that I mean class in the Windows sense again, not C++-class).
I've also stated - and I repeat this - that you should try to get the registered message to work in a normal application (or rather two, one that sends and one that handles it). Have you succeeded in this? If so, you'll just have to move the code to the designated modules, and it should work. Don't get stuck on services, login etc., get the message to work first.
Alok the programmer wrote:
i think now you understand my problem better,thank for nice and polite long disscusion.
it very nice to meet a intelligent guy like you,hat off
But we are getting a little bit strained, both of us
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
