|
A certain U.S. courier company doesn't allow capital letters in the @ part of an E-mail address. 
|
|
|
|
|
Write it low case...   
sorry... too tempting
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Perhaps their software vendor charges them for each letter that requires a lower case conversion? 
|
|
|
|
|
Capital letters are larger than lower case letters so they take up more disk space.
For such a large company with so many customers, that space is adding up!
This started out as a joke, but the thought occurred to me that something like that may actually have been the rationale behind it 
|
|
|
|
|
Sander Rossel wrote: Capital letters are larger than lower case letters so they take up more disk space.
No. Uppercase A-Z has values from 65 to 90, while lowercase a-z has values from 97 to 122.
This refers to ASCII. Uppercase can be encoded in as little as 5 bits (Baudot code) or 6 bits (Univac Fieldata; there are other 6 bit encodings as well).
If space is really at premium, you should go for Morse code. Lots of people never realized that the coding table is sorted by frequency: E, the most common letter (in English), is a single 'di'. T, the second most common letter, is a single 'dah'. The third most common is I, so it is 'di di', #4 is A: 'di dah', #5 is N: 'dah di', #6 is M: 'dah dah', all the way to rarely used special characters, such as colon: 'dah dah dah di di di' or comma: 'dah dah di di dah dah'.
We may argue the frequencies, and for other languages than English they may be significantly off. For special characters, usage may have changed since 1844. Nevertheless, the fundamental principle behind the Morse code is frequency sorting, to reduce the time for transmitting a message to a minimum.
|
|
|
|
|
I think Sander forgot the joke icon. 
|
|
|
|
|
Because I actually mentioned "This started out as a joke, but..." 
|
|
|
|
|
So when you got to the end it was no longer a joke ... 
|
|
|
|
|
I didn't include it myself. Having to explain, or point out explicitly, humor / parody / irony takes the sting/humor out of it.
Also: I didn't succeed in finding any good translation of the 'gruk' (mini-poem) by the Danish author Piet Hein, but my un-poetic translation says
He who takes a joke as nothing but a joke
and sincerity as nothing but sincerely
he actually understands both kinds
rather poorly.
(If anyone knows a better translation, please let me know!)
|
|
|
|
|
Well, you put us all to shame. A dutch speaker translating a Danish poem into (quite good) English.
|
|
|
|
|
Sander Rossel wrote: This started out as a joke, but
If you read my message you could've saved your whole reply.
Now that's a lot of bits! 
|
|
|
|
|
I get it: You don't want anyone to extend on your joke, you want to have the last hand on it.
That's OK with me ... But you'll have to formulate a response to this post as well of you insist on having the last word
|
|
|
|
|
Seriously?
sorry, too tempting
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Well, maybe this isn't weird, and it's relating to ASP.Net Webforms so of no relevance to most of you anyway... but even though I've been using ASP.Net webforms for donkey's years, this is something I'd not realised / understood until just now.
I have a form on which some of the fields may be disabled, depending on some rather complex logic. Some of the fields are disabled dependent on one of several statuses of a business object; others are disabled depending on a boolean flag that is available client-side. Some are dependent on both tests.
I was finding that when posting back, ONE of the fields was "losing" it's value, and the underlying database was getting an empty value. (Fortunately auditing at the database level was tracking the changes in values, so in those cases it happened in the live system I was able to restore via the audit trail. I knew it would be useful!) Debugging in VS it was apparent that although both fields were disabled (and had the disabled="disabled" attribute), one was empty right at the start of the page_load event, whilst the other had the value expected. I know that disabled fields aren't posted back as part of the HTTP post, but ASP.Net was "restoring" the value (I understand through ViewState). What I couldn't figure out was why ASP.Net was restoring some disabled fields, but not others.
Eventually I noticed that the one that had the expected value had aspNetDisabled in the CSS class attribute client-side (as well as my own class name). Investigating showed that ASP.Net adds this attribute when the field is set to disabled at the server.
It turns out that my code, which had evolved over years, had one set of "disabling" rules implemented server-side, by setting field.Enabled = false ... but the field that was returning blank, was getting set disabled CLIENT side. It therefore didn't have the aspNetDisabled CSS class.
By moving the client-side logic to disable that field across to the server, the CSS class was being set and ASP.Net was restoring the value from ViewState. (Fairly obviously, just adding the aspNetDisabled classname at the client won't do the trick, as the classname doesn't get posted back).
I know, it's one of those things I should have known, and I know, too, that I should be doing things like enabling fields consistently - either client-side or server-side. My original code did it server-side, but that involved writing a line of code for each control. The later additions did it client-side because there were quite a few controls involved, and it was much simpler to just add a CSS class to each one, then use JQuery to disable ALL fields with that CSS class.
|
|
|
|
|
Quote: A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.
This isn't one of those times.
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 should add it as a tip
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
I can not believe how badly they have screwed the pooch on this. I've posted about this before and submitted bug reports and and they have done it yet again. With the 17.4.4 update (I think it was) Visual Studio's batch build option lost the ability to remember which of your build targets you want to build. They then fixed it a release or two later. With the 17.5.0 update it was broke again and fixed again at the next release. Yesterday they released 17.6.0 and this is broken again. 
For me, this is a major pain in the backside. I have one solution with 24 projects, another with 40, and several more with 10. Now I have to waste a considerable amount of time selecting the desired build targets whenever I load one of those or I build them all and that wastes even more time.
I am so infuriated right now that I think I will wait until tomorrow to update my bug report. It won't matter very much because this is an issue raised by quite a number of people. One guy remarked that he gave up on it and has resorted to batch files. I am dang nearly at that point myself. 
Actually, what I should be doing is waiting until I see what new and annoying bugs there are with each new release before I do any updates. I certainly will in the future.
"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?"
|
|
|
|
|
|
But hey, the icons are shiny!
|
|
|
|
|
the shine so overwhelming you cannot see the issues anymore
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
I do not install the 17.{x}.0 updates.
Waiting for 17.{x}.4 or .5 updates brings less anger.
|
|
|
|
|
I have a little IoT audio development board - an AI Thinker ESP32 Audio Kit Version 2.2 rev 2957. The thing is supposed to able to be developed into an Alexa type device.
The problem with it is the documentation is maybe the worst I've ever seen. It claimed that the audio chip was an ES8388. It's an AC101, which isn't even similar.
Worse, there are at least 3 different versions of "Version 2.2" with different pinouts, none of which are specifically documented, requiring you to piece together snatches of old documentation, messageboard responses, and just random detritus from google and wave a dead chicken over the whole thing and maybe it will work.
I've been working on it all day and am not at the point where it produces sound yet. I can turn an LED off and on.
Would not recommend to a friend. Skip AI-Thinker and an get an Espressif LyraT board instead. Meh.
Edit: I got mine making sound finally but who knows how many boards this works for.
To err is human. Fortune favors the monsters.
modified 3-Apr-23 4:47am.
|
|
|
|
|
Quote: Possibly the hottest mess I've seen in some time
Word for word what I thought when I met my wife
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
