|
Just call SetLastError(0); by starting of you process.
Set a breakpoint there and then - by stopping -
take the "Go to Disassembly" from the context menu...
Now - step by F10 to "call", then - F11 to "jmp", then - F11 to "mov".
Set your second breakpoint here to keep all calls of SetLastError(..)
and press F5 to get it 
|
|
|
|
|
Thanks for the responses. I managed to find a breakpoint for some function that releases memory. Need to brush up on my assembly perhaps? 
Not quite what I asked, however a chap at work suggested typing $err into the watch window, this dispays the current value of GetLastError so I can step through code seeing where it changes.
|
|
|
|
|
I am confused by reading many articles.
Can any one tell me how many message queues are there in dialog based application.
Are there separate message queues for each window or each thread has its own message queue.
|
|
|
|
|
sharda.bhagwatkar wrote: Can any one tell me how many message queues are there in dialog based application.
Are there separate message queues for each window or each thread has its own message queue.
A dialog based application has one message queue.
A thread has its own message queue, if it's an UI thread. As a result, a window can have more than one message queue, if it has multiple UI threads running within.
sharda.bhagwatkar wrote: I am confused by reading many articles.
Read this: UI Threads explained by Dr. Joseph Newcomer[^]
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi Rajesh,
Hope you're good and having fun! 
I got a little confused when I read your post....
Rajesh R Subramanian wrote: As a result, a window can have more than one message queue, if it has multiple UI threads running within.
Ummm...
Not really sure what you mean here, but to my knowledge a window is only served by one message queue and pump in the sense that messages sent to the window will be queued in the message queue that belongs to the thread that created the window in the first place.
On the other hand, you may of course spawn new UI-threads from your "window" and create new windows in the newly created thread.
Or, do you really mean that messages sent to a window may end up in different threads/queues?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi Roger,
Yep, I'm good. Thanks. How's it going for you?
Roger Stoltz wrote: a window is only served by one message queue and pump in the sense that messages sent to the window will be queued in the message queue that belongs to the thread that created the window in the first place.
I said a Window (the program) can have more than one Message Queue running, simply by creating UI threads within. These message queues need not necessarily have anything to do with the message queue of the application window itself (to which all the messages are posted from the outside world). When I need a queued event dispatching mechanism, I can create UI threads.
Roger Stoltz wrote: On the other hand, you may of course spawn new UI-threads from your "window" and create new windows in the newly created thread.
I think that the term "UI thread" is horribly misleading, as a UI thread need not have a UI associated with it at all! I can have UI threads running around without associating any of those to a window.
Roger Stoltz wrote: Or, do you really mean that messages sent to a window may end up in different threads/queues?
I can of course re-route the messages internally if I have additional UI threads running within.
Example: A server program that I wrote, when it receives requests to compress rendered output videos, it just routes the message to a slave (an "ui" thread) and returns. The slave would automatically process the requests in a FIFO basis. The compression need not be done urgently, so I avoid additional threads, and at the same time, eventually every request will be processed sooner or later.
I'm not sure I got your queries right; let me know if I've been unclear somewhere.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Thanks for the replies and articles.
This is my understanding
1. device driver for the mouse or keyboard converts the input into messages and places them in the system message queue
2. The system removes the messages, one at a time, from the system message queue and then posts them to the message queue of the thread that created the destination window. e.g. in dialog based application it is a message queue associated with CWinThread (main thread) which has its message loop also.
3. Hence the message queue and message loop are associated with Thread not the window.
4. When UI thread is created inside the application, intially it does have message queue and message loop, but when some message is posted it creates the message queue and message loop on demand.
I still have one more query here. What will happen in case when modal dialog is launch on some button click of dialog based application and how will be the case with modeless dialog boxe.
|
|
|
|
|
Yeah, I'm good too.
Looks like I've just been assigned to something that looks very promising and may last for at least this year. So I'm happy.
Rajesh R Subramanian wrote: I'm not sure I got your queries right; let me know if I've been unclear somewhere.
Ohhh, now you're asking for it my friend...
Rajesh R Subramanian wrote: I said a Window (the program) can have more than one Message Queue running
I think this adds to the confusion. It looks like you're saying that a window is a program and of course it's not.
To my understanding the question was never about whether an application can have more than one thread that has a message queue, or if an application may have multiple message queues.
I interpret the OP's question in short terms as "does the message queue belong to a thread or a window" and the correct answer for that in equally short terms can only be "the thread".
Rajesh R Subramanian wrote: I think that the term "UI thread" is horribly misleading, as a UI thread need not have a UI associated with it at all!
Agreed at least a 100%!
The concept of "UI-thread" only makes sense as it is necessary to process messages when GUI objects are created in the thread.
Rajesh R Subramanian wrote: I can of course re-route the messages internally if I have additional UI threads running within.
Yep, that's possible. But that's more related to ::PostThreadMessage() than window objects.
Never mind, it's beside the point.
I think the essential part of my point is that a window will only receive messages in the message queue that belongs to the thread that created the window.
We can look at it this way:
You send messages to windows by calling either ::SendMessage() or ::PostMessage(). They both need a window handle as argument.
The window retrieves the messages sent to it by calling e.g. ::GetMessage(), which also needs a window handle. The point I'm trying to make can be found in the documentation for ::GetMessage() that says "the window must belong to the calling thread".
This means that a UI-thread can only have one message queue and since a window can only belong to one thread, it can only have one message queue where messages sent to the window will be put.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Rajesh R Subramanian wrote:
I said a Window (the program) can have more than one Message Queue running
I think this adds to the confusion. It looks like you're saying that a window is a program and of course it's not.
I took the simplest example - a dialog application, where there's just one message queue and that holds the messages posted to that very window by the outside world.
Roger Stoltz wrote: I interpret the OP's question in short terms as "does the message queue belong to a thread or a window" and the correct answer for that in equally short terms can only be "the thread".
Which I mentioned as well, only with added information that there could be additional message queues without windows associated to them.
I reckon we both have a way with our words, and we always get into discussions only to settle on the same boat after a while; saying: Oh yeah? You meant *that*. Right! Fun thing, if you ask me.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
sharda.bhagwatkar wrote: Are there separate message queues for each window or each thread has its own message queue.
A window does not have a message queue of its own. Multiple windows may be served by the message queue and message pump in the User Interface thread that the windows are created from.
In e.g. a simple dialog-based application there is initially only one thread and even if you create new windows, they will be served by the message queue in that thread. Keep in mind that all those small buttons and other controls are windows as well.
Every thread spawned is initially without a message queue. There are two kind of threads: worker threads and User Interface threads. Worker threads won't have a message queue, but UI-threads will get a message queue created when a message is sent, or posted, to the thread.
Read more about it in this small section[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
As Rajesh mentioned, message queue is associated with the thread. Not with the window.
|
|
|
|
|
i am working with an MFC application which handles images using an imaging library.
the application works fine for any image operation with small size images but for large size images, the application crashes.
if i try to debug in the visual studio 2008 then the application breaks with an heap corrupt message:
Heap block at 062E0E18 modified at 062FF378 past requested size of 1e558
Windows has triggered a breakpoint.
i tried for handling the exception using CMemoryException but it doesnt throw this kind so i am catching it this way:
try
{
}
catch(...)
{
}
now in the catch block i want to know the kind of exception which caused the problem.
is there a way to know this?
thanks
|
|
|
|
|
| Whether memory allocation of huge size taking place inside the try block? Величие не Бога может быть недооценена.
|
|
|
|
|
| One of the problems with this issue is that you have a memory leak in your code that is possibly not diagnosed until some time after the event. This means that even if you catch this exception it may only tell you what you see above: the heap is corrupt. You have allocated a buffer of 1E558 bytes (124248 decimal) but written in the heap somewhere beyond the end. You probably need to trace through your code as you load and process the image to ensue your index values are not corrupt. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
|
hai,
I want to create an application which will run 24 hrs a day & it should call a fn in every x minutes.
|
|
|
|
|
You can use a timer to do that.
|
|
|
|
|
Hello,
How can i access class member variable directly without creating object of that class.
I think there are two way, one way is declaring member variable as static.
What is the other way to access it?Abhijit
|
|
|
|
|
Abhijit D. Babar wrote: I think there are two way, one way is declaring member variable as static.
What is the other way to access it?
There isn't another way.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
learn about the class concept. A member makes only sence if have an instance. 
if it is a global values (as computer name) use a static variable.Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Hello,
Why MFC application create two resource file ".rc" and ".rc2" or What is the difference between .rc and .rc2 files.
.rc2 file does not contain anything, then why it use or created by MFC.Abhijit
|
|
|
|
|
In the *.rc2 file it is said:
#ifdef APSTUDIO_INVOKED
#error this file is not editable by Microsoft Visual C++
#endif //APSTUDIO_INVOKED
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Ok, it is having something in file, but what is use of that.
What it indicates.Abhijit
|
|
|
|
|
Take a look on documentation[^]Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
| you can include resources, which will not be editable in the Resource editor of the VS. Interesting for constant stuff as error messages or data as images. Press F1 for help or google it.
Greetings from Germany
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
