|
jkirkerx wrote: int iResult = SendDlgItemMessage(lb_SQL_Server_Scan_Servers_Field, NULL, LB_GETTEXT, iValue, (LPARAM)&pzServerName);
Have you tried:
iResult = SendDlgItemMessage(lb_SQL_Server_Scan_Servers_Field, NULL, LB_GETTEXT, iValue, (LPARAM) pzServerName);
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Should I be getting back readable text, or is it a pointer to what I put in it?
|
|
|
|
|
int iResult = SendMessage(lb_SQL_Server_Scan_Servers_Field, LB_GETTEXT, iValue, (LPARAM) pzServerName);
I got readable unicaode text from just using sendmessage. The documentation on getting the value was pretty vague, but now that I know, I can use the other LB_'s and so forth to get values from other methods.
Thanks
|
|
|
|
|
The point was not the function being used but rather you were sending the address of an address to it.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I understood the &pzServerName versus pzServerName in the information you presented. I just thought that the & was needed to assign the returned value to pzServerName.
But I wasn't even sure if I was working with the right function at first, the removal of the & cleared things up.
Thanks for the help, the code works good now, on to writing the value to a ini file or something, just need to store the value somewhere.
|
|
|
|
|
Why is it that the Visual C++ 2008 MFC DOC/View based wizard creates an application class InitInstance with the following code checking the result of new being used to dynamically create a CObject derived frame window?
I was under the impression that MFC new would throw on failure
CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame || !pMainFrame->LoadFrame(IDR_MAINFRAME))
{
delete pMainFrame;
return FALSE;
}
|
|
|
|
|
bob16972 wrote: Why is it that the Visual C++ 2008 MFC DOC/View based wizard creates an application class InitInstance with the following code
i'd guess it's because they didn't update that app wizard template.
|
|
|
|
|
This is the code generated by the wizard, which is merely the user application skeleton that the user (i.e. you) modifies to their own requirements. What you have is the minimum necessary and it's up to you to change it to your own needs.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I guess what I'm asking is why do they even check the pointer if MFC claims it will throw on an MFC (CObject derived class) new failure.
|
|
|
|
|
As mentioned elsewhere, this is just some wizard generated code that has not yet been updated. It's really the sort of thing you should be bringing to the attention of Microsoft rather than raising it here.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Richard MacCutchan wrote: It's really the sort of thing you should be bringing to the attention of
Microsoft rather than raising it here
Alrighty then. I'll get a hall pass next time before I start raising questions here 
|
|
|
|
|
What is wrong with my suggestion? You are complaining about a Microsoft product, so the logical thing to do is to report it to Microsoft. How else are they going to discover how concerned you are?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
My question was not a complaint....And no, I don't think the logical thing to do when you have a question is to report it to Microsoft. 
|
|
|
|
|
Sorry dude, I'm going with Richard on this one.
Quote: I guess what I'm asking is why do they even check the pointer if MFC claims it will throw on an MFC (CObject derived class) new failure.
Asking here what is going on in Microsoft's mind is not going to get any answers. Oh, there are a few out here that either claim to be psychic or claim to channel Bill Gates himself but really, if you want an answer to that question, ask Microsoft.
|
|
|
|
|
Here let me rephrase my question so I can better understand if I'm doing things correctly in my existing MFC code...
"Do you check the validity of a pointer to a CObject derived class after new? If so, can you tell me why it would be necessary? If not, can you tell me why it wouldn't be necessary?
NOTE: I'm only focusing on MFC new since and including Visual C++ 2003.
|
|
|
|
|
So I went into Visual Studio 2008 and found some code that uses new and hit 'F1' and received this tidbit:
Quote: Remarks
This form of operator new is known as scalar new, in contrast to the vector new form (operator new[]).
The first form of this operator is known as the nonplacement form. The second form of this operator is known as the placement form and the third form of this operator is the nonthrowing, placement form.
The first form of the operator is defined by the compiler and does not require new.h to be included in your program.
operator delete frees memory allocated with operator new.
You can configure whether operator new returns null or throws an exception on failure. See The new and delete Operators for more information.
With the exception of throwing or no-throwing behavior, the CRT operator new behaves like operator new in the Standard C++ Library.
So, since you can apparently configure the action on failure, I'm guessing that the MFC / Wizard code is defending against the case where it *doesn't* throw an exception (wow, now I'm channelling Bill Gates).
I didn't follow the links to *how* one would configure the behavior or what the default behavior is now-a-days. I suggest you set the behavior the way you want it (or take the default) and write your code accordingly.
|
|
|
|
|
I had to dig around in MSDN and trace through a few MFC based allocation failures to find out how to change the MFC handler and came across AfxSetNewHandler which does (confirmed this) set the handler for allocation failures in an MFC application.
The last time I checked this out (MFC allocation failures) was 7 years back and I only remember walking away with confirming what MSDN says about CMemoryException - "Memory exceptions are thrown automatically by new". Its probably good for one to revisit this topic every so often as I had been concerned that I had been protecting my new incorrectly all this time after seeing the wizard code.
Thanks for helping me get to the bottom of this.
modified 11-Nov-11 21:10pm.
|
|
|
|
|
bob16972 wrote: My question was not a complaint
Sure sounded like one.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Nah. I was just trying to figure out what the Microsoft programmers were attempting to protect against as I hadn't contemplated the scenario that Chuck O'Toole brought up in a different post.
He gave me a swift kick in the right direction and I think the mystery is now solved.
Thanks for your time.
|
|
|
|
|
The C++ standard requires that the new operator throws upon failure, but MS for some unknown reason implemented their compiler otherwise: it will return 0 upon failure and not throw.
In short, Visual C++ is not standard compliant, in this, and various other things, mostly related to templates. If you code platform-independent, you will have to specifically take care of these discrepancies, but since you are using MFC, I suppose that is not the case.
|
|
|
|
|
In this case, the compiler is not at fault. Since VC2005, Visual C++ compilers have been good at adhering to the standard, and has largely been at par with the other compilers out there in that regard.
In VC2008, new throws as it should, but the code in the question above is automatically generated, and that generator has apparently not been updated since the bad old days of VC6.0
Since Herb Sutter - the convener of the C++ standards committee - started working for Microsoft as an architect in the developer tools division, they have spent a lot of time and effort on becoming standards-compliant, and you do them a disservice to claim that the recent compilers are as bad as the steaming pile of wossname that VC6 is.
|
|
|
|
|
Ah, good to know. I only recently switched from 2003 to 2010 and only knew this used to be at fault in VS 2003.
|
|
|
|
|
Hello,
I´d appreciate it if anyone can tell me how to execute a dev-c++ program in the background as stand-alone.
Kindest regards
|
|
|
|
|
Define "in the background," and "as stand-alone."
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
That's pretty much what I answered, but made a couple of guesses... 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
