|
Very interesting.
Because of your post, I started searching for the windows explorer command-line options to see what /n and /e meant.
Those are very difficult to find. There is no : c:\> explorer /?
Only thing I could find was: https://superuser.com/questions/21394/explorer-command-line-switches[^]
Do you know of a way to get the available options?
modified 25-Oct-23 11:29am.
|
|
|
|
|
notepad.exe explorer.exe
or better yet, String Dump feature of sys intern Process Explorer.
start digging…
|
|
|
|
|
Start / Run / "."
[win+R] [Period] [Enter]
|
|
|
|
|
Someone else mentioned that.
However, if your admins set your (env variable) HOMESHARE then when you do that you will be taken to that network location \\network\username\whatever-Admin-Created\
I wanted it to load directly to:
c:\users\<my-username> the local user directory.
However, if your admin has set the HOMESHARE, then even when I follow your instructions and use:
[win+R][Period][Enter]
or
[win+R][%userprofile%][Enter]
Then it takes me to : \\network\username\whatever-Admin-Created\
Only when I do c:\> explorer %userprofile% does it take me to the local user directory.
That's why I was so happy to finally "hack" it.
|
|
|
|
|
Good to know, thanks.. It's interesting.. does explorer.exe really use a network share as the current-working-directory? That seems.. scary, to me.
Maybe explains why my work laptop hangs, all the dang time.
|
|
|
|
|
raddevus wrote: At work they have Windows Explorer set to automatically traverse to a place that I rarely, if ever, need to access. Why?!? It's because most business users don't care about File Explorer taking a few seconds to open, but they do care that if they break their laptop they may lose stuff, so they want it stored on the network so it's safe and backed up etc, but they don't want to actually have to remember to do anything. So it's easiest if group policy or whatever is set so that every user of every PC gets a default network folder opened unless they do something different.
Then when you, having stored files locally, accidentally pours coffee on your hard drive and loses a month's work, IT can just shrug and say "Your own fault..."!
|
|
|
|
|
Not to forgo the coolness of this, but I have an app that uses Tabs (for years), and always remembers my locations (I have about 10+ of them). So yeah, whenever I open it, it picks up where last left off.
Windows Explorer is, to put it simply, pathetic.
|
|
|
|
|
I don't know if this was Quote: Life-Changing Shortcut
I added a desktop icon and made a shortcut to here C:\Users\Dwight\AppData\Local\Temp
So I can delete all the files VS 2019 piles up when I am playing (developing)
NOW if I was brave I would write a Batch File to delete these files TOO scared I would delete something I should not delete
|
|
|
|
|
Very interesting. You can use %temp% to get the same directory.
For example, a user on win10 (probably win11 too)should be able to:
1. go to file explorer
2. type %temp% <ENTER>
and it will take her to the windows temp directory while supplying the proper user-name:
c:\users\<user-name>\AppData\Local\Temp
I did just that and was blown away to discover that my work computer has: 12.9GB of temp files in there!!
|
|
|
|
|
Quote: Maybe because this one doesn't have to hit the network since it is going directly to a specific path???
I think you right on that. I had a toolbar that was taking 50+ seconds to open. I was blaming it on the security software, but it turns out I had a short cut to a decommissioned server in the toolbar. I deleted the bad shortcut and now it pops!
|
|
|
|
|
What AI comes up with this? Granted, 90% of the time it works great.
It's the 10% that makes me shake my head in wonder.
using ceTe.DynamicPDF.PageElements.BarCoding; Really? What possible code in my simple class could lead VS to believe that I need this obscure namespace???
|
|
|
|
|
It's just getting you ready for the day when we all will have bar codes on our forehead.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
You don't already? You must not be one of the cool kids.
Mine's a little bit retro. U.S. POSTNET done with two sizes of staples.
Software Zen: delete this;
|
|
|
|
|
You were probably talking about PDF libraries with a colleague in microphone range of your phone.
|
|
|
|
|
|
Well ... Fun idea, but where is the real gain?
The real cost of your silver camera was in the lenses, not in the body. For all major brands, there are adapters for silver age lenses to fit on a digital body.
Besides, when I did that, to use my 20-40+ year old lenses, I learned two lessons: Modern lens designs (and camera bodies!) weigh half as much as the old ones, or even less. Second: Modern lenses have way better antireflex coating than silver age lenses.
The only lens I regularly use with an adapter is not from the silver age, but a four thirds lens with a micro four thirds adapter - a macro lens with two f-stops more than the zoom lenses, of high quality and with modern lens coating.
|
|
|
|
|
Another problem is that a MFT sensor is smaller than full-frame format (usual in traditional 35 mm camera's), so the image will be cropped and the lenses will not be used to their full potential.
|
|
|
|
|
Just started reading this (just released) book, The C# Type System (no starch press)[^] and the first chapter is kind of blowing my mind.
Step 1
Author starts out with the following example and says,
"You must use better named variables so dev users know what they mean."
Displacement(double t, double v, double s)
{
var x = v * s * Math.Cos(t);
var y = v * s * Math.Sin(t) - 0.5 * 9.81 * Math.Pow(s, 2);
return (x, y);
} Yes, that makes sense.
Step 2
Then he says,
"Oh, you can add meaning with this new idea of named arguments so users don't have to remember order that they should be passed in."
var result = Displacement(angle: .523, speed: 65, elapsedTime: 4); Ok, yes, that is good advice with the modern capabilities.
Step 3 May Blow Your Mind
He mentions that the code is still confusing because all three arguments are the same primitive type (double) and this leads into...
From the book: Primitive Obsession code smell, which describes any code that has an overreliance on primitive types—that is, those types that are built into the language, such as int, double, and string.
The solution is...
Wrap All the Primitive Types In Structs 🤯🤯🤯🤯🤯
public struct Angle
{
public double Size {get; set;}
}
public struct Speed
{
public double Amount {get; set;}
}
The Paradigm Has Shifted
Now, when the user attempts to call the Displacement method the compiler will know that the argument type is wrong.
Now, there's no way to pass the wrong value into the method, because the compiler will know the type.
Wow, that is a very different paradigm!!
Step 4 Is Immutability
Now, make each struct immutable so that it cannot be altered after construction.
public readonly struct Speed
{
public Speed(double amount)
=> Amount = amount;
public double Amount {get;}
}
I began learning OOP back in 1991 or so and it was much different then with a strong focus on Inheritance. Of course we all learned the pain of inheritance and then the Gang Of Four said,
"prefer composition over inheritance" and that changed a lot of thought on OOP.
Design to a interface and not a implementation.
It is interesting now because there seems to be a switch from Class-focus (heap-based objects) to Struct-focus (stack-based objects) at this current time.
Keep in mind that when Java was created that the designers literally made everything a Class.
I mean, basically C# is that way too with Object at the bottom.
In iOS / SwiftUI they have officially said, "If you create a new thing then create a struct not a class" and they explain why.
What Are Your Thoughts?
Anyways, what do you think about this "Primitive Obsession code smell"?
I see the value in it -- and I'm assuming that the people promoting this are saying do this for specific things in the domain and not all of them.
I cannot image wrapping all primitives in structs and having that many extra types. It feels odd but I can definitely see the value / benefit. But it's really odd after all these years.
|
|
|
|
|
I agree that Primitive Obsession is a code smell. It can easily cause bugs when, for example, a plain integer is interpreted as a time duration. Was that in seconds? Milliseconds? Microseconds? There have been articles about the topic on this site. Here's one of them, but in C++:
Units and measures for C++ 11[^]
Fixing that code smell in a legacy system can be quite a bit of work.
I don't subscribe to the "prefer composition over inheritance" mantra when stated that simply. If B is a type of A , B should derive from A (inheritance). But if B only has an A , but also other behavior that has nothing to do with an A , B should contain an instance of A (composition). The problem with using composition when inheritance is called for is that B ends up cloning most of A 's interface and forwarding to it.
|
|
|
|
|
Greg Utas wrote: It can easily cause bugs when, for example, a plain integer is interpreted as a time duration. Was that in seconds? Milliseconds? Microseconds?
Yes, I agree. That is a very good example of where this struct wrapper would be highly beneficial.
And, I do like the discussion around "using more structs". It is just interesting that in the past, it was "everything is a class" and to see that re-thought.
|
|
|
|
|
In C++, there's no difference between class and a struct , so that comparison with C# is likely to be misleading. In C++, the two keywords often have different semantics by convention, but they're the same to the compiler. If you look at the STL's <chrono> , there's no way to confuse a duration in seconds with one in milliseconds. Their object wrapper precludes it.
|
|
|
|
|
raddevus wrote: Anyways, what do you think about this "Primitive Obsession code smell"? It seems like the book author is someone trying to sound smarter than they are. Just because someone writes a book doesn't make them a genius. Now, I do agree that primitive obsession is bad, but so is struct obsession. A struct won't inherently prevent a coder from mistaking milliseconds for seconds (to borrow from this thread's example). But, what it does do is offer more complexity in an application that may otherwise not be needed.
A lot of these "new" ideas are just rehashed old ideas from JavaScript. I'm dead serious. It's just people looking for something to do rather than go outside. In JavaScript, some folks love to use an object as a parameter for everything. It's the loose and fast version of a struct in C#. It's just as ridiculous to expect an object as a single param in every last routine.
The problem is, the obsession or abuse of any one concept. Average coders take one little thing and run with it because it's the new shiny doodad. Abusing structs is no better. It's just change for change's sake while pretending to be smart. It's about balance.
raddevus wrote: Step 4 Is Immutability To the point of the book, to make each struct read only is a good idea. But, to the point of "prefer composition over inheritance", both Java and C# were literally designed with an OOP paradigm in mind. Move to a functional language if you want to start acting functional.
In regard to immutability, you can use a sealed class in Java and C# as well.
The irony is, all this struct talk is reminding me of C. People always said C sucked because it doesn't support classes. And yet, here we are. People just following the hype train because people looking to change something for no real gain and refuse to go outside. And I say this as a dude who loves functional programming, C# wasn't designed that way.
Jeremy Falcon
modified 25-Sep-23 14:06pm.
|
|
|
|
|
That was a great read. I had many of the same thoughts as I originally read the material.
Jeremy Falcon wrote: The irony is, all this struct talk is reminding me of C. People always said C sucked because it doesn't support classes. And yet, here we are. People just following the hype train
Agree 100%!!
Thanks for being so direct in your post. I wondered if there were others out there who thought the same thing. It's interesting that so many things have been done in the past and then along comes someone who says, "Hey, I got this shiny new thing."
I do see the benefit of this used in small special cases though. But, of course, once a certain set of people read about "Primitive Obsession" they will be obsessed with wrapping all primitives in structs. It's the latest shiny thing, after all.
|
|
|
|
|
Any time man. The longer you're in the industry, the more you see these patterns emerge over and over and over.
Here's another example, in the 90s when MS started pushing XML like crazy. Average coders were all like "omg clear text file formats". But, a decade prior we had SGML that did the same exact thing. SGML also required a DTD. Sure, XML was more strict... but it was nothing new in concept. And all these kiddies came along acting like they cured cancer because binary file formats was baaaaaaaad.
Even made its way to the web. XML this. XML that. But it was nothing new. Fortunately, the web eventually said screw that... it's bloated. Now JSON is the defacto non-official standard in the web world, and we use conventions rather than a DTD.
But the point is, if you used SGML for your typical file format in the 80s... I guarantee you coders would've came along saying how stupid that is.
Jeremy Falcon
modified 25-Sep-23 14:19pm.
|
|
|
|
|
The SGML v XML discussion is a perfect example of it, for sure.
And speaking of JSON -- the detractors for JSON want this new, new, new THING!!
(RUST uses it)
It's called TOML (Tom's Obvious, Minimal Language[^]).
TOML is so amazing!! It's so new. It's never been seen before!!!! Squeeeeee!!
Oh, wait, Windows 3.1 Ini files[^] used that same format. 😅😆🤣🤓
|
|
|
|
|