|
Well - apart from anything else, the code doesn't build. If you can't compile up BaseClass the compiler can't match up the base call. You need to change your reference to s1 to m_s1 in the member declaration.
protected string m_s1;
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Well, the examples I gave are simple that - examples. The code I'm working on does compile except for the error I've mentioned which has nothing to do with data members. I did "fix" that, but as I said, that's not the problem in the actual code.
Another thing I've noticed... Intellisense doesn't present me with a list of parameters when I type :base(.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Then post the definition of the classes (down to constructor level only).
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Look at my modified response that you just replied to (about intellisense).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi John,
please don't modify the original messages without a trace, it makes it
impossible to understand the chronology of the thread.
if Intellisense does not show you either did something wrong (like missing a
file in a project) or VS just got confused; so I would suggest you try deleting
the bin and obj folder(s) (except for your own additions to them), close and
reopen VS, and rebuild all.
What's your VS version?
Hope this helps.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Luc Pattyn wrote: please don't modify the original messages without a trace, it makes it
impossible to understand the chronology of the thread.
If you read the thread, you'll understand the chronology. I simpky forgot to put a m_ in front of a variable name.
Luc Pattyn wrote: f Intellisense does not show you either did something wrong (like missing a
file in a project)
Not that I can see - the line class MyClass: BaseClass is correctly syntax highlighted, so I know it sees BaseClass.
Luc Pattyn wrote: so I would suggest you try deleting
the bin and obj folder(s) (except for your own additions to them), close and
reopen VS, and rebuild all
Already did all that - intellisense still doesn't show the parameter list, and the compiler still chokes and claims there's no overloaded member with the correct number of arguments.
As you can see by the code posted in the original message, there doesn't appear to be anything wrong.
I've tried changing the base constructor to be protected
I've tried adding a default constructor.
I've even tried adding :this() to the constructor in the base class.
I'm out of ideas.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Could it be that the derived class is in a namespace and the base class isn't?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Nope - that shouldn't affect it. Without actually seeing the code we're really shooting in the dark with this. Some things to look at though:
The accessibility level of the constructor shouldn't be an issue if the base class has a protected constructor.
If the base class is in a separate project, try building that project on its own - problems compiling that project will have an effect on the derived class (which means that you will see the issue with Intellisense not picking the definition up).
A silly one, and one I suspect you've already ruled out - the parameters must be the correct types between the call to base and the constructor in the base class.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Check out the last message in this thread. :/
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
SOLVED
Here's what I found.
I have a solution with a project in it that represents an application.
I've added a second project to the solution that represents a DLL (asembly) to be used by the application.
I added a new class (my base class) to the solution, and VS2005 placed the cs file into a folder called Solution Items.
In the assembly, I need to derive from the base class. The only way I could derive from the class was to "add existing item" and select the file.
Unbeknownst to me, the IDE created a copy of the file int he assembly's folder.
I was still editing the copy of the base class that was in the Solution Items folder (which had the desired constructor), but the assembly project was compiling its own local copy. When I added the constructor to the local copy, it compiled fine.
So, do I have to compile the base class into it's own assembly in order to derive from it without this file duplication problem?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Nope - remove the one from the Solution Items folder. Basically, that's an entry that doesn't form part of an assembly (and won't be compiled). You could use a separate assembly for it, but based on your description here I don't see that you really need to do this.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Well, this is going to be used by more than one aassembly, so should it be in it's own assembly? (What a hassle...)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
If it's to be used by more than one assembly then yes - that's the best option.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Many thanks.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi guys,
I am calling a managed dll build in 2.0 from a vb 6.0 application, the dll runs well under clr 2.0 but the vb application breaks.
I was previously using managed dll built with 1.1, and that was working fine. i have framework 1.1 and 2.0 installed with windows server 2003.
can u guys tell me what could be the problem??
Thank You.
Saswat
|
|
|
|
|
What do you mean break? Where is the error appearing? What happens when you debug?
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hi,
i am using 4 dlls all build with .net 2.0 and calling them from vb application. the vb application calls the dlls then when control returns to vb app again then it stops unexpectedly. i think it is compatibility issue. but dont know how to resolve.
Thanks.
Saswat
|
|
|
|
|
Hi,
all modules in a single app should be based on a single Framework version;
you should not expect a 2.0 EXE to run happily with a 1.1 DLL or vice versa.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
yes i know that and that is not the problem. all the dlls are built with 2.0 and vb calls them. control switchs between managed and unmanaged code. and the vb application stops in between unexpectedly.
Thanks.
Saswat
|
|
|
|
|
Hi,
my application grabs an image from a camera. The image might be quite big such as 50MB.
The image is represented as a bitmap image with BITMAPINFO as the header and the image data right after that.
I have a COM object (writen in native code) which my WPF application uses that holds the image.
This COM object can return byte* as the pointer to the image.
Is there any way to use the .NET image component or other .NET component that will get just the pointer to my image (byte*) and without copying the whole image to .NET component?
Thanks,
Dudi
|
|
|
|
|
Dudi Avramov wrote: Is there any way to use the .NET image component or other .NET component that will get just the pointer to my image (byte*) and without copying the whole image to .NET component?
Nope. AFAIK, the image data must be copied into an object (preferrably decending from Image) on the managed heap for it to work.
|
|
|
|
|
Hi!
I need create a dll in VC++ and use in C#... But i can´t make this work
I made a new project:
New project > Visual C++ > CLR > Class Library
And write the files above, but when i import to C#´s project i can´t see the "test" function
So, anybody can help me?
Thank´s for the attention!
//########[Tsai7.cpp]########
#include "stdafx.h"
#include "Tsai7.h"
#include "math.h"
using namespace Tsai7;
public class Tsi
{
public: int test(int valor)
{
return valor;
}
};
//########[Tsai7.cpp]########
//#########[Tsai7.h]#########
#pragma once
using namespace System;
namespace Tsai7 {
public ref class Class1
{
public:
test(int valor);
};
}
//#########[Tsai7.h]#########
Rui Sousa
|
|
|
|
|
Have you got this working?
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
VS2005/.Net 2.0
Windows desktop (as opposed to a web app)
I am writing a service in which I want to support one or more ways to perform a specific task. I intend to write one or more DLLs (assemblies I guess you call them), each of which will implement a common interface, but with the goal of accomplishing the task. The desired outcome is to allow development of additional DLLs without having to change/recompile the service.
Each DLL will have a class, and optimally, that class would have the same name in each of the DLLs.
Finally, as a DLL is needed, the application/service would load the DLL, and then unload it when it's no longer needed.
If I can do this, can anyone point me to a place that describes how?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
You'll need to use reflection ... you load up the assembly, then load up each type in the assembly. You'd normally use a custom attribute to label your plugin classes for easy "spotting" of them  although base classes and interfaces can be used too.
The only way to unload an assembly is to unload the entire AppDomain, so if you really need this functionality then you need to spawn new AppDomains and load the plugins into them. THis has advantages and disadvantages. For the pro's you have the fact you can unload the assemblies and you can set the security on the AppDomain to be very restrictive and so use it as a sandbox. The con is that anything crossing an AppDomain boundary has to be serialized and so incurs a performance penalty.
If this is a long running service and there are large number of plugin changes, or you will have "untrusted" plugins, then you'll probably want to go the AppDomain route. If the service will be restarted occasionally or there will only be occasional plugin changes and you fully trust them then loading in to the current AppDomain would be best.
I don't have any articles to hand that cover all these areas as I've been dabbling with this stuff for a few years now and know enough just to look up the exact info when I need it. If you search around though you should find a good body of info, and with the pointers I've provided you can hopefully avoid some of the pitfalls that often appear (with unloading).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
