C / C++ / MFC

Capturing Messages Application

16-Jan-07 11:51

bs1977 wrote:
Since I don't know the size of buffer and if I use _itoa_s then how do I handle "sizeInCharacters" ?

   Short answer - you cannot use _itoa_s(...) correctly or in good faith without knowing the amount of valid buffer space you are passing telling it to use. toxcct's response is the correct way to handle this problem, if you want to use _itoa_s(...), otherwise switch to the plain old itoa(...) function.

   Note that if you decide to change the function to accept the buffer size and you ever need to use Unicode or TCHAR code, be sure not to confuse the BYTE size of a buffer with its character size (sizeof( char ) == sizeof( BYTE ), but sizeof( wchar_t ) != sizeof( BYTE ) ).

   Peace!

-=- James
Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles

Revant Jain16-Jan-07 10:31

Revant Jain

16-Jan-07 10:31

Hello,

I am new to Win32API programming, Now is there a program that is available that will hook onto my program and basically tell me what messages are going into the message queue. It does not have to tell me all the messages but basic ones like WM_PAINT, WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_LBUTTONUP, etc.

Thanks

Re: Capturing Messages Application

David Crow16-Jan-07 10:40

Re: Problem with GetFocus()

16-Jan-07 10:40

It sounds like you want Spy++.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

Problem with GetFocus()

Jader8916-Jan-07 10:17

Jader89

16-Jan-07 10:17

My problem is that i have a timer that querys data via ethernet, once this data is returned, it populates some fields displayed on my dialog. BUT i want to have an if statement in there such that if the user is editing/has focus of a edit box, i dont want to overwrite what has been changed. At first look, i figured it would be easy, and just check to see if it has focus, but for some reason GetFocus() returns NULL... Any ideas on why its return this? Im using the standard MFC timing, e.g. SetTimer( UINT nID, UINT millisec, UINT Func_ptr/*i think, or something like that. I use NULL here*/ )

"There are 10 types of people, those who understand binary, and those who don't."
- Somebody, not me.

Mark Salsbery16-Jan-07 10:34

Mark Salsbery

16-Jan-07 10:34

I'm not sure why you'd get NULL for GetFocus(). I thought a regular timer would be notified
on the same thread as the window proc but maybe not. The only thing I can think of is GetFocus()
is being called on a different thread than the window was created on.

An alternative would be to track focus on the associated edit controls by watching the
EN_SETFOCUS/EN_KILLFOCUS notification messages.

Re: Problem with GetFocus()

Jader8916-Jan-07 10:59

Jader89

16-Jan-07 10:59

Wait, i had an epihany... I'm sorry, the reason it is 0, is cause it IS a different thread... I forgot that my timer just sends a message, and i have a constant listener which handles all messages... Which means of course it returns 0... Thanks for the initial thought, sorry for the bother

"There are 10 types of people, those who understand binary, and those who don't."
- Somebody, not me.

launch 2 exes with one.....

homerjaylol16-Jan-07 7:31

homerjaylol

16-Jan-07 7:31

ok this might sound a little n00bish of me, but im desperate.

does anyone know how to create a .exe, that when loaded, launches 2 other exes.

and when the launching exe closes, the 2 exes it opened close too.

if any of you could provide me with some sample source or anything, i would be forever greatfull.

thank you.

David Crow16-Jan-07 7:34

16-Jan-07 7:34

homerjaylol wrote:
does anyone know how to create a .exe, that when loaded, launches 2 other exes.

Such as calling CreateProcess() twice?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

toxcct16-Jan-07 8:03

toxcct

16-Jan-07 8:03

this answers the first part of the question (starting other exes)
the second part intends to close the programs previously started (in step 1) if our program shuts down

Don't know where to start ?
Refer the Forums Guidelines and ask a friend

[VisualCalc 3.0][Flags Beginner's Guide]

David Crow16-Jan-07 8:06

16-Jan-07 8:06

toxcct wrote:
this answers the first part of the question (starting other exes)

Which is all I intended to answer, hence the quoted text.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

toxcct16-Jan-07 8:10

toxcct

16-Jan-07 8:10

DavidCrow wrote:
Which is all I intended to answer, hence the quoted text.

oh,

hehehe, my bad David. Wink | ;)

