|
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++.
|
|
|
|
|
|
Hello everybody!
I'm a beginner developer in .Net and I need to know if I can convert Bitmaps to Metafiles in anyway. ( The Save method of the Image Class does´nt work beetwen vectorial images and pixelized images ).
Advanced Thanks!
|
|
|
|
|
Hello everybody!
I'm a beginner developer in .Net and I need to know if I can convert Bitmaps to Metafiles in anyway. ( The Save method of the Image Class does´nt work beetwen vectorial images and pixelized images ).
Advanced Thanks!
|
|
|
|
|
You could, but it takes a lot more than just a simple save. The reason for this is that whereas a bitmap is a map of individual pixels, a metafile is a series of drawing instructions. These drawing instructions can be executed to create a bitmap, but it's very hard to convert a bitmap into drawing instructions.
|
|
|
|
|
Thanks for reply. I think I'm going to try it, surely it´s going to be a hard work, but sure there is a right solution in .NET.
|
|
|
|
|
Hi All
i have defined a __value type class.How can i declare and create it in UnmanagedC++ class using new operator on the C runtime heap?
For example
public __value MyClasss
{
public:
int a;
}
//my unmanaged classs
class MyUnmanagedCPP
{
void SomeMethod()
{
MyClasss *pMyClass = new MyClasss();// here i'm getting error C3828
}
}
|
|
|
|
|
This is explained in depth in my book, Extending MFC Applications with the .NET Framework, but the main issue is that managed objects are dynamically allocated on the CLR heap (not the C++ free store). In your particular situation, you're probably getting C3828 because you're writing an MFC applications and running it in Debug mode where the new operator is being #define'd as a placement new operator. You need to do the following where 1) the new operator is being undefined and 2) __nogc is forcing a GC heap allocation instead of a C++ heap allocation:
void Cdeletethis3Dlg::OnBnClickedOk()
{
#pragma push_macro("new")
#undef new
MyClasss *pMyClass = __nogc new MyClasss();
#pragma pop_macro("new")
}
Cheers,
Tom Archer
* Inside C# -Second Edition
* Visual C++.NET Bible
* Extending MFC Applications with the .NET Framework
|
|
|
|
|
Hi everybody!
I am looking for a parser to read vCalendar and vCard streams.
Any Suggestions?
Thanks for help in advance!
|
|
|
|
|
I am having a trouble of getting image from the hard disk. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
