Problem error LNK2005:

[Woodylepic]

Just for clarification... instead of this:

bool CPylon::IsSequenceValid(int inputInteger)
{
   // your code here
   return true;
}

you have this in your cpp?

bool CPylon::IsSequenceValid(int inputInteger)
{
   // your code here
here it is
bool CPylon::IsSequenceValid(int index) {
    if (index<0 || index >= numSeq) return false;
    SelectSequence(index);
    return curSeq->valid;
 
 
   return true;
}

If so, you'd have to replace it with this:

bool CPylon::IsSequenceValid(int inputInteger)
{
    if (inputInteger<0 || inputInteger>= numSeq) return false;
    SelectSequence(inputInteger);
    return curSeq->valid;
}

regards,
Face

int CPylon::GetSequenceType(int inputInteger)
h file
virtual bool SetParamBol(int inputInteger, bool value);//devolver bool que indica si ya ha terminado na mas. , PylSequence *caller = NULL);


I have change all the int index by (int inputInteger) on both h file and cpp and nothing change I got the same error

1>PYLONMFD.obj : error LNK2019: symbole externe non rsolu "public: int __thiscall CPylon::GetSequenceType(int)" (?GetSequenceType@CPylon@@QAEHH@Z) rfrenc dans la fonction "public: void __thiscall PylonMFD::selectPrevParam(void)" (?selectPrevParam@PylonMFD@@QAEXXZ)

 

[agentgonzo]

OK, that's a different error. The linker's complaining that it can't find the int CPylon::GetSequenceType(int) method in your cpp file.
Is your cpp file included in the project?

 

[Woodylepic]

Yes all the cpp was there like I said this program was old and I suspect that the int was not correct how but I not figure out how to chthis code to work ?

int CPylon::GetSequenceType(int index)
h file
virtualbool SetParamBol(int inputInteger, bool value);//devolver bool que indica si ya ha terminado na mas. , PylSequence *caller = NULL);

 

[agentgonzo]

I don't know why you think the int is incorrect. It's one of the default datatypes and shouldn't pose a probelm.
All we can really say is what we've said before. The linker is expecting to find a method that fits the declaration that you have in the header file (int CPylon::GetSequenceType(int)). It has found this prototype in the header file, which is why it is not a compilation error, but the linker cannot find the compiled version of this function (that is compiled from the cpp file).

 

[Wishbone]

SetParamBol or SetParamBool, 'tis the question: Maybe it's nobler in the mind to suffer the typos and lapses of outrageous typing...

 

[Woodylepic]

all h file and cpp was include and supposed to be correct ?:huh: you said that the linker can't not find the cpp file ?:huh: I will check but I not think that this is the trouble thank you.

 

[agentgonzo]

No, the linker can't find the function.
The compiler compiles the individual cpp files into object files (collections of variables and functions).
The linker links these object files into an executable (or library). In honesty, I can't think what's wrong with it as the method appears to be there and fine in the cpp file, yet the linker is still complaining.

 

[Woodylepic]

I have try this "Face" but its not working I'm a little bit tire and I have not time to get this working so If you wont I can send you the source code. If some one wont to recompile it Gazza will put your name in is credit name in is pdf.

 

[Face]

I have try this "Face" but its not working I'm a little bit tire and I have not time to get this working so If you wont I can send you the source code. If some one wont to recompile it Gazza will put your name in is credit name in is pdf.

Well, we could do it like this:

1. You send the complete source as ZIP to me (PM or Email)
2. I'll try to make it compile.
3. If finished, I send you the complete source with fixes back again
4. For credits, do as you see fit, I don't mind. I will not re-distribute the ZIP, either.

 

[Face]

Ok, since Woodylepic has not commented yet on the solution, I think I should write a small resume about what I did in this regards.

After Woodylepic sent me the code as ZIP archive, I noticed dbeachy1's note in it about Camelopardis putting the code under GPL. Since the ZIP contains previous versions of the code, but in a folder-copy-versioning way, I thought it would be good to have it all in a versioning system like Mercurial.

So I went ahead and converted it to a repository here, trying my best to reconstruct author and date information. Notes were sent to Woodylepic and dbeachy1 about the repository being public (GPL would allow this, anyway). I didn't try to contact Camelopardis, as his account is inactive since late 2009. If he his still around and objects this, please drop me a note. If you find something in the history to be incorrect, please drop me a note, too.

After the conversion to HG, I created a Visual Studio 2008 (VS9) solution with two projects for the plugin and the MFD. And I think there was the problem with the compilation as mentioned in this thread: inter-DLL function calling.

The MFD part is calling class functions that are implemented in the plugin DLL. Of course the linker can't find the entry-points to this functions without proper exporting/importing. Normally I circumvent this problem by making pure class-functions virtual, as this would put the entry-points into the object struct itself, thus allowing the linker to find them.

But unfortunately, this simple trick is of course not working with static class-functions (that are called, too), therefore I'd have to create exporting and importing declarations. As I'm not sure if the directory structure setup (/modules/pylon/pylon.dll - /modules/plugin/pylonmfd.dll) makes this late-binding feasable in terms of path-loading the appropriate DLL, I simply compiled the class implementation right into the MFD as well. Not beautiful, but it works.

I added my changes as well as updated binaries (DEBUG for Orbiter 2010 P1) to the above mentioned repository. If you have additions and don't want to fork it on Bitbucket, just send me a patch and I'll put it up...

regards,
Face