|
Thanks. I tried that too but didn't work either.
|
|
|
|
|
The problem, as I mentioned here, is that the FILE* passed to fprintf() is NULL. That's what the assertion is telling you.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
But it is creating the file in the "fopen" statement.
Ok incase as you said if it is doing so then what is the solution for that. What I'm supposed to do on that case.
|
|
|
|
|
agarunk wrote: What I'm supposed to do on that case.
I'm out of ideas at this point. You might try setting a breakpoint on the fprintf() statement and verify the value of sLogFile.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I'm writing dll and using it in C# so I cant put the break point. That is main problem to trace out.
|
|
|
|
|
At a minimum:
FILE *sLogFile = fopen("XMPLog.txt", "wb");
if (sLogFile != NULL)
{
fprintf(sLogFile, "Version : %s\n", version.message.c_str());
fclose(sLogFile);
}
else
MessageBox(...);
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I agree with David's suggestion. Passing C++ as a "optional" parameter yeilds undefined behaviour. With CStrings, you can do this, and I bet Microsoft engineers did some tweaking to make that work. I don't know about std::string, but chances are that they are not crafted in such a way that they will work with printf()-like functions...
--
100% natural. No superstitious additives.
|
|
|
|
|
Yes I agree with you, but what exactly I'm supposed to do now.
Please tell me if you are having some other alternatives or proper approach to tackle this. If possible with a sample piece of code.
(I'm getting error in "fprintf" part of file operation though "fopen" is working properly)
Thanks,
Arun
|
|
|
|
|
|
overide the WM_CTLCOLOR message and put the following code inside it
if( nCtlColor == CTLCOLOR_STATIC)
{
pDC->SetBkMode( TRANSPARENT );
}
this make the text backGround transparent.
To change the color use pDC->SetBkColor( RGB(0,255,0)); instead of SetBkMode
nave
|
|
|
|
|
Naveen R wrote: if( nCtlColor == CTLCOLOR_STATIC)
{
pDC->SetBkMode( TRANSPARENT );
}
Groupbox is not a static control but a button control with style BS_GROUPBOX.
Nibu thomas
A Developer
Programming tips[^] My site[^]
|
|
|
|
|
It's the button style, but its CTLCOLOR classification is CTLCOLOR_STATIC not CTLCOLOR_BTN
It seems that what naveen said was correct.
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
SaRath C wrote: CTLCOLOR_STATIC not CTLCOLOR_BTN
whitesky
|
|
|
|
|
I created one static class for it
whitesky
|
|
|
|
|
WhiteSky wrote: I created one static class for it
just for changing the color?
nave
|
|
|
|
|
ah no?, write one class for mimimimilaw
whitesky
|
|
|
|
|
Try it creating a sample application...
I am sure my code will work....?
nave
|
|
|
|
|
I wrote one example for you and i change background color from groupbox
whitesky
|
|
|
|
|
get the dc and make it transparent.
hello
|
|
|
|
|
I want to develop an MFC application that has
1. Either a control bar or dialog bar which has some button objects
2. The bar needs to be always accessible. That means I want to be able to click on the buttons on the bar even if a modal dialog showing.
One way I thought of to put the dialog bar in its user thread, but this is almost impossible as it dialog bar needs to send a message to the main windows. Another way was not to show modal dialogs, but this would complicate the design as to manage the number of different dialogs to be displayed.
Any thought as to how to put a controls bar/dialog bar/or even a child windows on its own thread that can always listen to user actions? A pointer to an article or sample code would be great.
Thanks,
/* I can C */
// or !C
Yusuf
|
|
|
|
|
I didn't get the exact situation over there. I will put my suggestions.
If you want to keep the UI alive, It is best to keep it in a separate UI thread and keep posting messages. There is always a defenite way to do that.
Also the use of Modal dialog demands the user to deal with the dialog ,and with nothing else when it is shown. You still have chances of improvement over here.
Sher
|
|
|
|
|
Thanks Sher,
The whole UI doesn't need to be alive, but a portion of it needs to be alive all the time. Think it this way, I want my toolbars to be alive all the time.
I started looking into creating my toolbar as a CDialogBar item which will run in it's own CWinThread. I though this will isolate it from the whole UI message loop. Since the CDialogBar object is created inside the CFrameWnd object, whenever the main UI is blocked, so does goes the second CWinThread which has my CDialogBar object.
I could create my CDialogBar as a child of the Desk top, which solves the blocking issue, but it lives outside the main UI frame, which does not meet my requirement.
Any idea as to how I might be able to solve this?
/* I can C */
// or !C
Yusuf
|
|
|
|
|
DoModal will block its parent by PreModalDialog API and releases using PostModalDialog
Have you tried modeless dailogs?
SaRath.
"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++
|
|
|
|
|
Yes I thought of modeless dialogs. But there is AfxMessageBox() which acts as modal dialog.
I though overriding PreModalDialog(), DoModal() to prevent the main UI from being blocked. it turns out, I will need to handle more cases, and alost have my own CDialog code.
Hmm, I guess I might be trying to do the impossible?
/* I can C */
// or !C
Yusuf
|
|
|
|
|
I'm studying and coding in MFC about Text To Speech in Microsoft Word. I need to find Materials of Text To Speech to present what I'm studing. What page or what material can I find ?
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
