|
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.
|
|
|
|
|
I know about the working directory option.
I've set it but to no avail.
I'm gonna use GetModuleFileName.
Thanks!
|
|
|
|
|
dliviu wrote: the problem I'm having is that the file "fisier.txt" is saved on desktop and not where my app is.
It's the difference between a relative path vs. an absolute path.
"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
|
|
|
|
|
Hello Friends
Critical Situation:
Two application are in MFC.Using Document View Architecture.
First Application saving a file using Serialize.[no idea about File Format].We dont have this application code.
Second Application is also saving a file using Serailize of same extension tht we created in first application.[ knows the format ].
Now,when i am trying to Load old Files into new Application,it crashes,As I am assuming File format is Different.Is there any way If I can Get Format of Old Files so that when i load up in new application,it doesnt crash?
Any Ideas?
Regards
Yogesh
|
|
|
|
|
You can use a HEX editor to read the file and try to figure it out, or try and find the format description by getting the source code of the application, or talking to the people who do have the source code. Either way there is no tool that I know of that can tell you the format.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
I dont have any option.And reading thru Hex file Editor and figure out is not possible.
Thanks Richard.
Regards
Yogesh
|
|
|
|
|
Why not use a different extension for your new files?
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
