|
Hello -
I read through a Samm's book... I read through Petzold.. and I still don't have a handle on this.
I am writing software to analyze a bunch of data with the data organized in columns. The general plan is to use the dialog model and open a sub-dialog for each column of data.
No problems creating sub-dialogs. It's destroying them that is confusing me.
Say that I setup, create, and activate a dialog using Create() and ShowWindow().
Now comes time to destroy the window.
I see a variety of ways of doing this:
1. The sub-dialog (an MFC-derived class) executes this->Destroy(). This seems wrong as a class is deleting itself without notifying the parent class.
2. A call-back function destroys the class. This seems reasonable.. except that the child calling the call-back that is part of the parent class winds up calling the child's Destroy() and control eventually returns to a destroyed class. Which ruins the idea.
Somewhere in the MFC documentation, it says that calling a sub-dialog's Destroy() function deletes the window.. but that the class's must be deleted to destroy the underlying data structures.
By this point my eyes are crossing.. and I could use a tip.
Regards,
Mark
|
|
|
|
|
I do not know if this can is you of aid, but I in my application create one in this way ProgressBar Dialog:
...other code...
m_pDlgProgressBar = new CDlgProgressBar();
if(m_pDlgProgressBar != NULL)
{
BOOL ret = m_pDlgProgressBar->Create(IDD_DLG_PROGRESS_BAR,this);
if(!ret)
AfxMessageBox("Error Creating DlgProgressBar");
m_pDlgProgressBar->ShowWindow(SW_SHOW);
}
else{
AfxMessageBox("Error Creating Dialog Object");
}
....other code....
In order to destroy the dialog I have override PostNcDestroy Function
like this:
void CDlgProgressBar::PostNcDestroy()
{
delete(this);
SECBitmapDialog::PostNcDestroy();
}
it makes to know me...
Excuse but my English is not of the best ones 
Too many plans make the health badly...
|
|
|
|
|
What is the std::string equivalent for the following CString operation?
CString time;
int minutes = 5;
int seconds = 5;
time.Format( "Time is %02d:%02d", minutes, seconds );
Output : Time is 05:05
|
|
|
|
|
you can use temp char array for conversion.like this:
char cTime[20] = {0};
sprintf(cTime, "Time is %02d:%02d", minutes, seconds);
string str(cTime);
|
|
|
|
|
Not elegant as the MFC version but that works.
Thanks
|
|
|
|
|
The "recommended by STL fanatics" method is to use an ostringstream:
ostringstream oss;
oss << "Time is " << setw(2) << setfill('0')
<< minutes << ":" << seconds;
string s = oss.str();
[edit] I didn't test it, if it doesn't work, Paul Watson wrote this code[/edit]
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
Still not as slick at MFC:
CString time;
int minutes = 5;
int seconds = 5;
time.Format( "Time is %02d:%02d", minutes, seconds );
But thanks.
|
|
|
|
|
smesser wrote:
Still not as slick at MFC:
Don't argue with me 
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
I'm not  I just keep hearing MFC is dead and I was looking at some of the things that I would have to be able to do to stop using it.
|
|
|
|
|
smesser wrote:
I just keep hearing MFC is dead and I was looking at some of the things that I would have to be able to do to stop using it.
MFC is not completely dead. MS still supports it in VS2005 and you can use winforms with it and vice versa.
In the end it's just a matter of taste, but it certainly wouldn't hurt you if you learn something new..
Blog[^]
|
|
|
|
|
ostringstream is slow as a dog. Read Herb's Coding Standards book for more information.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
ostringstream is slow as a dog.
Don't argue with me
(but you're right, it should be mentioned)
I adore the "The time is {1}:{2}" syntax of C#, the next best is FormatMessage in the C++ world
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
Hi,
I've created a database application that displays a datagrid containing information from an access database. I have an add button which brings up a dialog that adds information to the database but when i close the ialog the datagrid doesn't automatically update. The datagrid is connected to an ADO Datasource. I'm guessing i need to requery the database and refresh the datagrid when the add dialog closes but i'm not sure what window event i should use, or even if i should use a windows message at all.
Can anyone suggest a method for solving this problem?
Thanks
Aaron
|
|
|
|
|
Using the directly the functions of Windows API or using the functions of MFC classes?
|
|
|
|
|
|
Define faster. Do you mean faster to execute or faster to develop? Faster to execute is most likely direct Windows API but with optimization in the compiler you won't really notice a difference. If you mean in speed of developing, well, I would say MFC, but it really depends on how well you know MFC and how well you know the windows API.
-- Rocky Dean Pulley
|
|
|
|
|
I actually came from VB and I went to C++ hoping that I would port the code from VB to C++ and it would execute faster. So, I'm more familiar of the Windows APIs than these MFC Classes.
|
|
|
|
|
User Interface Code is rarely time critical. There are two major issues to consider:
- Repaint Speed
Are display changes "Immeditely"?
Slow form building is what makes (or at least made early) VB applications looking sluggish. There's no notable difference between Win32 API and MFC, and it is usually no problem (If it is looks slow you do something wrong )
- Flicker
rarely a speed issue, but looks "amateurish". This is a question of how it's programmed, not how fast it runs.
- User Action Response time
To handle a user action (e.g. a click on a button), you have about 100..200 ms to handle the message before the user notices a delay. This is more than enough for most actions.
Beyond that, "faster" is bound to the old rule: (all sing along!) "90% of the time is spent in 10% of the code". I would update this rule to
"95% of the time spent is caused by 5% of the code"
(Limiting factors are nowadays less the CPU, but memory throughput, diska access, etc.)
NeverFall wrote:
I actually came from VB and I went to C++ hoping that I would port the code from VB to C++ and it would execute faster
A straight 1:1 port will not make a difference for many applications. It all depends on what they do.
C++ is not the "Porsche Edition of the the VB go-cart", but a fleet of specialized vehicles which can do the same task much faster if they are used correctly
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
In comparison to VB you don't need to care if Win32 or MFC is faster... They are all MUCH faster than VB.
Don't try it, just do it! 
|
|
|
|
|
In many cases, the MFC is a thin layer above the Win32 API. Therefore, in those cases the coding directly to the API will be slightly faster. However, it's doubtful that it would be any thing significant and is outweighed by the ease of use of the MFC over the Win32 API.
Cheers,
Tom Archer - Archer Consulting Group
"Eat your brussel sprouts, Junior. There are starving Chinese children American programmers that would kill for that food!"
|
|
|
|
|
I was reading a chapter in the book C++ Primer Plus and ran across an interesting statement:
".... which can happen if there is no containing try block or no matching catch block, the exception is branded an uncaught exception, and, by default, it causes the program to abort"
So I started thinking. There are many system functions that can throw exceptions. For instance, when I use new to allocate memory for an object a bad_alloc exception could be thrown. Hopefully this will never happen, but what if it does? I've seen a lot of programs, professional and amateur which do not use try... catch blocks to enclose memory allocation. So in that case, if new results in a bad_alloc exception, is my program going to immediately terminate? A lot of times, I have seen code like this:
---
//Somewhere in the program, the pointer is initialized
TheClassType* theClassObj = NULL;
theClassObj = new TheClassType(arg1, arg2, ...);
//Somewhere else in the program, if pointer is not null, use it
if(theClassObj != NULL)
{
//put some code here to use it for something
}
---
So here is my question. The author of the book seems to imply that if the new operation throws an exception, my program will abort right there because there is no try and catch blocks to handle the exception. Is that really true? That seems to defeat the purpose of manually checking the pointer value every time I use it. Why bother?
My argument has always been that if the system can't allocate memory, there isn't much I can do about it at the moment it occurs anyway. So why bother with a try and catch? What's the point? Just let the program crash and then study to code to see what is going on because obviously there is some out of control code segment that is allocating and not releasing resources.
Does anyone have any thoughts on the matter? If so, I'm willing to read them. I'm still struggling to understand why and when I'd ever want to use the std C++ exception handling features. The project I am currently working on seems to be using it to some degree, but in the past I have never used it and I am having a hard time seeing the benefit of it.
Regards,
Shawn Fox
|
|
|
|
|
shawnf22 wrote:
My argument has always been that if the system can't allocate memory, there isn't much I can do about it at the moment it occurs anyway. So why bother with a try and catch? What's the point? Just let the program crash and then study to code to see what is going on because obviously there is some out of control code segment that is allocating and not releasing resources.
You're right. There isn't any point in this case. As I see it, the only point to catching an exception is if you can recover from it or if you want to find out what the problem is and log it somehow. But a memory exception in the scenario you describe is pretty catastrophic so you should just abort.
Kevin
|
|
|
|
|
In fact, the question is: should I care exceptions and, if so, in what
situations. Your example with using operator new is simple to
explain. The MSDN documentation gives the following description:
If there is insufficient memory for the allocation request, by default
operator new returns NULL. You can change this default behavior by writing a
custom exception-handling routine and calling the _set_new_handler run-time
library function with your function name as its argument.
In way shown above, new does not throw an exception by default on
insufficient memory. I would suspect that DEBUG version of the library sets
he new handler which throws one.
Anyway, using operator new you still hav control on what it returns.
There are, though, routines which does not return anything, just
void. Here, you have no control on what happens while executing
that routine and exception is the only way you can check whether the desired
action was done.
Besides what I said above, exceptions give you, as a developer, more
flexibility on handling of wider spectrum of undesired situation in designed
software than you could have based on return values.
That's my point of view.
|
|
|
|
|
The older new (vc6) defaulted to returning NULL. VC7 and later follows the standard.
"The default behavior of a new handler is to throw an object of type bad_alloc. A null pointer designates the default new handler."
This is from the VC documents.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
According to the C++ standard, new must throw an exception if it can't allocate memory. However, the new that comes with Microsoft's C++ Runtime Library doesn't do that, instead, it returns NULL. As another posted pointed out, you can change the behavior if you want to.
Exceptions in C++ make sure that you can't miss error conditions. With simple if/else error checking, it's quite possible to miss a few checks and you'll get into problems later. That's the main difference, exceptions have to be caught, simple error handling is optional.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
