|
Must be something I installed recently, but this stinking VS.NET C++ IDE is junk ... can't debug ... process is started, but it's dead in the water ...
There's an old post about this in the IDE forum, but no answer yet, anyone have this problem ?
I can run it, but not debug !
Max.
|
|
|
|
|
Max,
Does VS.NET crash when you hit the debug (looks like a 'play' icon) button. Mine does it occasionally. Very wierd.
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
|
I had this problem several weeks ago and here are 2 steps which helped me to solve this mystery:
1. In the project properties dialog set Linker\Debug\Generate Debug Info to Yes.
2. If you have dlls make sure to copy Debug Databases ( *.pdb ) to the app's folder.
43 68 65 65 72 73 2c
4d 69 63 68 61 65 6c
|
|
|
|
|
I have VC6 DLL which calls AfxGetApp to get the default
printer and creates CWnd dynamicly
I have recompiled this DLL in .NET and call the DLL from
an assemible.
When I step into the code the AfxGetApp now returns NULL.
So I can nolonger get the default printer.
When I call Create on a CWnd. .Net throws an excemption, I
trace the excemption to winCore.cpp line 678
cs.hInstance = AfxGetInstanceHandle();
the assertion is due to afxCurrentInstanceHandle == NULL
Is there a work around to enable the unmanaged DLL to
assign a valid afxCurrentInstanceHandle and return a valid
pointer to a Cwinapp
|
|
|
|
|
|
plz tell how to initialized MFC? i need complete syntex .
if you could tell the link related code i will be very thank to u.
and one thing more
if that initialized code is in dll or not in dll. how to deal with it ?
r00d0034@yahoo.com
|
|
|
|
|
I'm not in a position to test this out yet, so I decided to ask someone if they knew first
I've been trying to call a Win32 API function in my MC++ assembly (DnsQuery specifically). After including the necessary DNS header file, it was also pointed out I need to include Windows.h.
Anyway, I wasn't sure whether by including Windows.h at the top of any __gc class it would automatically break, I'm sure I've seen an article somewhere mentioning that Windows.h can't be included in the definition for a managed class.
I'll try it out when I get home tonight, but in the mean time
Thanks as always
--
Paul
"I need the secure packaging of Jockeys. My boys need a house!"
- Kramer, in "The Chinese Woman" episode of Seinfeld
MS Messenger: paul@oobaloo.co.uk
Sonork: 100.22446
|
|
|
|
|
You can certainly #include <windows.h> in your managed C++ assemblies. As was discussed in the thread below this one, there are some symbol conflicts that are easily worked around with #undef.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
Thanks Nick,
I tried it in the end and it worked fine, I was only creating a simple wrapper to the DnsQuery API Function, and in the end its all worked quite well.
Thanks again,
Paul
--
Paul
"I need the secure packaging of Jockeys. My boys need a house!"
- Kramer, in "The Chinese Woman" episode of Seinfeld
MS Messenger: paul@oobaloo.co.uk
Sonork: 100.22446
|
|
|
|
|
I'm trying to use some unmanaged legacy code with my managed application
and I need to include some windows headers ( afxwin.h, afxtempl.h, mmsystem.h ) in stdafx.h but there are some conflicts with some .net framework API, for example, the System::Windows::Forms::MessageBox can't be compiled :
...
#using <System.Windows.Forms.dll>
using namespace System::Windows::Forms;
...
System::Windows::Forms::MessageBox::Show(s, S"Received String");
gives :
<br />
c.cpp(130) : error C2039: 'MessageBoxA' : is not a member of 'System::Windows::Forms'<br />
c.cpp(130) : error C2660: 'System::Windows::Forms::Control::Show' : function does not take 2 parameters<br />
If I removed the legacy code and the headers, everything is ok ...
Any thought ? nish ? ( as you are the expert ! )
Thanks.
Max.
here's the sample code... ( from basic generated managed project. )
#include <afxwin.h>
#include <afxtempl.h>
#ifndef _INC_MMSYSTEM
#pragma message("To avoid this message, please put mmsystem.h in your PCH")
#include <mmsystem.h>
#endif
#include "stdafx.h"
#using <mscorlib.dll>
#using <System.dll>
#using <System.Drawing.dll>
#using <System.Windows.Forms.dll>
#include <tchar.h>
using namespace System;
using namespace System;
using namespace System::Drawing;
using namespace System::Windows::Forms;
using namespace System::ComponentModel;
int _tmain(void)
{
MessageBox::Show(S"Allo", S"Request");
Console::WriteLine(S"Hello World");
return 0;
}
|
|
|
|
|
The problem is that windows.h #define's "MessageBox" to be either "MessageBoxA" (ANSI) or "MessabeBoxW" (Unicode). The preprocessor is replacing all instances of "MessageBox" in your code to "MessageBoxA", and of course that is not a valid type in the Forms namespace.
You must #undef MessageBox.
If you intend to use both the Windows MessageBox() and the .NET Framework's MessageBox(), you can get tricky and store the MessageBox macro on the preprocessor's stack:
#pragma push_macro("MessageBox")
#undef MessageBox
...
#pragma pop_macro("MessageBox")
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
Nick Hodapp (MSFT) wrote:
You must #undef MessageBox.
That did the trick, but it's not something I really like ...
Thanks.
Max.
|
|
|
|
|
Me neither, but it's the reality of programming with libraries that have conflicting names...
Nick
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
I don't think the problem is the conflicting named, I can live with that, but the problem is with the preprocessor that rewrite code for us ...
Max.
|
|
|
|
|
Well, that's just C++.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
Wouldn't solving conflicting names with simple rules a real interesting stuff to come up with ?
If I remember well, the Eiffel language has this feature, when deriving classes.
And I swallow a small raisin.
|
|
|
|
|
Hi, everyone!
Look at the source codes,
--------
/* #define WIN32 */
#ifdef WIN32
#define MORECORE wsbrk
#endif
--------
Such is the comments,
--------
WIN32 (default: undefined)
Define this on MS win (95, nt) platforms to compile in sbrk emulation.
--------
I have two questions,
1. What means WIN32? When the variable "WIN32" becomes
defined? When it is not defined?
2. What means "sbrk" in the comment? What means "wsbrk"?
Btw: the software is written for both Windows and Linux
platforms.
Cheers,
George
|
|
|
|
|
Please only post in one forum...
This question don't have anything to do with either Managed C++ or ATL/WTL/STL
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Thanks, Anders pal!
I will accept your advice.
I cross-posted because my boss is asked me to hand in the
project immediately, but I am in trouble as you
see.
Cheers,
George
|
|
|
|
|
Hi, everyone!
I have searched the help page for "size_t" but failed
to find the help page and information about "size_t".
Where can I find the help page or information about
"size_t"? Can you paste detailed information about
"size_t".
Thanks.
Cheers,
George
|
|
|
|
|
|
Thanks, Nish, my old friend!
I still have a question.
What means "typedef _W64 unsigned int size_t;"?
Does it mean the three objects
_W64, unsigned int and size_t are the same?
Have a nice weekend,
George
|
|
|
|
|
Hello George
It means size_t is a synonym for _W64 unsigned int
And as far as I could make out _W64 has been defined as nothing. Perhaps someone else can correct me here if I am wrong.
So as far as you are concerned you can cast the size_t to an unsigned int
Regards,
Nish
p.s. I found the cross posts humorous, specially your choice of the ATL/WTL forum
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Thanks, Nisk pal!
I think I have fully understood the meaning
of size_t under your directions and other pals
in ATL/WTL forum.
Have a nice weekend,
George
|
|
|
|
|
As far as I can see, there's no header file in Managed C++ ?!?!?!?! everything seems to be inlined in the class like this in either a .h or .cpp file that can be included in the main project file:
<code>
__gc public class MyForm : public Form
{
public:
MyForm()
{
Text = S"MyForm";
};
};
</code>
The question, is, can I separate the implementation for the declaration ? to have a header file and a code file ( .h and .cpp ) ?
Are there rules, guidelines or specification ?
Thanks.
Max.
|
|
|
|