Don't know where to start ?
Refer the Forums Guidelines and ask a friend

[VisualCalc 3.0][Flags Beginner's Guide]

James R. Twine16-Jan-07 8:03

16-Jan-07 8:03

   DavidCrow's suggestion works for launching the two applications. You can then get their handles, and you can keep checking the handles to see if either one (or both) of the child apps have closed.

   To implement the close the other two when I close functionality, you can create a Named Event object, and signal it when the launching (parent) application starts to shutdown. The two child apps can check that event to see when they should shut down, and the parent app can check the child app's handles to know when they have shutdown and it can then complete its shutdown (or terminate the child app if it gets hung up and does not close on its own).

   Peace!

#realJSOP16-Jan-07 8:36

#realJSOP

16-Jan-07 8:36

If you use CreateProcess to start the other apps, you can do this froim the OnClose override in CMainFrame...

// using SendMessage will cause the sending app to wait until the other app 
// responds to the message, thus signaling the calling app that it's okay 
// to shut close the handles.
SendMessage(m_hWndTelemetry, WM_CLOSE, 0, 0);
CloseHandle(processInfo.hProcess);
CloseHandle(processInfo.hThread);

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

James R. Twine16-Jan-07 8:45

16-Jan-07 8:45

   Closing the handles as shown will not cause the applications to shut down, so I am not sure that this was your intent, it simply releases the calling/parent app's "reference" to them, same as how closing a thread handle does not cause that thread to die immediately.

   I do not believe that your suggestion will allow the calling app to ensure that the child apps have closed - they can ignore the WM_CLOSE message, or otherwise return from handling it and still be running.

   Actually waiting for the handles to become signaled tells you when the apps have shut down (or, after a certain timeout, that they have not).

--- Edit: OK - you may have been specifically talking about how to cause the other two applications to initiate shutdown, as opposed to my suggestion of using an Event. Yes, that works as well, and is a bit simplier, but it should be mentioned that this only works for applications/processes that have a window and are pumping messages. And you still have to get the window handles for those child processes.

   Peace!

Thunks

Waldermort16-Jan-07 7:16

Waldermort

16-Jan-07 7:16

I'm getting closer to MFC each day D'Oh! | :doh:

I have now got into the habit of using thunks whenever a callback may be required within one of my classes. My code works perfectly, but only on Intel 32bit machines. I have placed exclusion guards around my template to prevent compiling for anything other than said machine, but now is the time to do it correctly.

This is my thunk:

struct THUNK
{
    m_mov     = 0xB9;  // mov to ecx this ptr
    m_this    = obj;
    m_jmp     = 0xE9;  // jmp to new address
    m_relproc = Cast<char*>(proc) - Cast<char*>(this) - sizeof(THUNK);
}

This allows me to thunk without casting the hWnd paramaters. What would the equivlent be for a 64bit machine?

Re: Thunks

James R. Twine16-Jan-07 7:28

Can I raise Exception in one thread and handle it in another?

16-Jan-07 7:28

   Not knowing that much about thunks anymore, my first guess would be to account for the pointer size and structure layout/padding differences (this goes from 32-bit to 64-bit, and the size of the structure may now lie on a different boundary), but other than that, nothing that I can think of.

   But I am no expert in the field of thunks... :P

   Peace!

chilituna16-Jan-07 6:51

chilituna

16-Jan-07 6:51

Hi,

I am a bit curious.. Can I raise exception (with RaiseException()?)
and get it handled in another thread??

This is needed for operation stop-functionality.
I thought it would be nice to have one dialog
where is stop button, and it stops whatever the
main thread is doing..

Does anybody know how it is done in Visual Studio?
It's possible to freeze the debugged process anytime,
when debugging.

Re: Can I raise Exception in one thread and handle it in another?

James R. Twine16-Jan-07 7:03

Re: Can I raise Exception in one thread and handle it in another?

16-Jan-07 7:03

I do not think that the exception will cross threads. I would suggest using a Win32 Event object, because it can be seen by multiple threads, and signal it in one thread to indicate the other to stop processing.

Peace!

David Crow16-Jan-07 7:33