|
Perhaps adding the path to the .lib file for the DLL into your project will help with that.
|
|
|
|
|
waldermort wrote: I get unresolved external symbols for the three functions the dll uses (located in the main exe).
Ah, you said they were using functions in another DLL ... you can't link to an EXE, so you will get unresolved externals.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I figured that what I was trying to do was impossible, so instead I stripped out the functions and added them to the dll. In the dll I then find the window handles for the controls and proceed as normal.
|
|
|
|
|
waldermort wrote: In my origional code, I pass the class a pointer to another class (simply to control a progress bar on the main window).
Bad design.
waldermort wrote: If I do this in the dll I would need to include all the source files for the second class.
Simply post a message to the thread that owns the UI component. This is typically the primary thread.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Bad design.
I wouldn't call it a bad design when it isn't yet complete. Origionaly I started out with one class, after adding code I later had to break it into 5+ classes. I am now at the stage where I make the exe smaller and smooth out all these rough edges.
|
|
|
|
|
waldermort wrote: I wouldn't call it a bad design when it isn't yet complete.
Insomuch that one class should not have so much internal knowledge of another. It's the weak-coupling/strong-cohesion mindset. Should the progress control ever be changed to something else, those places that directly interface with it would need to be changed.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yes, but the cost of decoupling can be much greater than the cost of having to change all users of the class.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
dear all,
i have solved my problem already, but with a way i don't like at all. but i couldn't find a working method in the time i had to do the job.
here is the topic :
i have a program (say v1.0) which serializes its objects into binary files.
but this program has grown up to v2.0, and the objects serialization scheme has changed.
both versions were working fine independantly. but the problem was starting when a version was trying to open an object which scheme was of the wrong version. the fact that app v2.0 doesn't read files of v1.0 is normal behavior (it is not supposed to recognize the version of the serialized object).
the thing is that i had to make an external project for the migration.
in the project, i have the sources of the new objects linked as an additionnal source directory in the compiler settings, and the old sources are directly copied in the migration project directory.
but as the objects files/classes remained the same between the 2 version, the compiler complains about types redefinitions.
i had the idea of putting the sets of sources into different namespaces, but i didn't succeed in doing this.
the only solution i found to compile the migration tool was to rename all the types of the old version, ,and appending an "Old" to their name... bad, isn't it ? 
so, i'd like to know you advise for the best design you think of to solve such a problem.
thanks already for your answers.
ps : i'm leaving internet, so, don't worry if i don't answer immediately
|
|
|
|
|
toxcct wrote: the fact that app v2.0 doesn't read files of v1.0 is normal behavior (it is not supposed to recognize the version of the serialized object).
That is an odd requirement. Typically, backwards compatibility is a desirable feature, and something that is not backwards compatible is not desirable.
MFC provides the schema version when you are serializing objects. Typically, you just check the schema before you read the data and then use the correct version of the read operation (the write operation is always done with your most up-to-date version, so that doesn't matter).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
i know that Zac, but that's not the question...
|
|
|
|
|
I realize that. My response was suppose to be more of a question: What is the purpose in having a non-backwards-compatibly serialization scheme for these classes that are apparently designed for the same purpose?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: What is the purpose in having a non-backwards-compatibly
laziness maybe 
|
|
|
|
|
The thing is, if you fix that, you no longer have this problem to begin with. Being Lazy = More work down the road.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Being Lazy = More work down the road
lol, yes, i'm gonna tell this to the owner of the code...
|
|
|
|
|
You should. Dumb decisions are made all the time because some programmers are too lazy to do things right the first time and end up trying to perpetuate that decision by hacking up code to make their lazy code work.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
See this[^] series of articles.
/ravi
|
|
|
|
|
thanks Ravi, i already knew your article, and the software doesn't have problem for the serialization.
the point is much about having the 2 schema classes (so, duplicate classes names) in the same project...
|
|
|
|
|
Ah. It seems I've misunderstood your question.
Are you having problems differentiating between 2 versions of the same class when you read in the data? (If so, versioning the classes [as described in the tutorials] will take care of that.)
/ravi
|
|
|
|
|
nope, i read perfectly the files ((de-)serializing is not the matter at all).
i only fail in having two definitions of a class (in two different files) in the same project...
take this as an illustration of my problem :
MyClassOld.h :
class CMyClassOld {
private:
std::vector<CFoo> m_vecFooList;
std::vector<CFoo2> m_vecFoo2List;
};
MyClass.h :
class CMyClass {
private:
std::vector<CFoo> m_vecFooList;
};
what i want to do is this :
#include "MyClassOld.h"
#include "MyClass.h"
CMyClassOld o1;
CMyClass o2;
the problems curretly is that i have to rename one of the class into SomethingOld to avoid the "type redefinition" compilation error...
see what i mean ?
|
|
|
|
|
Gotcha.
I would take a different tack - use a single class (the latest version, without m_vecFoo2List). When you read the object's version during deserialization, use a local instance of std::vector<CFoo2> to read in the old data and ignore/convert it as required. This way, you only have a single class definition that supports both (and all future) versions.
/ravi
|
|
|
|
|
hum, yes, i see the point.
but what if the new business schema doesn't know its previous versions design ?
how do you think such a migration tool could be done ?
BTW, this is just a guess, for my curiosity, because everything works fine now (even if bad designed) and i think that your latest suggestion is the way to go...
|
|
|
|
|
toxcct wrote: what if the new business schema doesn't know its previous versions design ?
Ouch. That's a serious problem, since you can't do a silent upgrade (or a separate migration) without full knowledge of the old and new schemas.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: since you can't do a silent upgrade (or a separate migration) without full knowledge of the old and new schemas
that's why i was importing both classes version.
well, thanks Ravi, that was helpful  ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
Glad to be of assistance!
Btw, this[^] hack uses the serialization techniques described in my tutorial and is able to silently upgrade all previous 12 versions of its database without any intervention by the user.
/ravi
|
|
|
|
|
I'm including a CComboBox on the first CPropertyPage of a CPropertySheet displayed in wizard mode with the following styles for the property sheet PSH_WIZARD97|PSH_WATERMARK|PSH_HEADER.
The problem is that the drop down from the combo box is being drawn with the watermark bitmap as its background and I can't figure out how to stop it. Apart from anything else this makes it pretty hard to read the combo box text.
I realise this is probably something obvious but any help would be appreciated.
Thanks,
Ewan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
