 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Maybe you will admit that MS doesn't *always* make their programs perfect?
Never said they did. The things I say about MS is that they generally do a
better job of usability than FOSS manages (which isn't surprising,
considering), and I wonder why people complain when MS is greedy. :-) Oh,
and that there's often a lot of functionality that most people don't know
how to use that's there but people lament it not being there.
Basically, I argue against uninformed FUD about Microsoft just like others
argue against uninformed FUD about Apple or Linux or anything else. Not
because I especially like MS, but because I'm familiar with the software and
I dislike uninformed FUD. Often, it's when MS implements something as a
feature that people don't like, and they call it a bug, I point out why it
can be considered a feature given MS's market.
But they often have various bugs in their stuff, sure. And new versions
often are less usable (for me) than older stuff. Like, their Vista version
of media center is a PITA compared to the XP version.
Heck, I use firefox and thunderbird because the MS functionality for those
sucks so bad, buggy and unsafe. :-) They took over from Sendmail and
Netscape Navigator long ago as being the security bug poster child.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> later if needed without having to go back to the original Excel file,
> update, then copy & paste again.
I try to avoid having my tax returns change once I've filed them. :-)
Yeah, there's various paste stuff like that - keep old/new formatting, and
link/copy data. I think in 2003 it shows up after you do the paste, on the
lightning bolt. (Which also disappears once you scroll or move too far or
something, which was annoying.)
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> One would think that it would be a piece of cake... but no: You can insert the
> whole smash as a new table; you can insert the whole smash into the existing
> cells using the source format (or what Word makes of it); you can insert the
> whole smash using the destination formatting - but then Word pastes it all in a
> single cell (duh! That's what I call BS).
Yeah, that was pretty amusing.
> Why the Holy Moly doesn't MS seem to consider this a frequent enough use case to
> make it possible somehow? You get all the fancy stuff in the dropdown list you
> can pop up after inserting, but *this* one is not among them.
Well, in 2003, just put the cursor right after the headers of the table you
want, and hit "paste", and it'll paste the data from excel, then (after
thinking a bit) change the format to match the table you just appended to.
It just didn't work for me until I did the big paste in two steps. Then it
was trivial.
Just for your future information.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Basically, I argue against uninformed FUD about Microsoft just like others
> argue against uninformed FUD about Apple or Linux or anything else.
But your level of defense is often of the sort: "What do you mean you
can't create symbolic links in Windows? Of course you can. You write this
asm code which calls this undocumented hidden system function through
a third-party API and there you have it: A symbolic link in Windows."
Especially when the comparison is "in standard unix, ln -s src target".
(Yes, I am exaggerating above. It's on purpose. However, I am trying
to make a point.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> (Yes, I am exaggerating above. It's on purpose. However, I am trying
> to make a point.)
Agreed. If someone said "Windows doesn't support making symlinks from the
command line", I might agree (if it were true, which it isn't).
But understand that the designs behind Windows and Unix are different.
Windows does things thru APIs. Unix does things thru data formats.
For example, before BSD, directories were plain old files. "ls" would open
and parse the data in the directory. "mkdir" would actually create the
directory file then write the records for "." and ".." to it - the system
call actually invoked fork() and exec() to run /bin/mkdir.
Windows doesn't do things that way. It uses APIs and COM objects as its
normal functional mechanism. People use languages where it's hard to invoke
COM objects and then complain they can't get to that functionality (or, more
specifically, that the functionality doesn't exist). It's kind of annoying,
because it's the kind of thing that makes for bad software under Windows.
It's a kind of interesting trade-off, engineering-wise. The same sort of
trade-off between using a database vs the file system, or using binary vs
text formats for data, or etc.
Also, there are ways to do things in Windows (like use the registry) and
ways to do things in Unix (like put dot files in the home directory). When
people complain that Windows does a poor job of defining the home directory,
I don't think it's unreasonable to say "you're not supposed to use the home
directory, so it's not trivial to get at that information."
You're not supposed to use symlinks in Windows. That's why there's no
trivial manual way of doing things. There are better mechanisms for
achieving that end. Hence, complaining it's not as easy to use symlinks
under Windows is like complaining there's no easy way to do COM-like
operations under Unix. That just isn't how you do things in Unix.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
> You're not supposed to use symlinks in Windows. That's why there's no
> trivial manual way of doing things. There are better mechanisms for
> achieving that end. Hence, complaining it's not as easy to use symlinks
> under Windows is like complaining there's no easy way to do COM-like
> operations under Unix. That just isn't how you do things in Unix.
>
I don't want to turn this to flamewar, but what is a better mechanism to
get same data readable from two different directories with the same
filename? Should the data location be written to registry and checked by
there before reading?
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> I don't want to turn this to flamewar, but what is a better mechanism to
> get same data readable from two different directories with the same
> filename?
Don't do that. :-)
> Should the data location be written to registry and checked by
> there before reading?
Exactly. Code the indirection into your program instead of littering the
file system with it. In other words, store the name of the file in two
places, rather than making it look like there's two files. Bump the
indirection up a level - indirect to find the file name, instead of
indirecting to find the data.
Or use a "shortcut", which gets automatically updated when you move the
"real" file somewhere else, even if it's someone moving a file on a network
share.
Sure, occasionally it's more of a PITA (especially in complex development
environments where the tools aren't necessarily sufficiently configurable),
but it tends to keep things cleaner in the long run, especially when you
realize that the Windows file systems are a forest, including trees not even
on your machine, for example.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
> Exactly. Code the indirection into your program instead of littering the
> file system with it. In other words, store the name of the file in two
> places, rather than making it look like there's two files. Bump the
> indirection up a level - indirect to find the file name, instead of
> indirecting to find the data.
And if two humans instead of two programs should read the data? :)
> Or use a "shortcut", which gets automatically updated when you move the
> "real" file somewhere else, even if it's someone moving a file on a
> network share.
Shortcut doesn't count, since it's always named .lnk ie. the file name
can't be same.
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> And if two humans instead of two programs should read the data? :)
There's no reason that putting the file name in the registry (or an env var
or other config file) makes it less readable?
> Shortcut doesn't count, since it's always named .lnk ie. the file name
> can't be same.
It's not automated, but you can code your program to follow the link if you
want. (Granted, that's not usually the problem symlinks are used to solve,
but it's not an awful solution for something like a playlist or a run queue
(in the POV sense of the word). :-) Think of the startup menu, for example,
or the send-to menu.
--
Darren New, San Diego CA, USA (PST)
My fortune cookie said, "You will soon be
unable to read this, even at arm's length."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Eero Ahonen wrote:
>> And if two humans instead of two programs should read the data? :)
>
> There's no reason that putting the file name in the registry
Actually there is. For a humanbeing, especially Bart the Basic-user,
registry is a nasty place to crawl for that kind of information.
>(or an env var
Yes, that could do it.
>or other config file) makes it less readable?
Even nastier than registry being somewhat cryptic for a humanbeing
(granted, it makes some sense while you're browsing it) is mixing that
registry and random config files around the filesystem.
> It's not automated, but you can code your program to follow the link if
> you want.
Actually, that pretty much never is a problem. Usually (at least for me)
missing for symlinks is a problem with software that already exists (and
usually is somewhat stupidly done). I can't use shortcuts with such
software, because the shortcut is never named 'file', but 'file.lnk'
instead. I guess that in Windows-world the best way would be that I
could give those programs the name of the datafile eg. somewhere in
registry (as I asked and you preferred, IIUC), but even getting that to
work the software would need to be changed, which usually is not an option.
> (Granted, that's not usually the problem symlinks are used to
> solve, but it's not an awful solution for something like a playlist or a
> run queue (in the POV sense of the word). :-) Think of the startup
> menu, for example, or the send-to menu.
There's surprisingly many things that are done with symlinks and
problems that are solved with them on *n?x, which leads to that there's
multiple other ways for not needing them in Windows -world, which leads
to the whine how useful they would be (and from time to time, they
would), if they were around as easily as on *n?x.
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
