|
I have a problem and don't know what to do. 
I've written some unmanaged code and made managed wrappers for classes. Project loads in VS 2003 on my computer (first it was created by VS .NET), but on other computers VS doesn't open it. So I created new project and inserted all code there. It compiled ok, but new assembly doesn't load
with error message "procedure imported by some.dll could not be loaded".
Do someone had same troubles and how to fix this?
Thanks
|
|
|
|
|
I need some suggestions on starting an MDI project using managed C++. Note that there will be at least three different document types(and different menus.)
thanks
|
|
|
|
|
Use MFC. You may check possibility of having managed Form/UserControl hosting MFC MDI app.
Just possibility.
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
|
R U in Vegas?
The only way of discovering the limits of the possible is to venture a little past them into the impossible.--Arthur C. Clark Toasty0.com
|
|
|
|
|
|
|
Didnt know about it. Thanks. I will check it out
|
|
|
|
|
All,
I am converting a server TCP based software from C++ to Managed C++ and .NET. I want to use C++ as less as possible and use mainly __gc classes and data. I have some problems though. The server communicates with commands encapsulated in structs. For example:
struct SomeStruct
{
int i;
int j;
long int p;
};
So my question is how to convert the managed char array which I receive from the Socket or NetworkStream class to this struct. I want to declare my struct as managed -- __gc struct.
So if we summarize I need to cast managed char array to managed struct or at least copy the contents of the char array to a newly allocated managed struct.
In straight C++ this was pretty easy - we use cast and treat the char buffer like a struct or we use memcpy and copy the contents of the char array to the struct. However I did not found any way to do this fast in managed C.
Can anyone help me with this?
Nick
Visuall
|
|
|
|
|
Does anyone know how to get a pointer to a managed class in the Document (MFC architecture).
The whole project is in C++ except the class to which I want to get a pointer.
Everything compile fine but when I do a #include "MyManagedClass.h" in the Document it doesn't work.
Thanks
ad
|
|
|
|
|
I know that I have Data in the clipboard with the DataFormat::MetafilePict.
But I can't get it. My code is more or less the next:
/////////////////////////////////////////////////////////////
if ( iData->GetDataPresent( DataFormats::MetafilePict) )
{
System::Object * obj;
System::Drawing::Imaging::Metafile * pMetafile;
obj = Clipboard::GetDataObject()>GetData(System::Windows::Forms::DataFormats::MetafilePict ); pMetafile = dynamic_cast< System::Drawing::Imaging::Metafile * > (obj);
}
/////////////////////////////////////////////////////////
Obviusly in the Debug, I enter inside the first if condition, so the code executes but the System::Object obj can't keep the data of clipboard and keeps a undefined value after the asignation.
It seems a contradiction, isn't it ?
Can anybody say me anything about get MetafilePict Data from Clipboard ?
Advanced Thanks, everybody.;)
|
|
|
|
|
I'm building a DLL with Visual C++ .NET that needs to be portable back to Win98. However, the DLL simply fails to load (using depends.exe) even when all required (MSVC 7.1) DLLs are provided in the search path.
Win98 will successfully load a barebones DLL if we disable Managed Extensions, but the full project does not link without Managed Extensions due to nafxcw/msvcrt conflicts.
Is it even possible to run Managed Extensions code on Win98 given the appropriate DLLs? And/or does anyone have any pointers to solving link errors (see below) when Managed Extensions are removed?
Thanks...
-----------
nafxcw.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in MSVCRT.lib(MSVCR71.dll)
nafxcw.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in MSVCRT.lib(MSVCR71.dll)
nafxcw.lib(afxmem.obj) : warning LNK4006: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in MSVCRT.lib(MSVCR71.dll); second definition ignored
nafxcw.lib(afxmem.obj) : warning LNK4006: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in MSVCRT.lib(MSVCR71.dll); second definition ignored
nafxcw.lib(apphelp.obj) : error LNK2001: unresolved external symbol __mbctype
nafxcw.lib(filelist.obj) : error LNK2019: unresolved external symbol __mbctype referenced in function "void __stdcall _AfxAbbreviateName(char *,int,int)" (?_AfxAbbreviateName@@YGXPADHH@Z)
nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv
nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argc
|
|
|
|
|
Defining _AFXDLL seems to have helped. Not quite sure why.
|
|
|
|
|
Is it considered part of the OS? Or is it treated on par with someting like the Java JIT compiler?
|
|
|
|
|
LasVegasGuy wrote:
Is it considered part of the OS
Not yet. It will be integrated into the os when longhorn arrives though...
LasVegasGuy wrote:
Or is it treated on par with someting like the Java JIT compiler?
Yes.
John
|
|
|
|
|
Would that mean it would encompass the full full depth and breadth of the Windows API?
|
|
|
|
|
No. Two different ani-mules.
HTH.
Best,
Jerry
The only way of discovering the limits of the possible is to venture a little past them into the impossible.--Arthur C. Clark Toasty0.com
|
|
|
|
|
|
Thats what I thought at first. But then, if reading online MSDN documenation about GDI+, on the one hand it seems like a C++ Win32 API interface, on the other hand it is also touted as part of the .Net framework. Also, if you look at the Visual C++ section in the following article,
http://msdn.microsoft.com/vstudio/productinfo/whitepapers/default.aspx#vs%20languages%20playbook_msdnwp%20temp_topic3
it implies that full access to the Win API will be available only through Visual C++.Net.
Man learns from History that he NEVER learns from History
|
|
|
|
|
LasVegasGuy wrote:
But then, if reading online MSDN documenation about GDI+, on the one hand it seems like a C++ Win32 API interface, on the other hand it is also touted as part of the .Net framework.
This is because the .NET Framework BCL has a wrapper for the C++ GDI+ class library.
LasVegasGuy wrote:
it implies that full access to the Win API will be available only through Visual C++.Net.
C# and VB.NET can use the Windows API, but they can only do so through P/Invoke. MC++ can access the Windows API the same way that VC++ does. With Longhorn, all .NET languages will have equal access to the Windows API, because it will be in the form of a managed class library.
|
|
|
|
|
|
Tom Archer wrote:
Justin is correct. Remember also that MS wants people to move to .NET so everything is going to have a .NET spin to it.
Tom,
Does that mean that VC++ will not have the access to the win32API that it now enjoys? If true, will that cause a performance hit that doesn't exist now?
Assuming that is also true, what could PC game developer do to overcome this hit if indeed one will exist?
Best,
Jerry
The only way of discovering the limits of the possible is to venture a little past them into the impossible.--Arthur C. Clark Toasty0.com
|
|
|
|
|
Toasty0 wrote:
Does that mean that VC++ will not have the access to the win32API that it now enjoys?
Even if it can't access the WinAPI any other way, it can certainly do it through COM interop.
|
|
|
|
|
What about legacy code which directly makes API calls?
|
|
|
|
|
It'll still be supported through a compatibility wrapper, but nothing new will be added to it.
|
|
|
|
|
Thanks!!
Hopefully, by then managed C++ will have been standardized and brought in tune with ISO C++.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
