|
I also find it funny when someone pronouncing Darta calls Oracle Or SQL Server a Daytabase
"It was when I found out I could make mistakes that I knew I was on to something."
-Ornette Coleman
"Philosophy is a study that lets us be unhappy more intelligently."
-Anon.
|
|
|
|
|
People who pronounce it wrong make me go nucular.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
What? I thought Dayta was just another Americanism.
I say Darta, and DartaBayse, and Darta Myning, and Darta Module.
What surprises me is that a Ozzie guy said Darta correctly.
Ozzies more often sound like Americans.
(I'm a Kiwi, by the way)
|
|
|
|
|
mojp wrote: (I'm a Kiwi, by the way)
There's' no need to apologise. Most of us will speak to anybody. 
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Hate to break it to you, but countries with a strong Brittish infuence are far more likely to use "darta" than those with a strong American influence. It's not about being snobby, it's about how trashy your country's accent is/isn't 
|
|
|
|
|
I'm definitely a "Dayta" guy. This use of longer forms of vowels to try and sound clever or proper is getting out of control. I got so mad the other day when I heard a newsreader talking about "Irarq" and, worst of all, "Parkistarn".
Near where I live a local car dealer used to advertise on the radio (maybe still does). He had a Nissan dealiership and he used to end his adverts with the Nissan slogan of the time, "You can with a Nissan." Except he used to say "You caaaaan with a Nissun." He pronounced the 'a' in Nissan very quickly, like in "doberman". He seemed to have completely missed the point that the slogan was supposed to rhyme! 
|
|
|
|
|
Dayta is American.
Pretty much everyone in Australia uses Darta.
Whenever I hear Dayta I think of Star Trek and it sounds very American.
|
|
|
|
|
Hi,
I *suspect* there was no attempt at an upper-class accent, down here in New Zealand and Australia 'Darta' is the usual pronunciation... it often grates on us when we hear Dayta. That having been said, some people down here do use Dayta, and some change between the two randomly. I'd suggest it's more of a cultural or general accent issue rather than someone attempting to sound classier than they are.
|
|
|
|
|
"Darta" is the stuff you store in computer memory.
"Dayta" is the positronic android from Star Trek the next generation.
That aside, language is fluid and ever changing so pronounce things however you like. If it 'grates' you then you are probably one of those OCD programmers who go and change everyone else's code to uppercase and get paid for it.
I find it hilarious that someone here claims to know how Latin is supposed to be pronounced. Hate to break it to you but only the Ancient Romans knew how to pronounce that language, and you can bet the dialects varied.
|
|
|
|
|
I think of dayta as the English pronunciation, Darta as that of the US dialect.
I have a colleague who is a stickler for the grammatically correct treatment of dayta as a plural. It is never "that data" or "this data" but "these data". My grammar is so commonly wrong that I find the correct usage sounds slightly strange!
|
|
|
|
|
I've seen stacks of articles about how to do shell extensions in C# (here[^], here - in MSDN!![^], here[^], and here[^] are just a few from the 1st page of Google). I've always filled them away in that part of my brain that I reserve for interesting things that I may need sometime but not right now.
I just came across this note from Raymond Chen[^] (that links to this post by Jesse Kaplan[^]) that strongly states you should not extend the shell with managed code.
To sum it up briefly. If you write a shell extension in managed code, that will load the CLR into the shell process. And as only one version of the CLR can be loaded in a process that can cause problems with other managed apps using common dialogs, and other managed shell extensions.
Now on one hand I've got 4 articles, one from MSDN telling me how to do it, and on the other hand I've got the CLR program manager and a developer on the Windows shell team telling me not to do it.
1) Is this still true. I vaguely remember reading something about .net 4.0 being able to be loaded in process with CLR 2.0 apps. (Obviously we all know .net 3/3.5 all use the 2.0 CLR), so does this mean that the problem only exists with .net 1.0/1.1 interoperability, so the new message is really, "don't write shell extensions in .net 1.0/1.1".
2) If it is still true, someone really should be telling all these article writers and pushing the message that it is a very bad idea.
3) Come on MS, sort out this. .Net is meant to be the future of windows programming, stop forcing us to use native code anytime we want to interop with your OS.
Simon
|
|
|
|
|
Simon Stevens wrote: I vaguely remember reading something about .net 4.0 being able to be loaded in process with CLR 2.0 apps.
Yes. See: In-Process Side by Side[^] - starting with .NET 4.0, a single host (Explorer) will be able to load multiple versions of the CLR, rather than forcing all loaded components to use whatever version loads first. If I understand this correctly, that means you're actually fine writing .NET 2.0/3.0/3.5 shell extensions now, so long as you and your users avoid any 1.1 shell extensions.
Edit:
Daniel Grunwald notes that this will still break any .NET 1.1 apps that load the shell by using the standard open / save dialogs. So, still a bad idea.
Frankly, if you're gonna write a shell extension, you should be reading the excellent tutorials here by Mike Dunn to start off with, followed by acres of related MSDN topics. Neither of which are particularly well-suited for a programmer looking to avoid familiarity with WinAPI...
Last modified: 1hr 10mins after originally posted -- caveat
|
|
|
|
|
It sounds a bad idea to have anything with a dependency on a large library / framework such as .NET to be used as a shell extension anyway.
TBH I sometimes wonder if shell extensions are a bad idea full stop - so many programs install them and slow the explorer down and it can be hard knowing which application is at fault. What I do know is that for me Explorer under XP is barely usable at times, displaying just a white screen covering the monitor for 20 seconds or so periodically. For something so essential that you need to use all the time this is a PITA.
|
|
|
|
|
Dave Parker wrote: TBH I sometimes wonder if shell extensions are a bad idea full stop
Yeah, don't get me wrong, most of the time I hate shell extensions, (I often manually disable them after dumb apps install them without asking) but I have a few I couldn't live without.
I just think it's a bit bad that there's all these articles out their describing something with no mention of the fact that it's strongly advised against by probably the two most important and knowledgeable people in the field.
Simon
|
|
|
|
|
Dave Parker wrote: shell extensions are a bad idea full stop
Yes.
|
|
|
|
|
If you'd change the message to "don't write shell extensions in .net 1.0/1.1", then some cretin will come along and do it anyway, and then all those wonderful .NET 2+ shell extensions could randomly break even though they were "within the rules"
|
|
|
|
|
The 4.0 CLR can be loaded in parallel with .NET 2.0, but not with .NET 1.0/1.1.
AFAIK if you write a shell extension in managed code using the .NET 4.0 runtime, all .NET 1.x apps that use open file dialogs will break.
|
|
|
|
|
People need to be told.
We must spread the word.
The truth must be known.
I think I feel an article coming on.
Either that or I'm just going to rant to my wife when I get home and she's just going to say yes dear, and totally ignore me and I'm going to huff around moaning about how the whole development community is made up of idiots who just copy and paste code from the internet without thinking about the consequences (except you guys of course) for a bit before totally forgetting about it all.
sigh
Simon
|
|
|
|
|
The last time I heard about this, writing shell extensions with managed code was still considered not supported by Windows Shell team, even with .NET 4.0
Simon Stevens wrote: Come on MS, sort out this. .Net is meant to be the future of windows programming, stop forcing us to use native code anytime we want to interop with your OS.
Do you still live in 2003?
That was the position at the time of Longhorn Alpha project, when the direction was to move all Windows programming to CLR and deprecate Win32 but it has been abandoned in the meantime.
|
|
|
|
|
I remember the .NET enthusiasts were shocked to see most of what Windows 7 had to offer was in COM, and to use some of the new features the only was was to write native code. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: I remember the .NET enthusiasts were shocked to see most of what Windows 7 had to offer was in COM, and to use some of the new features the only was was to write native code. Big Grin
To be fair, they've released some horribly verbose wrappers for stuff like the taskbar API... 
|
|
|
|
|
Sssssshh! I should have seen you here around.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
|
That is a coincidence.
Some good news there from the sound of it - Explicit support for this kind of thing.
I think I still lean towards what Ray M_ is saying in that thread though, just because you can, doesn't mean it's a great idea. CLR loading times, (especially if we're now talking about potentially multiple versions) isn't going to be fantastic. I think my gut says consider doing it native first, unless some decent testing showed it to be up to speed performance wise.
Anyway,
Thanks for the link. Some good info.
Simon
|
|
|
|
|
You are welcome.
Keep in mind that if you need a very simple menu e.g. without submenus and dynamic text you can achieve it with registry settings. So before you start coding native solution first decide how complex menu you need. If you need it at all
Simon Stevens wrote: I think my gut says consider doing it native first, unless some decent testing showed it to be up to speed performance wise.
You will do the whole application in native or call your program from the shell extension?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
