|
Well my code is slpitted in: one myClasses.h and one myClasses.cpp files and it's something like this:
// *** myClasses.h: ***
#define SIZE 10
public __gc class MyClass;
public __gc class AnotherMyClass;
public __gc class MyClass{
public:
MyClass();
void myMethod();
private:
bool myArray __nogc[SIZE];
AnotherMyClass* anotherMyClass;
};
public __gc class AnotherMyClass{
public:
AnotherMyClass(bool myArray __nogc[SIZE]){ // constructor is inlined
for(int i=0; i<size; i++)
="" this-="">myArray[i] = myArray[i];
}
private:
bool myArray __nogc[SIZE];
};
//*** myClasses.cpp: ***
MyClass::MyClass(){
for(int i; i<size; i++)="" myarray[i]="true;
" anothermyclass="NULL;
}
void" myclass::mymethod(){
="" anothermyclass(myarray);
}
="" ***="" oh,="" and="" this="" is="" the="" main="" (in="" another="" file):="" ***
int="" _tmain(){
="" myclass*="" myclass="new" myclass();
="" myclass-="">myMethod();
return 0;
}
So far I receive this error, but I can't understand why and how to fix it (without using managed arrays):
error C2664: 'AnotherMyClass::AnotherMyClass' : cannot convert parameter 1 from 'bool [10]' to 'bool []'
I can't find anything on google too, help help!
|
|
|
|
|
Please modify this thread and chose "do not treat <'s as HTML tags"
|
|
|
|
|
I have created a class library that uses managed extensions for c++ [manageddll] where i have a test() unmanged function with a dll export decoration.
I later tried loading this dll from an MFC based dialog application and tried calling the test() function. The app crashes at run time.
If anybody could help me in this regard?? Thanks in advance.
|
|
|
|
|
I would guess that the loader does not recognize that the .NET managed assembly is valid. MFC has no concept of metadata nor the .NET assembly header format.
Just out of cusiosity, why would you want to do this?
|
|
|
|
|
This might be a better explanation than my response:
http://msdn.microsoft.com/msdnmag/issues/05/01/CQA/[^]
Read the final question: "Can I Call the .NET Framework from my MFC application?" (The answer is Yes). The author explains the problems associated with this type of operation.
|
|
|
|
|
I m doing this because i would like to use the same managed c++ dll for both my managed and unmanaged clients.
Check this page for calling managed c++ from an unmanged environment:
http://www.codeproject.com/dotnet/bridge.asp
This sample worked fine if i called from a win32 console application but when loaded from MFC app. It crashed during runtime.
|
|
|
|
|
I read the article and downloaded the code and read that, and I'm embarrassed to admit, that I couldn't understand how exactly it was supposed to work.
I feel terrible. My advice above, obviously was completely incorrect.
|
|
|
|
|
i have here this pice of code from a class
i dont understand what does _RSA_FZM_CLASS stand for.what must i type in as search to get more information on this type of declarations of classes
class _RSA_FZM_CLASS TRsaFuzzyAccumulation : public TRsaFuzzyOR
{
public:
//member functions
};
|
|
|
|
|
It's probably a MACRO, so put your mouse over it and see if intellisense tells you what it really means.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Grauss wrote:
t's probably a MACRO, so put your mouse over it and see if intellisense tells you what it really means.
and if it doesn't, search for _RSA_FZM_CLASS into your hole project, and in the included files...
TOXCCT >>> GEII power [toxcct][VisualCalc]
|
|
|
|
|
Hi,
Does anyone know how to convert a pointer to a managed class to a void * so I can pass it to a unmanaged function which will call into a managed function with the void pointer which then needs to convert the void pointer back to a managed pointer. All the code is in the same exe I am not calling into a dll.
Here is a chunk of code as an example:
__gc class mcFoo {
.
.
.
public: int x;
};
tmain()
{
mcFoo *Foo = new mcFoo();
Foo->x = 1;
xxx(Foo);
//Foo->x == 2
}
#pragma unmanaged
xxx(void *ump)
{
yyy(ump);
}
#pragma managed
yyy(mcFoo *mp)
{
// mp-> x == 1
mp->x = 2;
}
|
|
|
|
|
I believe I have found the solution. By creating a unmanaged class and having it contain a pointer to the managed class (using gcroot) and passing that to the unmanaged function it apears to resolve the compiler issues. If this is the right aproach I have a new question:
If the managed class is complex in that it conatains pointers to other managed classes, such as a container class, do I need to do more such as define the layout mechanism of the class? I am not using this pointer in any of the unmanaged code, just passing it through from on managed function to another through a unmanaged function.
|
|
|
|
|
Hi,
I have a dll that is using mixed mode. I followed these steps to create the
project:
1. Created a managed C++ class library.
2. Added methods and code that uses unmanaged MFC (CString).
3. Compiled.
4. Added this dll as a reference in some C# project.
5. Used the managed classes that were coded in the dll.
Everything was normal until i tried to fix the linker warning:
LINK : warning LNK4243: DLL containing objects compiled with /clr is not linked with /NOENTRY; image may not run correctly
This link says how to fix the linker warning:
http://msdn.microsoft.com/library/d...tomixedmode.asp
Please check the steps given under the section:
"To convert the managed DLL to mixed mode"
After doing whatever was mentioned in that section, when I access a
method in the dll that uses CString, I get an exception in one mfc file.
Details of the exception:
-------------------------------
File : f:\vs70builds\3077\vc\MFCATL\ship\atlmfc\include\cstringt.h
Line : 1088
Expression : AtlIsValidString( psz )
... and blah blah.
Can anyone help me in fixing the linker warning as well as the exception ?
Thanks in advance.
-Raj.
|
|
|
|
|
Hello,
I have created an MFC C++ application. I copy the exe to my colleagues machine.
I want to execute it on my his machine but when I do so on his machine it says hat the MFC71D.DLL
is missing. All I am doing is copying over the exe, I expected it to execute.
Can anyone help? Thank you, Joe
|
|
|
|
|
He has the .NET Framework 1.1 installed... I forgot to mention this.
|
|
|
|
|
joseph1950 wrote:
says hat the MFC71D.DLL
is missing
The D means you gave him a debug build - NEVER do that.
MFC is a dll, as you have discovered. If a release build does not work, then you need to give him the dll. If you've used C runtime functions, you'll need MSVCRT something.dll ( I forget the number ). To avoid this, choose 'use MFC as a static library' when you build your next MFC app, it will be bigger, because it will include the MFC code you use in your app.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thank you for your replies. I pulled down project -> properties->general and changed the debug to release and then rebuilt the application. I then also experimented with changing shred dll to static dll as well. My coworker hasn't yet tried the new versions. Am I doing what you said to do?
Joe
|
|
|
|
|
Yes, always give out release versions. Debug versions contain a lot of extra stuff to help debugging, and will be slower, as well as needing debug dlls, and the other issues someone else raised.
I didn't think you could change to static build on an existing project ? Anyhow, I was not saying you should do this, necessarily. I wouldn't, but I mentioned it so you can decide if you want to. Ideally, you should just ship with the dll, then you can ship smaller updates, because you'll know the dll is there. If I was offering software for download, I'd offer the dll seperately.
Don't forget, you may also need MSVCRT, if you've used C runtime functions. I think VC comes with a tool called Depends that tells you what dlls your app needs.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
i don't agree with christian for linking MFC as a static library. sure it does not force you to provide the MFC dll with you program, but it can enlarges enormously your program if you call many MFC functions.
as i already ask[^] on MFC dll version, here is[^] what Alok responded to my great satisfaction...
so to sum up, I advise you get your MFCs as a dynamic linked library (DLL), and always provide that DLL with you programs written with MFC (it is not so big after all...).
Also, as Christian said, be careful not to provide to ones a debug version. visibly here, it was for a collegue, but remember make a release version before distribute your soft... it will increase security (debug information can allow recovering the code) and decreasing considerably the size of your exe...
cheers,
TOXCCT >>> GEII power [toxcct][VisualCalc]
|
|
|
|
|
Thank you for your replies. I pulled down project -> properties->general and changed the debug to release and then rebuilt the application. I then also experimented with changing shred dll to static dll as well. My coworker hasn't yet tried the new versions. Am I doing what you said to do?
Joe
|
|
|
|
|
It worked. I have distributed the app. Thank you. Joe
|
|
|
|
|
toxcct wrote:
don't agree with christian for linking MFC as a static library. sure it does not force you to provide the MFC dll with you program, but it can enlarges enormously your program if you call many MFC functions.
Sorry, I wasn't advocating that as a general approach, I was just trying to give a complete answer. I also said that would bloat the exe size.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi... Sorry if this becomes a long message but, Please look throught this code:
#using <mscorlib.dll>
#using <System.dll>
#using <System.Drawing.dll>
#using <System.Windows.Forms.dll>
using namespace System;
using namespace System::Drawing;
using namespace System::Windows::Forms;
__gc class SimpleForm : public Form
{
public:
SimpleForm();
private:
Button *btnMe;
void CloseClick(Object *Sender, EventArgs *Args);
};
SimpleForm::SimpleForm()
{
this->BackColor = System::Drawing::Color::Azure;
this->Text = S"Ett litet Test";
btnMe = new Button;
btnMe->Location = Point(115, 225);
btnMe->Text = S"&Close";
btnMe->Click += new EventHandler(this,CloseClick);
this->Controls->Add(btnMe);
}
void SimpleForm::CloseClick(Object *Sender, EventArgs *Args)
{
Close();
}
int __stdcall WinMain()
{
SimpleForm *SF = new SimpleForm();
Application::Run(SF);
return 0;
}
What do I need to add in the class to draw something using GDI+ or whatever way that might be the best. I just want to draw some circles or rectangles or lines onload or onbuttonclick. I have searched all over for some EASY samples of this, but no there are only expert solutions that performs 1000 operations more than I really want to do and which also makes the code VERY hard for an inexperienced programmer to understand.
Any help is appreciated, thanks in advance.
Regards,
Hmmkk
|
|
|
|
|
Oooh... I just figured it out... but without using GDI+...which I eventually want to learn and be able to use properly, so I still want help with this.
The way I solved it was by adding an protected: virtual void OnPaint(PaintEventArgs * pe) to the SimpleForm class... I guess windows has that name on default and understands what to do automaticly? (Am I right?)
Also when this finally worked, I tested some cool OnMouseMove stuffs, it worked too so now I get projectiles of lines drawn from every corner of the work when moving mouse
Awell, so the problem now is mainly, how to send for example X and Y cordinated to another function, ex on some timertick, move the rectangle 1step to the right. I might have a solution myself for this, but any "expert" solution so I learn it the proper way is appreciated.
And of course also, how to implement GDI+ into this? I have tried to include it but I get alot of errors.
Thanks.
Regards,
Hmmkk
|
|
|
|
|
I just happen to be reading this terrific book by Chris Sells, and he has a chapter entitled: Drawing Basics (about 50 pages long).
Anyway, he starts out with this:
"...the System.Drawing namespace is implemented on top of GDI+ (Graphics Device Interface+), the successor to GDI. The original GDI has been a mainstay in Windows,...
GDI+ is a Win32 DLL (gdiplus.dll) that ships with Windows XP,... GDI+ is also an unmanaged C++ class library that wraps gdiplus.dll. System.Drawing classes share many of the same names with the GDI+ C++ classes,..."
"No matter what kind of drawing you're doing, the underlying abstraction that you're dealing with is the Graphics class from the System.Drawing namespace."
In your form class's constuctor C.Sells recommends using code like this:
Graphics g = this::CreateGraphics();<br />
Once you have instantiated a Graphics object, there are numerous drawing calls you can make (these are quite simple).
This is the listing of members to the Graphics class over at the MSDN site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdrawinggraphicsmemberstopic.asp[^]
You can always override the OnPaint event, but, using the Graphics class properties and methods gives you more flexibility (and can be used anywhere in your Form class code). Calling Invalidate, Update, or Refresh on the Graphics object will fire the OnPaint event (among other things).
|
|
|
|