|
It would require duplicating a lot of code because most of it is compile time computations of the sort that aren't easily passed to another function, even at compile time. That's the other issue with breaking it up. There would need to be a large common preamble to each routine.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
Ah, so for IOT, where memory is a premium, it's better not to. Totally understand. đ
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
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.
|
|
|
|
|
He who only takes a joke as a joke
and sincerity as sincerity
needs to be knocked on the head.
|
|
|
|
|
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.
|
|
|
|
|
I like when they don't allow dots.
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
so you have to spell them out 
|
|
|
|
|
Actually, that's not a bad thing. Yes, we treat it as case-insensitive, but the original concept had lowercase letters in mind. These days, uppercase is used as a crutch because you have a really long username or domain name, or just are an old fart. 
bob@bob.com - Good
bobGoesToTheMarket@bob.com - Bad
P.S. They probably should just lowercase it on the backend and allow for mixed cased input though.
Jeremy Falcon
|
|
|
|
|
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.
ETA: 17.6.3 was released today and it is still broken. A corporate representative posted on 25 May that the issue is fixed and awaiting release.
ETA: 17.7.0 was released today and it is FIXED! At long, long last. It was still broken in releases 17.6.4 and 17.6.5 so this is very welcome news.
ETA: they have released versions 17.7.1, 17.7.2, and 17.7.3 and it wasn't broken on any of them. I have to state that I am very, very surprised but in a good way.
ETA: While 17.7.3 did not break this option, it changed a whole bunch of my settings and it has been very annoying resetting them.
"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 30-Aug-23 17:51pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
