|
Good, Free, AND Windows? Good luck to you my friend.
|
|
|
|
|
Actually, I am about two thirds done with the exact type of software you are looking for.
My desktop document management system currently stores WORD (doc, docx) documents, PDFs, and TEXT.
I was told by some people in the field that no one would be interested in such a software tool. But here you are.
It probably wouldn't take all that long for me to finish the application.
Let me know if you are interested... 
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
doesn’t windows 7 have tags? I think you can tag any file and search for it that way. It supports multiple tags iirc.
|
|
|
|
|
If nobody didn't suggest it yet, a nice idea you can start from is Johnny.Decimal approach.
|
|
|
|
|
When I started up one of the first things I did was imagine that my company (just me) was huge and tried to come up with systems to suit - it is tough if you outgrow your systems.
On one general drive we have folders for:-
Administration, containing everything administrative including financial,
Asset Management - everything which appears in our Asset Schedule, basically,
Clients - folder for each client with their likes, dislikes, contact details, non project correspondence and so on,
Computing - folders for hardware, software, IT Management systems and so forth
Development - folders for planning, business plans, budgets, etc
Library - one place to store all those useful documents which are timeless
Meetings - records of all in-house meetings
Our People - (forget HR, it is so dehumanising) all about the people who actually do the work
Our Suppliers - every company or person who supplies our inputs
Quality - everything about our quality systems
Production - rules about how we do things, analytics on production, that sort of thing,
Templates - all standard documents and templates
Training - all systems and records to do with Training.
And then we have another drive for each (numbered) project.
Most important - we use links to access files which could be in several places, we never have two copies. Thus there are a links to client projects inside the client folder.
When we started a wiki we kept the same structure.
I try to use the same structure in my Outlook folders.
It works well, but I would love to hear about a better system!
Good luck.
|
|
|
|
|
had an offline layout (install set) for vs2017 that was quite a few months old, figured now that 2019 was out the last 2017 should be stable.
follow the instructions to update the offline layout, all good, downloaded a bunch of stuff but looking in the folder after could see it left all the old versions there too., install dir grew almost twice the size it was before. it's not that I'm short of or really care about space, but I hate dead wood, so figured empty the dir and start fresh.
did that, and what did it download? welcome to fantasy island vs2019. arrrgh ... want stable!
so break out the googlizer, instructions to download the last 2017, found (I hope correct).
3rd round... tick tock tick tock... sigh. (queue cute kitty cat u-tubes while I wait, AGAIN!).
Message Signature
(Click to edit ->)
|
|
|
|
|
We have to take it in turns to rant about VS now? 
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
There there is a queue: take a ticket from the machine over there, or just wait for your member number to be called.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
btw: steal the wrong persons ticket may result in ... Beetlejuice Head Shrinks scene - YouTube[^]
tired of the cat vids,... queue ticket comment popped this right into my head
Message Signature
(Click to edit ->)
|
|
|
|
|
"Now serving " EXCEPTION: Arithmetic overflow
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
One at a time or all at once -- your complaints will be completely ignored, either way.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I'll pile on instead of starting a new one.
Now I am getting banner adds for VS2019 appearing in VS2017. That is thoroughly annoying.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Is this just me? I am starting to see the "auto" keyword abuse growing to an extraordinary proportions. Reminds me of the "var" type in JavaScript or "void*" in C/C++. The program, where all variables are declared as void*, would be considered atrocious, yet auto seems to be littered like an empty beer cans nowadays.
|
|
|
|
|
I would not call it abuse and it doesn't even remotely resemble void* declarations. With auto the compiler figure out the appropriate type to use and gives you an error if it can't. A void* declaration has no type so it is a completely different thing.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
modified 23-Apr-19 14:02pm.
|
|
|
|
|
Rick York wrote: With auto the compiler knows exactly the appropriate type to use and gives you an error if it can't figure it out.
If it "knows exactly", how can it not "figure it out"? Sounds like a chick/egg scenario to me.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
If it knows exactly what the type should be, it'll substitute the appropriate type. If it doesn't know exactly what the type should be, it knows exactly that it doesn't know what the type should be.
How's that a chicken/egg-scenario? Either the compiler knows the type or it doesn't. That's the beginning of the causality chain. If the compiler doesn't know the type, it throws you an error. That's the end of the causality chain.
|
|
|
|
|
The compiler knows. The developer doesn't (necessarily).
|
|
|
|
|
That's pretty much the point. In most cases, namely when the type doesn't matter as long as it works, the developer doesn't need to know. In edge cases, such as auto i=1 where i is required to be, let's say, an unsigned value somewhere later down the line, the developer can still forego the auto and make it a unsigned int i=1 or at least an auto i=static_cast<unsigned int>1.
An example from my own work: I've been using API functions like GetTickCount quite a lot and instead of looking up the exact return type, a simple auto s=GetTickCount does the job. API functions returning some value are documented as "Returns 0 if the operation succeeded", in that case, a if 0==s is still enough, I don't need to know the type.
|
|
|
|
|
Even "auto i=1" can be made explicit with "auto i=1U".
|
|
|
|
|
It's laziness: same as var in C#. Yes, you need it (in C# you can't do Linq without it, pretty much) but when all you ever see is
var x = 666;
var y = "Hello World";
var z = DoSomething(x, y); It's just the coder* saying "I can't be bothered to think about it - you work it out for yourself" 
* Note that I didn't use "developer" here
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
At first glance var does seem lazy, I use it regularly while working on a large codebase with a lot of 'technical debt'.
I use it quite a lot in my professional code development having been encouraged to do so.
There again I work in an environment where comments are frowned upon, the thinking being that well written code should not have to be documented - a philosophy which I don't agree with.
I think the use of var fits in with this 'no comments' philosophy as it is not explicitly stated what the type of the variable is and you have to figure it out with intellisense or by inspecting the method's return type.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
If your code has a lot of 'technical debt' it is probably not well written code, and thus arguing if well written code should be documented commented or not is irrelevant for that particular case.
---
I agree with a lot of the philosophy you don't like... I have been anti-comment and pro var for a long time.
I believe comments should not say what (names are for that) or how (instructions are for that)... yet, I think comments that explain why and for what are good. At the end the motivation for having less comments is that comments are not checked, and could be forgotten in refactoring, and thus there is a risk that they will be outdated... sure, we can argue dicipline, yet we use strictly typed languages for a reason. Thus, instead we want to express what we would have said in comments in code.
With that siad, I can tell you that using var as an extension of a no-comments philosophy is retrograde. The idea is to make the code express as much as it can (so it is explicit, that is what they mean by well written code, please do not confuse with verbose), so that we do not have things to communicate in comments... from that point of view, var is counterproductive.
Let us be clear, var is not dynamic typing. Yes, names can help with knowing the type※... yet, no, I am not advocating for hungarian notation either. So how can I be anti-comment and pro var if they are at odds?
I belive in the use of var as a way to protect the code from reasons to change. Same goes for auto. And yeah, I use it virtually everywhere. It eases refactoring (If I change the return type, using auto avoids a maintenance ripple of updating types everywhere the code is used), thus increases maintainability.
Addendum: You know what, I do realize it goes both ways, because if I did a poor job and returned something bad, auto will not complain. Although, I would expect it to break where we actually try to use the value.
If the code follows the robustness principle ("Be conservative in what you send, be liberal in what you accept"), we will not be using auto for the return type, instead the return type should be as specific as posible (without breaking encapsulation, if any). On the other hand, we want to assign the return value to a variable, and the return type is probably much more specific than you actually need in client code. In that situation we probably should not care of the particular type... in fact, we can argue that in that situation - if possible - it often makes sense to cast to an base class/interface that expresses what we need from the return type... and yes, you can use auto with a cast, yet, I will not be forcing you or anybody to use auto.
---
※: if I write auto highPriority = is_high_priority(w); the type of highPriority could be anything. However, it is expected that we can do if(highPriority){} or at least somebody did a very bad work at naming (somebody has been writing very bad code). Do not tell me that the names means nothing, names are for the people who read the code. If the name does not give you a clue and you need documentation to know what everything does, that is poorly written code. In fact, there could (and arguebly should) be naming convention that cover this. Yes, I understand that you want to see bool there, it gives people peace of mind. As I said above, I will not be forcing you or anybody to use auto.
So, nah, I'm not trying to convince you to use auto everywhere. I just wanted to give some insight on why one could advocate for zero comments and var everywhere. I felt misrepresented.
|
|
|
|
|
For no particular reason, I've adopted var in the case of your third example, but not the first two. I always use an explicit type for native/built-in types like string or int...but when it comes to classes (assuming your DoSomething() returns a class rather than a native type), I'll use var...especially when I might not even do anything with it other than forward it to somebody else (ie, I might not even need to look at any of its properties or members).
|
|
|
|
|
var in Javascript relates to scope rather than the type of the object.
I think you may be referring to C#
Scope is perhaps the one thing in Javascript that gives me a taste of what hell might be like.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
auto is abused for simple POD types.
When you start using more advanced C++ idioms (templates, lambdas...) , it can be a soul saving tool.
I'd rather be phishing!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
