|
A few random things to try... there is an article somewhere around here called "Surviving the Release Build", which has some good info.
Also, I've noticed that the Debug build often is "nice" and initializes variables to zero or to a known debug value. Release mode gives you no such luck. So perhaps you just have an uninitialized variable somewhere?
You can also try "Cave-man" debugging... put in message boxes at strategic locations in your program to narrow down the crash. 
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
I've read that article and everything I can find in MSDN.
I've tried the cave-man approach, and the problem seems to move. That's why I'm thinking its a pointer gone awry.
The problem exists even if I run a debug version executable as an EXE, without the debugger.
Also, if I run a release (NDEBUG, with inlining and optimizations) version in the debugger, I don't get any errors!
|
|
|
|
|
Without more info, it can be hard to try to help you.
Maybe you can set debug information for the release version (Keith Rule's Debugging Release Mode Problems[^] tells you how), if the error still pops up then you'll know where it is located.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
That's just it - its not just a standard debug-to-release problem.
If I run a _release_ version executable in the debugger, it works fine. Its only when I run it as an EXE that it fails. It doesn't matter what my build settings are, its a question of if I'm running it in the debugger or double-clicking the EXE.
|
|
|
|
|
Can you include some poor-man traces (message boxes, for instance) to narrow down the point of error?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Probably you could try Numega Boundschecker to check for memory leak. No guarantee on solving your problem thou.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Thanks for your help.
It turns out I was doing something like this:
(In a member fn of a class based on std::list)
iterator it(begin()), en(end());
while(it!=en)
{
if(*****)
it=erase(it);
else
++it;
}
For some reason, the debugger let this slide, and it was only picked up by running the EXE, even though they were _exactly_ the same build!
|
|
|
|
|
In an MFC app I wrote, I wanted to display some normal text with an up arrow or down arrow inside a CStatic text control. The only font that contains those characters is the Symbols font. So I took one of the normal fonts, copied the arrows from Symbols into it and saved it with a new font name. Then in my MFC app I loaded that new font, and everything works great.
Now I'd like to send the text to a lazer printer. These arrows obviously don't print because the printer doesn't know about my new font.
Is there a standard way of loading fonts to a lazer printer so that it will use my new font?
Thanks
|
|
|
|
|
I have run into an issue with ExtCreateRegion on windows 9X machines. I use getregiondata to get the data and then use ExtCreateRegion data to recreate the region. Everything works fine on 2000/XP and on 9x machines when the region is less than 64K but on the 9x machines when the region is larger than 64K it fails. The MS documentation says 64K is not longer a limitation on 9x but my tests seem to elude to a different answer. The code is pretty simple:
int LastTestRgnSize = GetRegionData(TempRgn, 0, 0); // get the rgn size
unsigned char* LastTestRgn = new unsigned char[LastTestRgnSize];
memset( LastTestRgn, 0x00, LastTestRgnSize );
int size = GetRegionData(TempRgn, LastTestRgnSize, (RGNDATA*)LastTestRgn);
HRGN Rgn = ::ExtCreateRegion(NULL, RgnSize, (RGNDATA*)Temp);
The ::ExtCreateRegion function will fail when the region size is above 64K on 9x but not on 2000/XP. Does anyone have a work-around for this or any ideas on how to correct the problem.
Thanks in Advance 
nemo
|
|
|
|
|
nemo wrote:
The MS documentation says 64K is not longer a limitation on 9x
I'd like to see where it says that. Everything in User and GDI on 9x has 16-bit limitations because much of that code is 16-bit code for Win16 compatibility. [Eg, list boxes can't hold more than 32K items, 32K is the max value of a 16-bit signed int; 9x can't handle more than 16K window handles, 16K*4 bytes = 64K bytes, 4 bytes being sizeof(HWND)]
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | 1ClickPicGrabber New v2.0! | RightClick-Encrypt
If my rhyme was a drug, I'd sell it by the gram.
|
|
|
|
|
Can you suggest some software to create a help file for my application? I need my help file to have a look as in the VC++ Help such as Content, Index, Search. This help file should allow me to embed graphics/screen shots. I have looked into htmlhelp, but i am not sure this is the best tool.
Elizabeth
|
|
|
|
|
help workshop
hhc.exe from microsoft
includeh10
|
|
|
|
|
Do you have any preference over the two products WinHelp and HTMLHelp?
Elizabeth
|
|
|
|
|
WinHelp uses RTF or plain-text documents as it's contents.
HTMLHelp, in the other hand, is entirely constructed of web pages. Each page on the help guide is an independent web page. You can use things like Internet-links, style sheets, Java etc etc to aid in your help file creation..
I, for myself, prefer HTML Help for these reasons.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
html help seems to need to input index one by one, but old help can generate all indexes automatically.
includeh10
|
|
|
|
|
Thank you all. HTMLHelp fixs better for us since the files can be used cross platform. We are sharing the help files with both Windows and Web applications.
Elizabeth
|
|
|
|
|
... than normal combo-boxes. Any idea why? And how can I keep this from happening?
I have 3 combo boxes on a tool bar, one of them is owner draw and it looks rather weird...
|
|
|
|
|
|
Yes... MeasureItem allows you to change the size of the items in the associated listbox of the control. My problem is that the editBox (and the combo control itself when not expanded) is actually higher by about 4 pixels.
You can test this in the resource definition, simply check the Ownerdraw for a combo and preview the dialog and it is already bigger. Not the end of the world but it looks weird when you have two combos next to each other. I may have to make them both owner-draw... Great!
|
|
|
|
|
In MeasureItem you can specify not only the height of your items, but also the height of the combo-box itself when the item ID is -1:
if (lpMeasureItemStruct->itemID == (UINT)-1)
lpMeasureItemStruct->itemHeight = 15;
else
lpMeasureItemStruct->itemHeight = 13;
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
|
|
|
|
|
Wow.. I am very grateful... Thanks for posting this! Better later than never!
|
|
|
|
|
which function or command is for removing items from Start menu programmatically?
thanks
includeh10
|
|
|
|
|
Try looking for SHGetSpecialFolderLocation(..., CSIDL_COMMON_STARTMENU, ...). Once you have access to the folder's IDL, adding to, or deleting from, it is trivial.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
thanks.
this function is COM staff, isn't?
includeh10
|
|
|
|
|
COM staff??
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
