|
What is a C# control?
If you build a library using C#, then all public classes in
that library can be consumed by any of the .NET languages.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi,
Thanks for reply.
Mark Salsbery wrote: consumed by any of the .NET languages.
I want to add my 'Windows Form Control Library' (i.e. VC#.Net 2008 ActiveX Control) in my MFC Application of VC++.Net 2008.
Thanks & Regards,
Aniket A. Salunkhe
|
|
|
|
|
Aniket Salunkhe wrote: i.e. VC#.Net 2008 ActiveX Control
I don't know about ActiveX controls, but an ActiveX control
written in c# should work just like any other ActiveX control...
that's what they're designed to do 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
Is there any way to design '.ocx' in VC#.net?
Because I can't register '.dll' VC# activeX control.
Thanks & Best Regards,
Aniket A. Salunkhe
|
|
|
|
|
Hi all,
I found something to work with MFC application,
http://msdn.microsoft.com/en-us/library/b1kyh79x.aspx[^]
Thanks for your support too.
Now I am trying to integrate it with my MFC Application & Control, as I want to add mutiple control dynamically in MFC Dialog.
But I appreciate any other better suggestions.
Thanks & Best Regards,
Aniket A. Salunkhe
|
|
|
|
|
I guess I'm confused - do you need an ActiveX control or a
Windows Forms control?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: ActiveX control or a
Windows Forms control
What is difference between these 2?
I want to create a UserControl in C#. eg Analog Clock Control in C# with some properties.
|
|
|
|
|
|
Any control you create in C#, or even VB.NET, can be used by the other .NET languages. You have to add a reference to the .dll containing your control.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Hi,
Thanks to you both for reply.
Paul Conrad wrote: can be used by the other .NET languages
I am using VC++.Net 2008, but I am doing MFC Application.
Paul Conrad wrote: add a reference to the .dll containing your control
How to add reference to .dll in MFC Application using VC++.Net 2008?
And even after adding reference in MFC Application, how to add/use custom ActiveX Control?
Scenario is,
ActiveX Control in VC#.Net 2008 as 'Windows Form Control Library'.
Application in VC++.Net 2008 as 'MFC Application' (as I am doing DirectShow programming in it).
When I try to add my ActiveX Control through 'Insert ActiveX Control', it doesn't show it in that list.
When I try to register the control using 'regsvr32.exe' it shows error as, DllRegisterServer Failed
Thanks & Regards,
Aniket A. Salunkhe
modified on Friday, September 19, 2008 3:32 AM
|
|
|
|
|
Aniket Salunkhe wrote:
How to add reference to .dll in MFC Application using VC++.Net 2008?
And even after adding reference in MFC Application, how to add/use custom ActiveX Control?
That's really fun. I suggest you google that one, it's involved and there's articles how to achieve it.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Loading a managed C++ dll from a non-managed executable works as expected when it is loaded from a local directory. However, when loading the same dll from the same executable over a network path a FileLoadException is thrown: "Failed to grant minimum premission requests". Is there a way to decrease the DLL's security or must the computer's settings be changed in order for things to work correctly?
Thanks!
Doug
|
|
|
|
|
As far as I know you can do this through the manifest file.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
The managed C++ dll is strongly named and the C++ program has a reference to it. I thought that should take care of any such issues. What else do I have to do?
Doug
|
|
|
|
|
I don't think strong naming it is enough. That will help the load time and allow you to register it in the GAC, but it doesn't affect the security policies about running from a network location. There is something you can add to the manifest file which says that it's safe to run from a network location, I just don't remember what it is offhand.
You can also try using fuslogvw (http://msdn.microsoft.com/en-us/library/e74a18c4.aspx[^]) to help identify what the loader is trying to do.
There is also some information here[^] that might help.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
 I have some unmanaged code that invokes a callback function to display a series of bit map images in a picturebox in a managed GUI.
The unmanaged code is called from a worker thread, it loops, creating the bitmap images and passing the image address and a serial number as parameters to the callback routine. When all the images have been displayed the unmanaged code finishes, and the worker thread terminates.
The callback routine copies the bitmap to a stream and uses invoke to get the gui to display the image.
The images are set to display at 1/second.
I thought I had everything working nicely, but after about 30 seconds everything dies and a 'Buffer Overrun' message is generated.
The error is generated when/in/by calling the callback routine. If I don't invoke the callback all is ok. If I invoke the call back but do nothing except return immediately everything still goes wrong after about 30 seconds.
If I make the delay 10 sec everything runs happily for about 100 seconds, but then dies again.
I've reduced the code to a simple skeleton, but still get the crash.
The unmanaged code is called using a delegate, GCHandle, and Marshall::GetFunctionPointer.
I suspect something to do with garbage collection, or the lifetime of a thread, but I'm tearing my hasir out over this.
Can anyone suggest what I may have overlooked?
Bob Swan
|
|
|
|
|
Is the buffer overrun message because of an exception?
If so, what code is executing at the point the exception
is thrown?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
None that I can see.
Normally the error is flagged when the callback is returning to the unmanaged code. The .net code that does all the cleanup and overrun checks as part of the return statement detects that the marker bytes have been modified.
I have run the code with visual studio monitoring the memory locations, (a breakpoint that continues when triggered) I can see that the markers are being overwritten. I can see that the data corrupts, but not what is doing it. This occurs even when all I am doing is calling the callback from a loop, and that does nothing except return.
In the original unmanaged code there were number of cout statements
which tended to flag the error, especially if you piped several items to the output. But I believe that was just because they also ran code that performed clean up checks. They also don't appear in my simple system.
I have ruled out the hardware problems as this occurs under Windows XP + studio 2005 or Windows 200 +studio 2008 Express.
I feel sure its something stupidly obvious.
BoB Swan
|
|
|
|
|
Well I've found one stupid error that corrects my simple version of the program.
when declaring the callback function pointers I had failed to define the calling convention as _stdcall
See stupid, maybe not obvious.
Bob Swan
|
|
|
|
|
|
ref class MyDummy
{
public:
void SayHelloTo(String ^str)
{
Console::WriteLine(str);
}
~MyDummy()
{
Console::WriteLine("Destructor called");
}
};
int main(array<System::String ^> ^args)
{
MyDummy ^myDummy = gcnew MyDummy();
myDummy->SayHelloTo("Name1");
delete myDummy;
myDummy->SayHelloTo("Name2");
return 0;
}In the above code, I am deleting handle myDummy after first call to SayHelloTo method. I can see that the destructor is getting executed but the next call to SayHelloTo after delete, worked correctly. How this can happen? After destruction, how it can be used again?
Any help would be great
|
|
|
|
|
You should make it a habit to set your handles to nullptr after explicitly deleting them.
delete myDummy;
myDummy = nullptr;
myDummy->SayHelloTo("Name2");
The explicitly deleted object instance may stick around for a while before the GC actually releases the resource.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
George L. Jackson wrote: The explicitly deleted object instance may stick around for a while before the GC actually releases the resource
But AFAIK, when delete is used, we are not waiting for GC to collect the object. We are doing deterministic destruction, isn't it?
|
|
|
|
|
N a v a n e e t h wrote: But AFAIK, when delete is used, we are not waiting for GC to collect the object. We are doing deterministic destruction, isn't it?
If the type was allocated using gcnew you are waiting for the GC to collect the object.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
According to this[^], the call to delete will call the types destructor if it has been allocated with gcnew. As a result, while the object has been disposed it may still be around if the GC hasn't run a collection cycle yet.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
