|
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
|
|
|
|
|
I have a dataset that I read from an xml file using
DataSet.ReadXml(fs);
I then add to the dataset and rewrite the xml file using the following:
DataRow newrow = mf.quotesDataSet.Tables["quote"].NewRow();<br />
newrow["thequote"] = quoteInput.Text;<br />
newrow["speaker"] = speakerInput.Text;<br />
newrow["origin"] = originInput.Text;<br />
newrow["image"] = "test.jpg";<br />
mf.quotesDataSet.Tables["quote"].Rows.Add(newrow);<br />
mf.quotesDataSet.WriteXml(fw);
It does add the data, however, it adds it outside the main xml hierarchy. For example, instead of:
<rss><br />
<channel><br />
<quote><thequote>text</thequote></quote><br />
<quote><thequote>text</thequote></quote><br />
<quote><thequote>new text</thequote></quote><br />
</channel><br />
</rss><br />
it writes to the file as:
<rss><br />
<channel><br />
<quote><thequote>text</thequote></quote><br />
<quote><thequote>text</thequote></quote><br />
</channel><br />
</rss><br />
<quote><thequote>new text</thequote></quote><br />
how do I make the added rows to the dataset write into the proper hierarchy?
|
|
|
|
|
<br />
#pragma check_stack(off)<br />
#pragma comment(linker,"/OPT:NOWIN98")<br />
#include <windows.h><br />
#include <shellapi.h><br />
<br />
#define mFunc(x) int __stdcall x(HWND mWnd, HWND aWnd, char *data, char *parms, BOOL show, BOOL nopause)<br />
<br />
<br />
mFunc(IsTaskbarAutoHideOn)<br />
{<br />
APPBARDATA ABData;<br />
ABData.cbSize = sizeof(ABData);<br />
return<br />
SHAppBarMessage(ABM_GETSTATE, &ABData)<br />
& ABS_AUTOHIDE;<br />
wsprintf(data,"%d");<br />
return 3;<br />
}<br />
any idea why this won't return a value to mIRC?
also what function do i use to enable or disable it? thanks
PS: i'm kind of a newb, so try and use simple english :p lol
"Don't fight with idiots, first they pull you down to their level, then they smash you with their experience"
|
|
|
|
|
I have a need to changed the All Ways On top setting for the Windows Task Bar under program control. I have tried using SHAppBarMessage to Set State but it does not work. Has anyone done this and how?
|
|
|
|
|
Hi all,
I'm toying around with VS2005 Beta 2, recompiling one of my ongoing projects that contains ~300 .CPP files. Normally I use VC6 to work with this project.
I'm getting tons of warnings I wanna get rid of, namely C6054 ("string may not be zero-terminated") and C4996 ("function was declared deprecated"). For the most part, I'm getting these out of MS's own headers like tchar.h.
I need those headers but could do without those specific warnings (for now). I could "#pragma warning" them out before including the offending files, but I'd have to do this for nearly all of my 300+ CPP files; this is impractical for this project. I don't want to lower the warning level either for the entire project, because there are other warnings I actually do want to see.
How could I disable specific warnings, project-wide?
|
|
|
|
|
Put the #pragma warning in the stdafx.h file?
Daniel Desormeaux wrote:
C6054 ("string may not be zero-terminated")
That looks kind of wierd, how are strings to be terminated if not with a zero (NULL)? or are NULL and zero considered to be different in 2005?
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
Honoured as one of The Most Helpful Members of 2004
|
|
|
|
|
> Put the #pragma warning in the stdafx.h file?
I don't have one. This is a raw Platform SDK project that started off years ago with a totally empty file to which a main() function was added and then things evolved from there... 
> That looks kind of wierd, how are strings to be terminated if not with a zero (NULL)?
For all intents and purposes, I think that particular message is intended to point out potential buffer overrun errors (eg, strcpy vs strncpy)...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
