|
You could add a TextBox to the form and show the message in that TextBox.
|
|
|
|
|
Uhm, the parent form can't have the error message box on it.
I have a class called ErrorScreen displaying error message. Then there is the main menu Form1 (1). the Form invokes function classes(2). These function classes invoke more basic classes(3). These basic classes invoke the ErrorScreen class. But the ErrorScreen instances displays strangely in front of the main menu. The error icon, the text, and the button are not displayed, but empty holes on the ErrorScreen. If the ErrorScreen instances are replaced with Forms::MessageBox::Show(),the error messages are displayed correctly. But I need big size button displayed on the error message screen, therefore I need use the ErrorScreen class created myself.
What senarias I shall look into in order to display those ErrorScreens correctly?
|
|
|
|
|
When I add my assembly to the Toolbox via the Tools | Choose Toolbox Items... dialog, the components in my assembly are added to the General tab. How can I tell Visual Studio 2005 programtically to add my components to some other tab ?
I was expecting some attribute placed before the component class which I could set to tell the Toolbox on which tab I my component would be placed, but I could not find such an attribute. But I am sure their must be some way from within my assembly by which I can direct the Toolbox to place a given component on a particular tab, which would be created for it if the tab does not already exist within the Toolbox.
Edward Diener
|
|
|
|
|
Hello,
I have the following 'effect' with my application, implemented with Managed C++ on Visual Studio 2003.
If I start the application on some computers, MessageBoxes (System.Windows.Forms) are popping up as they are expected to. They show a button and they have a size depending on the message they should show. Only that the text doesn't show. Neither the message nor the OK on the button. The Titlebar is shown correctly. What is causing that kind of problems?
I tested the effect on several PCs already. They all have Windows XP and .NET framework installed (in the correct version). I'm not sure, but I think, the PCs that it's not working on do not have VS2003 installed. However it's working on other PCs that also do not have VS2003.
I made a test application that only gave a MessageBox. It's showing correctly on the development PC but again not on the TestPC(s).
Is it a regional problem? Is it a library problem? Shouldn't those standard library functions (as the MessageBox) not work anywhere. I would doubt if it was my selfmade Messagebox.
Any idea?
Thank you in advance,
dawei
-- modified at 9:38 Wednesday 23rd August, 2006
|
|
|
|
|
Are you passing string literals to the messagebox call? Or are you passing a variable? Try using a constant or a literal - that'd help narrow down the point of error.
|
|
|
|
|
Hi,
yes, I thought of that as well. So I made the test sample using both a constant value ("STRING" as well as S"STRING") and a variable.
Anyway it happens.
I continued my testing and interestingly, although development and testing were made on XP machines, setting the compatibility mode of the application on the test machine stops that error from appearing!
On another website they say that they had similar problems because of a bug in McAfee Anitvirus 8.0. We use that program but our administration always updates that kind of tools. So everyone should have the same version. Hence, either it should work or not work on both machines.
Funny...
Thanks for your answer! It's a strange little problem, but I am happy that at least I have a solution- although not satisfying. If you know the answer, it might also be interesting for other people!
best regards,
dawei
|
|
|
|
|
Is there any way using unasfe (non-managed) raw CPP to temporarily elevate access to s specific function like you can in managed code?
|
|
|
|
|
Ray Cassick wrote: Is there any way using unasfe (non-managed) raw CPP to temporarily elevate access to s specific function like you can in managed code?
Perhaps you could use AdjustTokenPrivileges.
|
|
|
|
|
hi,
i am writing a dll in MC++ for using from C#.
I have a pair of strings and object of class say 'Record', <<string,record>> which should be passed to a dll function. i have learned that SortedList collection class can be used in this scenario. but i dont know how to create SortedList object in C# and how to receive it in managed c++ function. Please guide me on this.
thanks in advance,
Abin 
|
|
|
|
|
Can this link help?
Best,
Jun
|
|
|
|
|
yes Jun , it was a very good article
thank u very much ! 
|
|
|
|
|
I have an unmanaged project that I will to compile in Managed C++. Is it just a matter of adding the /clr switch to the compiler options in VS2005/Project/Properties/C++/Command Line?
Thanks
alias47
|
|
|
|
|
Yes, that is, in theory, correct. However, I'm not sure if that will actually expose anything to the CLR ( if it's a dll ), it will simply make the .NET framework available to your application.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
So, is the solution to create Managed C++ wrapper for each exported routine?
|
|
|
|
|
alias47 wrote: So, is the solution to create Managed C++ wrapper for each exported routine?
What exactly is your scenario? That might help people give a more suitable answer.
|
|
|
|
|
If you want to export C++ methods to be exposed to .NET, then probably, but as Nish said, some more info would help.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thanks for your help guys. I have a c++ MFC DLL, written in Visual c++ 6.0. This DLL is currently called from an Excel VBA application and has some callbacks back to Excel in it. I have rewritten all of the VBA code into a non-VSTO shared managed add-in in c#, written in VS2005. I want the managed addin to call the c++ DLL the same way VBA used to. In its current form if I add a reference in the managed addin to the c++ DLL, a message says that it is not a valid assembly or COM component. If I compile the c++ DLL in VS2005 without the /clr switch it makes no difference, except that the Excel VBA application does not work anymore. If I try to use a DLLImport with the c++ DLL, I receive a "memory may be corrupt" message. The c++ DLL exports about 30 functions, as specified in a DEF file. Do I need a Managed c++ wrapper around these functions to access them from C#. Is there some boilerplate code to use? Does it depend on what the functions are?
Sample of the first function exported:
extern "C"<br />
short int DLLFUNC FunctionX()
DLLFUNC defined:
#ifndef DLLFUNC<br />
#ifdef WIN32<br />
#define DLLFUNC _stdcall<br />
#else<br />
#define DLLFUNC WINAPI _export // DLL functions are FAR PASCAL _export<br />
#endif<br />
#endif
Regards
alias47
|
|
|
|
|
Hello,
alias47 wrote: Do I need a Managed c++ wrapper around these functions to access them from C#?
Yes.
alias47 wrote: Is there some boilerplate code to use?
Check out this CP article: Using Microsoft Interoperability Libraries.
alias47 wrote: Does it depend on what the functions are?
No.
Best,
Jun
|
|
|
|
|
I *really* need someone to help me out.. I am wasting heaps of time trying to access this unmanaged c++ DLL from C#. It is a showstopper.
Let me check my understanding on a few issues:
IJW: Does IJW mean "Just compile unmanaged c++ code in VS2005" and then reference the unmanaged DLL in C#. If so, this does not work.
COM: How can I tell that the unmanaged c++ DLL is not COM-based? (Apart fromn the message I receive when trying to reference the DLL from C#)
PInvoke: When using this from C# to the c++ DLL, I receive a message about corrupt memory. Is this because the type of the argument is incorrect? In c++ the type is IDispatch. In C# I am passing an object type. In fact it is an Excel.Application type which is being cast to object that I am passing. Will this PInvoke technique possibly work if I pass a different type?
The article http://www.codeproject.com/useritems/usingcppdll.asp seems comprehensive, but I wonder whether I need to do any/all of this.
The unmanaged c++ DLL works prefectly currently with Excel. I guess that is because excel is itself unmanaged? Is the approach found http://groups.google.com/group/microsoft.public.dotnet.languages.vc/browse_thread/thread/8c538b0e1bbf020b/cac8b5f6bb7932ef%23cac8b5f6bb7932ef
too simplistic?
Surely there is an app in vs2005 that autogenerates the managed wrapper? Surely? Like http://www.codeproject.com/dotnet/NativeWrapper.asp
Regards
alias47
|
|
|
|
|
alias47 wrote: IJW: Does IJW mean "Just compile unmanaged c++ code in VS2005" and then reference the unmanaged DLL in C#.
The first half is correct. IJW only compiles unmanaged code and leave it in the unmanaged context. It won't make it callable by managed code, meaning you can't add unmanaged DLLs as references to managed projects.
alias47 wrote: COM: How can I tell that the unmanaged c++ DLL is not COM-based? (Apart fromn the message I receive when trying to reference the DLL from C#)
Your header and source files should indicate COM interfaces and their implementations. If your modules has implemented IDispatch, then the module is a COM-based. Check this site for how to PInvoke COM in managed C++.
alias47 wrote: PInvoke: When using this from C# to the c++ DLL, I receive a message about corrupt memory. Is this because the type of the argument is incorrect? In c++ the type is IDispatch. In C# I am passing an object type. In fact it is an Excel.Application type which is being cast to object that I am passing. Will this PInvoke technique possibly work if I pass a different type?
Probably because the first two issues have not been resolved properly.
Best,
Jun
|
|
|
|
|
Jun Du wrote: Your header and source files should indicate COM interfaces and their implementations. If your modules has implemented IDispatch, then the module is a COM-based. Check this site for how to PInvoke COM in managed C++.
Hey Jun,
he just has an MFC DLL with some exported functions. I don't think it's a COM DLL. So all he seems to need is a bunch of DllImport definitions.
|
|
|
|
|
That is what I first thought too. Actually on his another discussion thread on the same topic, he said it's not a COM module. But somewhere in this thread, he indeed mentioned IDispatch interface. I guess he needs to know what he is asking first.
Best,
Jun
|
|
|
|
|
Jun Du wrote: I guess he needs to know what he is asking first.
Yes, he does.
|
|
|
|
|
alias47 wrote: In its current form if I add a reference in the managed addin to the c++ DLL, a message says that it is not a valid assembly or COM component.
You don't need to add a reference. You can call imported functions from C# using the DllImport mechanism. That's all you'd need for your scenario.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
