|
You could try handling the WM_POWERBROADCAST message.
|
|
|
|
|
Hello,
Can anyone provide me some ideas or resources in order to read the .PSD file? I am more interest to know how can I read the layer information of in the .PSD file.
Thanks!
Nachi
|
|
|
|
|
Go here and search for the PSD format.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
is there a way to place a drop menu nexto and image
|
|
|
|
|
I have an MFC application that creates a WH_GETMESSAGE with a callback function in an external non-MFC DLL. It specifically monitors mouse and keyboard events. Event notifications are sent to my app with PostMessage from inside the DLL callback function. This in itself works perfectly. However, when I try to close the app, the app will crash or start to take up 100% cpu usage. If I right click the app in the task bar and choose close, I get 100% cpu usage, or if I then press 'C' for the 'Close' menu option, the app crashes. The X button will crash, double clicking the icon in the titlebar will exit without error, as will Alt-F4, and choosing Close from the system menu will crash.
It doesn't matter if I uninstall the hook in OnClose or not, because the DLL will cleanup on DLL_PROCESS_DETACH. I get the same result anyway.
I'm very confused, I have no idea what the problem is, its not consistant at all. I do know that if in the DLL I comment out the PostMessage lines in the event callback, there are no crashes or hangs at all. So I don't know if my app or dll is to blaim. Before the GetMesssage hook I had separate mouse and keyboard hooks, which didn't cause the CPU hang, but would occassionally crash.
Any suggestions?
Thanks!
-Aaron
modified 12-Jul-20 21:01pm.
|
|
|
|
|
Maybe the dll shouldn't notify the application in case the application was closing? (infinite loop?)
Try unloading the dll from the application first
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
The problem is I want the DLL running the entire time the app is, without some sort of stop button being requried.
I was wondering if there may be an infinite loop, and I think you're right, that that was the problem. What I did is add a conditional to my hook callback that would only postmessage if the orginator of the message was not my window. And that works great! I don't really need the messages to be posted while they're in my app anyway.
Thanks!
modified 12-Jul-20 21:01pm.
|
|
|
|
|
Aaron Stubbendieck wrote:
I have an MFC application that creates a WH_GETMESSAGE with a callback function in an external non-MFC DLL. It specifically monitors mouse and keyboard events. Event notifications are sent to my app with PostMessage from inside the DLL callback function.
Uh oh. That there is an infinite loop waiting to happen. Your app calls GetMessage(), which triggers your hook, which posts a message to your app, which calls GetMessage() to read it, which triggers your hook, which posts a message to your app...
See where that's gonna end up going? 
You'll have to find some other way of notifying your app - look at shared memory or some other inter-process communication; messages won't work in this case.
I can't really explain why some cases didn't cause the crash, although it may be due to the "feature" of WH_GETMESSAGE hooks where messages retrieved via GetMessage() are processed by the hook, but messages retrieved with PeekMessage() are not. I never really understood why this was the case, but it's possible PeekMessage() may be being used for some of those cases.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Yeah, I eventually worked around that by not posting the message if it was from my app, that's as clean of a solution I could come up with. The odd thing is, that except when closing the app, there was no problem.
Thanks for the help on this thread and the other.
modified 12-Jul-20 21:01pm.
|
|
|
|
|
how can I convert TCHAR to LPVOID
here the example what I have,
<br />
CString str = "HELLO"<br />
TCHAR k[512];<br />
wcscpy(k,(LPCTSTR)str);<br />
LPVOID lpmsg = k;<br />
could run without any problem, but lpmsg only contain only one character, which is 'H'
how can I store CString content to LPVOID or TCHAR to LPVOID.
Thankyou
|
|
|
|
|
Exactly like you did
If you want to see all the chars cast it back to a TCHAR*
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
I dont' want to see all the characters back
I need to send this message to another application.
I have two applications, let's named them app1 and app2. They used pipe to communicate. So
app1 needs to send the message to app2 and here what app1 did,
<br />
CString msg = "sample text";<br />
LPVOID lpvMessage;<br />
TCHAR chBuf[512]; <br />
wcscpy(chBuf,(LPCTSTR)msg);<br />
lpvMessage = chbuf;<br />
int k = strlen((const char*)lpvMessage);<br />
<br />
fSuccess = WriteFile( hPipe,lpvMessage,strlen((const char*)lpvMessage) + 1, &cbWritten,NULL); <br />
app2 gets the message sent by app1 but only the first character.
So what I need is app1 has CString conent and need to send that string to app2.
How can I send that string out to app2?
by the way, I'm using UNICODE
thank you
|
|
|
|
|
How much is strlen((const char*)lpvMessage)??
and how are you reading the data in app2?
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
strlen((const char*)lpvMessage) return 1
app2 reads as followed,
fSuccess = ReadFile( hPipe, chBuf,512,&cbRead, NULL);
chBuf only contains the first character of what app1 sent.
thank you
|
|
|
|
|
A tip:
wcscpy(chBuf,(LPCTSTR)msg);
+
int k = strlen((const char*)lpvMessage);
Krrrrrsh...
Would be the first time ANSI-routines would work for Unicode strings 
Instead of using strlen, use _tcslen. Also, you shouldn't use wcscpy, but _tcscpy.
For the WriteFile function, use the length returned by _tcslen and multiply this size with sizeof(TCHAR).
Best regards,
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
Yes.. k now get more than 1 length..
No.. app2 can't still read it.. it's all junk app2 got.
I don't know whether app1 sent the right information or it is just the converting?
<br />
LPVOID lpvMessage;<br />
TCHAR chbuf[512];<br />
_tcscpy(chbuf, (LPCTSTR)msg);<br />
lpvMessage = chbuf;<br />
int k =_tcslen((TCHAR*)lpvMessage);<br />
app1
<br />
fSuccess = WriteFile( hPipe,lpvMessage,_tcslen((TCHAR*)lpvMessage) *sizeof(TCHAR)+ 1, &cbWritten,NULL); <br />
app2
<br />
fSuccess = ReadFile( hPipe, chBuf,512,&cbRead, NULL);<br />
|
|
|
|
|
I suspect using LPVOID in app1 is the cause of the problem. Even though the second parameter of WriteFile() is a LPCVOID, this would be acceptible:
TCHAR chBuf[512];
_tcscpy(chBuf, msg);
WriteFile(hPipe, chBuf, _tcslen(chBuf) * sizeof(TCHAR), &cbWritten, NULL);
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
No.. app2 still get the first letter o ftf whatever pap1 sent
is app2 might aslo has the problem? app2 doesnt' use unicode as app1.
<br />
fSuccess = ReadFile( hPipe, chBuf,512,&cbRead, NULL);<br />
thank you
|
|
|
|
|
pnpfriend wrote:
app2 still get the first letter...
How are you verifying this? In the Watch window, look at:
chBuf[0]
chBuf[1]
chBuf[2]
chBuf[3]
chBuf[4]
Or you might could try chBuf,su since it is a UNICODE string.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I found out that
chBuf[0]=H,
chBuf[1]=0
chBuf[2]=E
chBuf[3]=0
chBuf[4]=L
chBuf[5]=0
chBuf[6]=L
chBuf[7]=0
chBuf[8]=O
why the characters are store in every other buffer?
Is it because of UNICODE? why UNICODE string does that?
thank you
|
|
|
|
|
pnpfriend wrote:
why the characters are store in every other buffer?
Is it because of UNICODE? why UNICODE string does that?
That's what UNICODE is. Perhaps you need an introduction.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Is it possible the way app2 reads
<br />
CHAR chRequest[BUFSIZE]; <br />
fSuccess = ReadFile( hPipe, chRequest,BUFSIZE,&cbRead, NULL);<br />
<br />
app2 is not using UNICODE, so it is not really neccessary to use TCHAR, isn't it?
|
|
|
|
|
|
Thank you all for your advises..
I had changed wcscpy() to _tcscpy() to send the message from app1 to app2,
app2 seems like only got the first character of the message from app1 but as Davide Crow suggested, I wrote a function that checked every single character of the message and found out that message char was store in every other index in the array. for example, H0E0L0L0O
<br />
void App2::GetReqStr(TCHAR* str, DWORD bufSize)<br />
{<br />
TCHAR temp[BUFSIZE];<br />
int j=0;<br />
for (int i=0;i<bufSize;i++)<br />
{<br />
if(str[i] != 0)<br />
{<br />
temp[j]=str[i];<br />
j++;<br />
}<br />
}<br />
_tcscpy(str,temp);<br />
str[j]=NULL;<br />
}<br />
So App2 gets the message what app1 sent, but the problem is that app1 is not getting the same message what App2 sent back.
for example, App2 gets message "Hello" from app1 and app2 send "YES" to app1 back. however, using the following same methods, ReadFile() and WriteFile(), and app1 got junk messages from app2. Why is that??? it is driving me crazy. I cant' find the errors.. why I dont' get the same message that is sent by app2???????? 
<br />
CString msg = "HELLO";
<br />
TCHAR chBuf[BUFSIZE];<br />
_tcscpy(chBuf,msg);<br />
fSuccess = ReadFile( hPipe, chBuf,BUFSIZE,&cbRead, NULL);
<br />
fSuccess = WriteFile( hPipe,chBuf,_tcslen(chBuf)*sizeof(TCHAR*),&cbWritten,NULL);
<br />
|
|
|
|
|
If one program is UNICODE and the other is ANSI, then you have to decide on your protocol.
I see you have two choices:
1. App1 SENDS Unicode and App2 CONVERT the Unicode to ANSI. If App1 RECEIVES a message from App2, then App1 must conver the Ansi sent by App2 back to Unicode.
2. App1 CONVERTS Unicode to ANSI and sends ANSI to App2. If App1 RECEIVES a message from App2, then App1 must converts the Ansi back to Unicode.
You need to investigate WideCharToMultiByte (UNICODE to ANSI) and MuliByteToWideChar (ANSI to UNICODE) string conversion functions.
Also, you might want to SEND the NUL terminator along with your string, although it is not strivtly necessary as long as you add one at the receiving end.
fSuccess = WriteFile( hPipe, chBuf, (_tcslen(chBuf) + 1) * sizeof(TCHAR), &cbWritten, NULL);
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
