|
I would guess the answer is the code of the main MFC message loop
led mike
|
|
|
|
|
hehe yeah I just can't find it. Thankfully I'm unwilling to try any further because it's never
going to be an issue that affects ME, and I'm selfish like that LOL
Cheers man!
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Moral: PreTranslateMessage() is a bad place to do message boxes from
That's a given. I wonder if the issue has anything to do with the message box being a modeless dialog in disguise.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I couldn't get that far to find out. I was unable to step into the source code for
the innards of the AfxMessageBox on VS 2008 (the trail ended at a call to an imported library
function which wasn't debuggable), so I couldn't even see what "modal" loop it was using.
That's why I was unable to find where that second message gets eaten.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark and Mike.
FYI check
Microsoft Systems Journal June 1996
There is some info on modal dialogs message behavior which may explain things.
PS I am still working on my solution to this dilema. Making some progress.
Vaclav
|
|
|
|
|
Hey guys,
I have an application where I need to keep the UI responsive while background tasks are running.
I currently have worker thread that does a PostMessage to a handler that does my GDI drawing, but the problem is that if too many things are happening the message pump gets held up and therefor my UI drawing is not smooth at times. If there was some way I could just do my GDI or GDI+ drawing directly from the worker thread I know that would solve my problems and my UI would be responsive.
Is there anyway I can do my drawing directly from a woker thread safely using either GDI, GDI+, or even DirectX? any way at all?
|
|
|
|
|
You can do your drawing into off screen buffers in the worker thread then signal the main thread to update the display and all it has to do is draw the buffer(s) making it much faster. But you haven't indicated what you are actually doing so I don't know if that is helpful.
led mike
|
|
|
|
|
Oh cool, so I can actually safely use GDI calls to draw on an offscreen device context from directly within the thread so long as I dont do anything with an actual windows control? Then just update the actual windows control from the main thread?
modified on Wednesday, February 27, 2008 11:41 AM
|
|
|
|
|
Greg Ellis wrote: so I can actually safely use GDI calls to draw on the device context from directly within the thread
Safely? Not without synchronization. You have to insure the user can't do anything to cause
GDI ops - like dragging a window across your windows, etc.
It is possible, but safely takes some work
If you use regular thread synchronization to control all thread access to GDI then it will work pretty well.
I've been doing it for a lot of years, including rendering video and graphics on windows of another process, and I've not
seen or heard of any problems yet.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have the following declaration in my code;
struct DTC{<br />
TCHAR *Code;<br />
TCHAR *Description;<br />
TCHAR *Defined;<br />
int nDefined;<br />
int nIndex;<br />
};<br />
<br />
struct DTC DTCodes[0x4000];<br />
The declaratiom appears before the code using the struct, I am reading a file into the array, it seems that as my file size grows my debugger gives me the following error message.
Breakpoint Found in Code + Address 0x7c901230.
I have verified there are no breakpoint set, my debugger usually stops at the line that is marked as a breakpoit.
I am using Lcc-Win32.
I think my problem is memory allocation, so I need to know how properly allocate memory for an array, the allocation must allow for expansion.
Thank in advance for your help.
|
|
|
|
|
You're allocating statically the array hence it can't grow. You need to dynamically allocate memory, have a look at malloc and free documentation.
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
|
|
|
|
|
Wow! that was fast, god I love this site.
The file I am reading contains 2632 records, I allocated 0x4000 in anticapation of future expansion. My debugger is acting weird, and my first inclination is I am overwritting code with data, although the program seems to work OK in the runtime. I will investigate using malloc.
Thanks
|
|
|
|
|
jonsey29847 wrote: so I need to know how properly allocate memory for an array, the allocation must allow for expansion.
I agree. Is this a school project? If so the text provided should cover both of those aspects.
led mike
|
|
|
|
|
Thanks for fast reply, I will try to use malloc. This is not a school project, it is a keep this old brain working project, I am learning C programming and Win32APIs in my off time.
Thanks
|
|
|
|
|
jonsey29847 wrote: I am learning C programming and Win32APIs in my off time.
How? I mean what learning materials are you using? Did you check out the Book Review Section and Tutorials here on CodeProject?
led mike
|
|
|
|
|
I have early experience with Turbo C, I have read a few books, I travel a lot so carrying reference books is almost out of the question, I really need a a good Win32 book (Peitzold?) electronically would be ideal. I have checked out the tutorials section, the confusion I seem to have here is allocating memory for a struct. I have found this site to be particularly valuable as I get quick replys and for the most part I can work things through once I have an idea what I need to do.
I am working on a application to communicate with the OBDII controllers in an automobile, I am on V3 (alpha?) if that tells you anything.
The first computer I programed was an IBM 1620 using Fortran II.
I loved assembly, but finally faced up to using C, I will tackle OOP (C++) next.
Tom
|
|
|
|
|
jonsey29847 wrote: I really need a a good Win32 book (Peitzold?)
I learned Windows 3.? from Petzold book. It certainly covered the fundamental topics. I have not read his Win32 book, when I started Win32 development I just used the SDK books.
jonsey29847 wrote: the confusion I seem to have here is allocating memory for a struct.
That's not really a specific topic. Depending on the definition of the struct the allocation issues can be quite different.
IMHO here is a short list of C/C++ issues that one needs a firm grasp of before continuing with the language.
* Heap vs Stack memory
* Memory Addressing / Pointers / Arrays
* Memory allocation and freeing
* Initialization of memory and ramifications of not initializing memory.
* Function execution, i.e., pushing the parameters onto the stack and then jumping and how they return
led mike
|
|
|
|
|
led mike wrote: That's not really a specific topic. Depending on the definition of the struct the allocation issues can be quite different.
Can you cite some examples, my struct is simple 3 pointers to TCHARs and 2 ints.
led mike wrote: * Heap vs Stack memory
* Memory Addressing / Pointers / Arrays
* Memory allocation and freeing
* Initialization of memory and ramifications of not initializing memory.
* Function execution, i.e., pushing the parameters onto the stack and then jumping and how they return
My score is about 3 for 5 here, I think I am getting a lesson on Heap/Stack and Allocation and freeing.
Tom
|
|
|
|
|
jonsey29847 wrote: my struct is simple 3 pointers to TCHARs
That is a perfect example of "not simple".
TCHAR * is an address in memory to a block of TCHAR where the length of the block is undefined in your structure, which Mark Salsbery has pointed out.
Therefore when you allocate the memory for the struct on the stack only the 4 byte address member is allocated, not the space you need to hold the string you want that to point to.
Even if you calculate the space required and allocate on the heap you still don't have the memory structure you think you do in the struct and you would have to use math to address the starting points in memory to all the space you allocated for those strings. That is not advisable or Best Practice by the way.
jonsey29847 wrote: My score is about 3 for 5 here
It's possible you may not have accurately assessed your situation.
led mike
|
|
|
|
|
led mike wrote: It's possible you may not have accurately assessed your situation.
It would not be the first time, nor I expect the last.
It seems the deeper I get into this the greater the complexity.
Ah, well...
Tom
|
|
|
|
|
led mike,
This is what I have taken away from all this;
1. An array does not have to reside in contigous memory, thus I was not corrupting the code, I found something interesting that was causing the apparent (debug only) problem, and a bug in my code.
2. As each element of an array is initialized the operating system will take care of pointer offsets. Duh?
3. In the function that reads the file and populates the array I am using LocalAlloc(LPTR, MaxSize) to initialize intermeadiate variables to hold the data as it is read. I am reinitializing theses variables by using the strcpy function to copy an empty string into the variable. My thinking is that the best practice would be to use ZeroMemory to to reinitialize, this should cover the possiblity of random data causing some kind of problem.
Last night I purchased Petzolds book from Amazon, and I have online access to it neat eh, I have already learned a few neat tricks that I can't wait to use.
Thanks for your help.
|
|
|
|
|
Modified: My answer doesn't allow for expansion.
Doing some sums...
0x4000 = 16384.
x 40 (5 things, at 8 byte spacing) = 655360 = 0.6Mb.
Allocating it as you did, puts the array on the stack - which can only cope with a small (in the grand scheme) amount of memory.
Possible your stack is getting corrupted.
1/ Make sure your memory access is only using the allocated memory.
2/ Try allocating the memory on the heap:
DTC *DTCodes = new DTCodes [0x4000];
...
DTCodes [97].nIndex = 77;
...
delete [] DTCodes;
Good luck,
Iain.
Iain Clarke appearing in spite of being begged not to by CPallini.
|
|
|
|
|
Hey Iain what machine/compiler have you?
sizeof(DTC) gives 20 on my system.
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
|
|
|
|
|
I was pulling numbers out of mid-air. And I wasn't sure if packing would be a problem. 8byte packing, x 5 thingies = 40.
It also made the numbers bigger to illustrate the issue.
If people assume I do vast research to answer their questions, they're baaaaadly mistaken.
(OK, occasionally they're right - the whole shortcut path name in a shell extension question a few days ago tickled my curiosity and stubbornness)
Iain.
Iain Clarke appearing in spite of being begged not to by CPallini.
|
|
|
|
|
Thanks, your answer is just what I was looking for, I will try new.
|
|
|
|