|
Iain,
Thanks for your remarks. I do not think that the postmessage is the problem either, since I see the results of processing the message which has obviously been sent and processed. The crash occurs somwhere later.
I do not use the HWND of the modeless dialog box at all. I use the HWND of the parent dialog, which remains active all the time. This is the window that has to process the message (write changes to a file and update the list control).
I tried to keep the modeless dialog box in existence (using ShowWindow (SW_HIDE) rather than DestroyWindow. I still send the message before hiding the window, with exactly the same result: BANGGG!!
I did try to debug the darned thing, but then it behaves like an angel. No crashes, however often I enter and destro the subwindows.....
I also found out that it does not matter if I enter the same modeless dialog box twice, or if I enter one and then another. The second OK will make the system crash (in the release version)
William
|
|
|
|
|
Thanks all for your replies. I think I found the problem. There was an issue with the prototype of the message handler function. When I corrected this, the problem had disappeared.
Regards,
William
|
|
|
|
|
You're not allowed to fix the problem yourself! I just read your message in my email, and went "aha! this sounds exactly like the problem I had 9 years ago, with MFC blindly casting the prototype..."
This ended up with stack corruption, and a crash that was very difficult to pin down. And didn't show up in debug mode with its extra padding.
Now you've ruined my chance to show off through your self reliance!
Curses,
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
I deeply and humbly apologize. I hope you can forgive my inexcusable violation of this esteemed forum's practices. I have already put ashes on my head and will refrain from all pleasures of the flesh for the coming week or so........
Greetings,
William
|
|
|
|
|
William Engberts wrote: will refrain from all pleasures of the flesh for the coming week or so
Whoah there! I grant you an indulgence to eat as much chocolate as you like this easter weekend. I don't mind if you're not from a christian heritage country or not - it's still a good excuse.
/forgive,
Iain.
Iain Clarke appears because CPallini still cares.
|
|
|
|
|
he he he nice quote
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
Perhaps you don't really want to "destroy" the children windows if you are going to use them more than once. Better solution might be to create all child windows once (upon start up of main window) and intialize them hidden. Then when you need them you can just hide and show them - this would eliminate unnecessary memory allocation/de-allocation. If you need to reset each child window, you could just call that before the ShowWindow( SW_SHOW ).
Just a thought. 
|
|
|
|
|
Eh, just kidding, just found the rest of this discussion. Not only did someone else already suggest that, but you already solved it. Ok, I'm going to get some coffee now. 
|
|
|
|
|
Handle WPARAM and LPARAM for custom messages even if you are not using them to avoid crash in release mode.
|
|
|
|
|
I'm using c++ and I have to make a struct big numbers that can keep numbers up to 10^26. I've done this by using a string with a length of 10^26 but now I have to make a funcion for diving the big number with an integer. Can somebody please help me by giving me an idea how to devide this big number (string) with an integer?
|
|
|
|
|
k_micak wrote: I've done this by using a string with a length of 10^26
WOW, your machine must have inifinite memory resuorces. 
(Just kidding)
IMHO the task is not daunting (you may mimic the 10-based division-by-hand technique learned at school) but it will turn out to be quite inefficient. Why don't you have a look at a library like this one [^].
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, I really trust a library when :
"GMP is very often miscompiled! We are seeing ever increasing problems with miscompilations of the GMP code. It has now come to the point where a compiler should be assumed to miscompile GMP. Please never use your newly compiled libgmp.a or libgmp.so without first running make check. If it doesn't complete without errors, don't trust the library. Please try another compiler release, or change optimization flags until it works. If you have the skill to isolate the problem, please report it to us if it is a GMP bug; else to the compiler vendor. (The compilers that cause problems are HP's unbundled compilers and GCC, in particular Apple's GCC releases.) É
|
|
|
|
|
Well this sometimes happens on GCC world. At least they are honest. And probably you should never use a library for GCC whoose make check fails.
I'm confident that passed the make check obstacle, nobody will exchange the library with the string-based approach.
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
|
|
|
|
|
without going to a bignum library, i'd try just duplicating the algorithm that you use when doing long division on paper:
________
1234 | 567890
ex:
5678 / 1234 = 4 with a remainder of 742. carry the remainder to the 9...
7429 / 1234 = 6 with a remainder of 250
250 / 1234 = 0
and now you've reached the decimal point, so the whole number part of the answer is 460, and you can do the rest with FP math.
as long as the divisor (1234) is in the integer range, you'll be OK, since all the other operations in the process will also be in that same range.
modified on Wednesday, March 19, 2008 5:08 PM
|
|
|
|
|
im using vc++ and accessing microsoft access as my database.im using my application on embedded xp,but on running my application im am geting this error
"SPECIFIED DRIVER COULD NOT BE CONNECTED TO THE SYSTEM ERROR:126(MS ACCESS *MDB"
THANKS IN ADVANCE
modified on Wednesday, March 19, 2008 10:24 AM
|
|
|
|
|
I may be wrong about this, but I believe you have to register your database before you can access it. Have you done that?
John P.
|
|
|
|
|
I didnt get what u mean by Registering the database?
|
|
|
|
|
|
Neither do I. I use C++ to interact with Access databases all the time and I've never had to "register" them. 
"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
|
|
|
|
|
Can you tell us how you defined the "connection string" to get records?
Did you use "Control Panel\Administrative Tools\Data Sources (ODBC)" to define it?
|
|
|
|
|
I'm developing a simple animated game and it must run on windows 2000 and above including vista.
Some of us think:
1. Loading bitmaps (.png files) with DirectDraw7 will be MUCH faster than creating textures with DirectX 9.
2. Performance will be the same or better.
3. DirectX textures distorts the bitmap (.png files).
4. It will work on all windows OS because it's backward compatible.
How wrong are we ?
|
|
|
|
|
Based only on what I have read, not experienced, if you intend to use the DirectDraw interfaces you don't want to use DirectX9 because DD is only exposed through a managed class and is therefore slower. If however you want to use the DX interfaces then DX9 appears to be faster than older versions. One specific thing I have frequently read is that the FPS is higher due to a faster fill rate.
|
|
|
|
|
Thank you very much Mike.
led mike wrote: if you intend to use the DirectDraw interfaces you don't want to use DirectX9 because DD is only exposed through a managed class and is therefore slower
If I understand you right: Using DirectDraw interfaces , with the ddraw.lib as part of the DirectX9 SDK is slower.
But perhaps using ddraw.lib from any other sdk is less compatible ?
|
|
|
|
|
Hanan888 wrote: But perhaps using ddraw.lib from any other sdk is less compatible ?
That is certainly possible, I have not seen any noise in regards to compatibility. You might want to do some Googling yourself because I am not directly involved in any game development currently so I don't pay much attention. I know the net is full of noise about game development though. I also don't know anything about PC game dev, I was involved with the console platforms (XBox, PS) only.
|
|
|
|
|
I saw a lot of "do not use direct draw, unless you are crazy".
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
