|
_Maxxx_ wrote: C:\Folder\Directory\myFile.txt
filename
_Maxxx_ wrote: myFile.txt
filename
_Maxxx_ wrote: C:\Folder\Directory
path
The first two are basically the same thing: both of them let you find a file. One is relative and one is absolute but in most cases you don't care about that. I/O methods will accept either and do the right thing.
If you do care then I'd call the first either filePath or absoluteFilename.
|
|
|
|
|
BobJanova wrote: he first two are basically the same thing
Nonsense
BobJanova wrote: I/O methods will accept either and do the right thing
Lordy lord, what sort of systems are you working on?
|
|
|
|
|
You forgot relative path, for example: ./bin/debug
Marc
|
|
|
|
|
_Maxxx_ wrote: And what about just the name of the folder the file is in?
They aren't folders they are directories. It should still be called FileManager, not Windows' Explorer.
A pox upon whoever made those UI decision.
|
|
|
|
|
Absolutely. Directories are EXACTLY right, as the directory is jsut a collection of pointers to the files within - whereas the folder metaphor implies the physical existence of the files within the folder, which is drivel and rot.
If anything, a disk drive should be a folder, containing directories of files.
But we are victims of the dumbing down of It and, in most cases, it doesn't matter to the user who (lets be honest) call their monitor their computer and the computer their hard drive!
|
|
|
|
|
Exactly! Also More Like An Index Or Catalog. A Document May have links From Many Directories. Try That With Folders!!
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
In my code, filename means just the filename (and extension); pathname means the entire path including filename. The path is just the path.
|
|
|
|
|
You call them all a path. Then you have methods to tell you which bits they include. Look at the dot net System.IO.Path namespace.
If you can work the word 'Rooted' in there somewhere you are doing really well.
|
|
|
|
|
pfn - i.e. path file name
fn - file name
path
Examples from function/method declarations:
std::string slurp(const std::string aPfn);
void A::B::startApp(const char* app_fn);
void Filter(std::string a_localAppPfn, std::string a_peerAppPfn,
|
|
|
|
|
Explorer leaks memory like a sieve. Sieves don't leak memory, you say? Like it suffers from Alzeihmers then. Whatever.
Anyway it started out being slow and getting slower by the day. Long story short, it seems to use a few additonal megs every time I browse a folder, and god knows what else that makes it crawl.
I suspected a faulty shell extension but disabling every damn thing makes no difference. I don't install anything beyond the bare minimum dev tools anyway, nothing exotic.
Wasted a couple of days wrestling with the POS when it grinds to a halt and trying to fix it.
I thought Win7 was pretty stable?
Looks like an OS reinstall for me, and we all know how painful it is to get everything back after that.
As MM would say, faarrrkkkk!
|
|
|
|
|
Upgrade to 8.1!!! 
It's awesome, really.
|
|
|
|
|
Not convinced yet,
One of my programs that runs fine on every other windows frequently crashed on 8.1 (not on 8 tho only on 8.1).
And I have no freaking clue why.
Something to do with the wow64.dll but that's all I'v been able to find out (but only been debugging on it for like 4 hours yet so...)
Going to be fun tomorrow when I get to do some more debugging on that problem.
|
|
|
|
|
Joking aside, I do run 8.1 too.
It isn't that bad, my only gripe is that it doesn't sleep by itself
|
|
|
|
|
S u n s h i n e wrote: Explorer leaks memory like a sieve.
Maybe on your machine but not on mine. Win7 x64 SP1.
Perhaps your machine has caught a nasty little virus?
|
|
|
|
|
No such luck, a virus would have been easier to get rid of. The thing is isolated from the outside world so that was unlikely in the first place.
|
|
|
|
|
Well, you've got something on that machine that is screwing with Explorer. It's not what happens to Explorer when installed "out of the box".
Do you have a crappy anti-virus installed? How about some integrated Zip utility? See the picture here?
In any case, if that's what you're seeing and you don't have any clue what's causing it, your best bet is to flatten the machine and rebuild. Install one thing at a time and test Explorer before installing the next.
|
|
|
|
|
Yawn.
Another user who blames Microsoft before even understanding what's happening. Bring back my jump-to-conclusions-map when you're done with it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
It is most likely an Explorer Extension which is leaking.
Get the SysInternals autoruns utility and disable all but the extensions you trust.
|
|
|
|
|
Our support dept often gets very vague emails about 'something' being broken, without much details and we want to implement something to improve this and make it better / easier for developers to track down and fix issues.
Any suggestions for a system / procedure / form that can be used by users to report errors in software? Not so much a bugtracker, we have internal software for that, but something that can be used to help us get better and more complete issue reports from the users...
|
|
|
|
|
We use JIRA at the moment. Does the job.
|
|
|
|
|
Write your own.
Every bought in system I've worked with has been flawed, some seriously.
When you write your own you can force users or those answering the call to take the information you actually need. The users rarely tell you what you need to know unless someone draws it out of them. Too often those employed to take that info are crap at it.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
Good idea. I guess a standard Issue / Error Report Form will be a good start.
|
|
|
|
|
I'm sorry but your post is too vague
Half serious 
You mean some kind of error reporting mechanism that you can build into an application?
|
|
|
|
|
Yup, something like that To get more info on the issue being reported.
|
|
|
|
|
Education.
No matter what you do in terms of procedures, users will spend as little time n it as they can - they are busy people who don't realise what you need to know. So teach them why you need to know, to try and encourage them to help you to help them!
Well, a man can dream, anyway... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
