|
There are multiple possibilities. How do you select which one to use? Does the final targets are known beforehand. If not, how do you decide which one to use?
In your case, we can see that D is a final target because D is never on the left side of the pair. But for the other sequence, one could start with Y and end with Y (since it is a loop).
If the target are knows, then you would be able to build the result by search which item lead to the target and then repeat using the source as the new target (and the final target would be the original target).
Philippe Mori
|
|
|
|
|
If the target are knows, then you would be able to build the result by search which item lead to the target and then repeat using the source as the new target (and the final target would be the original target).
Yes, you are right.
Then, how to implent your idea into algorithm in C++?
|
|
|
|
|
- For each possible target, find immediate source. Add them (each pair) to a result list.
- For each immediate source not equal to the original target, find its own source. Add each pair to the result list.
- Recursively repeat the second step until you don't find any source distinct from the initial target.
You can remove recursivity if you like if you keep track of which pair were processed.
By the way, I assume that none of the source have multiples (immediate) targets.
Philippe Mori
|
|
|
|
|
I have no clue how this happened and how to fix it.
I am getting this error message from the compiler ( VC6.)
<b>“The source files ...cpp and ..cpp are ...both configured to produce ...pch
Project cannot be build.”</b>
I started getting this error on a file I really did not put into my project, so I deleted it.
Than this error “moved” onto a real file and I would like to fix it.
I would be most grateful if some VC 6.0 expert helps me to understand this and/ or how to fix it.
Thanks
Vaclav
-- modified 3-May-12 15:04pm.
|
|
|
|
|
Check the properties on your source files to ensure that only one is configure to create the PCH information.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
Richard,
that is exactly what the error message is saying.
I got that far.
I would not be asking here if I knew how and where to check that.
Vaclav
|
|
|
|
|
Right click on each files and select Properties.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
OK,
we are getting somewhere.
Indeed the ..pch file is in Properties of the offending source.
Now, how to get rid of it.
I suppose deleting it ( from the debug directory) won't work since it is obviously being generated by ...??
|
|
|
|
|
I think I found it.
Somehow all files were set to build precompiled header.
Thanks Richard for getting me started, I really appreciate your help.
Vaclav
|
|
|
|
|
Happy to help. I wonder how they all got set like that?
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
i have this code:
FILE* file;
file=_wfopen(L"fisier.txt",L"w,ccs=UNICODE");
fwrite(text.c_str(),sizeof(wchar_t),wcslen(text.c_str()),file);
fclose(file);
the problem I'm having is that the file "fisier.txt" is saved on desktop and not where my app is.
How can I change the location from VS 2005 so that the file is created in my app's directory?
I don't want to change the path in the code.
|
|
|
|
|
Use the Common Item Dialog[^] to allow the user to specify the path to the file. Or use one of the Shell functions[^] that provide the user's application data path.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
I'm thinking is some setting is Visual Studio but I cannot find it.
And how come it saves the file on desktop?
I cannot see any logic in that.
|
|
|
|
|
dliviu wrote: I'm thinking is some setting is Visual Studio
Why are you thinking that?
dliviu wrote: And how come it saves the file on desktop?
The desktop is just a folder like everywhere else.
dliviu wrote: I cannot see any logic in that.
The logic is missing from your code. If you do not tell Windows where to store your files then it is going to have to make a decision based on 'best guess'.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
There must be a setting because i downloaded a vs c++ project which saves the files created with fopen in the app's directory and not on desktop!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
|
|
|
|
It's nothing to do with Visual Studio, it depends on the environment of the executable program (which does not necessarily run inside Visual Studio). And a single exclamation mark is enough to make your point!
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
and how can I tell windows where to store my c++ created files??
|
|
|
|
|
Do as I suggested and use one of the options I already told you about, and provided links to.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
This question is non-sensical. Why would Windows care where they are stored?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
"The desktop is just a folder like everywhere else."
Would it be more correct if we say that the "desktop" is the parent / main (Windows) application and that is why the file goes there if no path is specified?
Just curious.
Also it seems "illogical" / awkward to open a file ( on desktop ) and than save it elsewhere.
But - whatever floats your boat.
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: Would it be more correct
I was trying not to complicate things, saying "it's just a folder" was the simplest explanation I could come up with.
Vaclav_Sal wrote: Also it seems "illogical" / awkward to open a file ( on desktop ) and than save it elsewhere.
Sorry, I don't understand what you are saying here.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
You can always get the path from where the exe is running using GetModuleFileName and extract the required path and append it in the wfopen function for the file name .Then your file should be created in the app directory itself.
Though this is a strange behaviour that you are getting, this is just another way for achieving what you want.
You talk about Being HUMAN. I have it in my name
AnsHUMAN
modified 3-May-12 8:52am.
|
|
|
|
|
Thank you for your answer.
This is indeed a strange behaviour.
I will use GetModuleFileName.
It seems that I have no other option.
|
|
|
|
|
dliviu wrote: This is indeed a strange behaviour.
No, this is quite normal.
dliviu wrote: It seems that I have no other option.
You have quite a few options, two more of which I suggested above.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
There is a 'working directory' setting which I believe is on the debug menu, or some such. It is where you can specify the exe to be debuged and any arguments too.
This might change the behaviour, but I am guessing at some point you will want the app to run outside the debugger, so you are going to have to write code to set the path where the file is saved.
==============================
Nothing to say.
|
|
|
|