|
Browsers are similarly evil.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
It's really not that bad.
I've always refused to commit to Chrome, so I was forced to pick something else when IE was officially declared dead (and more and more pages were now getting broken). I used the original "non-Chromium" version of Edge for maybe a grand total of 45 seconds when it was first introduced years ago.
I'm liking Edge. I can't say which features I use are unique to it since I don't have Chrome installed anywhere so I can't compare, but perhaps first and foremost, I find it does a good job bringing back whatever was opened when you reboot the computer or accidentally close the entire browser instead of just the current tab.
|
|
|
|
|
The thing I like about FF and hate about Chrome is that you can drag a tab to a bookmark. With Chrome you have to hit the bookmark icon then wander through the choices and save. It's a lot easier to just drag it where you want it.
Haven't tried it with edge.
The only thing I don't like about FF is I can't do online banking with my bank, it gives all kinds of errors when I try to log on so am forced to used Edge.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
I can't say I've tried to save a URL as a favorite by dragging. I always use the Add to Favorites button, then pick the correct folder in the resulting popup. Re-organizing existing URLs by drag and drop--that, however, I do all the time and I find it works well enough.
|
|
|
|
|
We have a customer for whom we've done a [great steaming] pile of custom work. A couple of times a year they find a problem with the custom stuff. It always turns into a wretched slog through a Lovecraftian swamp of bubbling ichor (e.g. legacy code) I didn't write but am now required to maintain. Three months ago they reported an issue with one of their features in the new generation of product that didn't happen with the old one. I compared the code between the two and it was identical. I've spent considerable hours debugging through the code for the feature.
It turns out the new code is looking in the wrong place in the registry to see if their custom features are enabled . The old code only worked accidently.
Cue the fireworks a day early, and let the naked happy dance commence!
Software Zen: delete this;
|
|
|
|
|
One of our embedded systems has been around for 15+ years, we had one or two customers in that time have random device crashes. We tried setting things up and using the customers configuration, to no avail, for many months. Data from the clients revealed the crashes occur at many different addresses. Finally, in desperation, I decided to look at stack usage. There were two routines related to little used features out of hundreds (think 70-80K lines of code in assembler) that allocated 4 bytes more stack space than it deallocated. It took thousands of these routine calls before encroaching on runtime variables. Twas a happy day when I found it , and as important, a big learning experience.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
jeron1 wrote: Twas a happy day when I found it , and as important, a big learning experience Same here. I've had other memorable bugs that were excruciating to recreate and diagnose. One was a GDI handle leak that took over a week of run time to show up and crash the application. Another was a piece of embedded code where the TCP/IP code we bought back in 1995 did not re-initialize properly after a network hardware error. Both of these took weeks of debugging to find and reproduce and only a couple of hours to correct.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: Both of these took weeks of debugging to find and reproduce and only a couple of hours to correct. Funny how that is.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Now imagine weeks of debugging and seconds for the actual fix (after the problem was identified and well understood).
|
|
|
|
|
True, it's tough when you are going through it, for me sleepless nights are the usual result!
dandy72 wrote: after the problem was identified and well understood To me there's a certain satisfaction to that, as rough as the road was to get to that point (and maybe learning a thing or two about better implementation, as I did).
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
I get what you say, but the last time such a thing happened to me it was a case of a missing quote in a string that was being built with multiple layers of escaping them. So of course the compiler didn't know any better and was of no help.
There was nothing satisfying about solving that particular problem. Just annoyance at whoever last modified the string in the first place...
|
|
|
|
|
My favorite was a 49-day crash bug caused by a 32-bit timer rollover. Management wanted to know why test did not find this bug.
|
|
|
|
|
I have a similar story about a once-per-49-days issue. Takes a long time to run those experiments, and to be patient enough to not interrupt them for some other test of the system.
|
|
|
|
|
You always find something in the last place you look for it.
|
|
|
|
|
My takeaway is "don't write things in assembly"
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I wouldn't necessarily argue! In this particular product there's a lot of time sensitive code, and over the years it's grown, A LOT.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Hopefully you bill by the hour.
|
|
|
|
|
Unfortunately no , at least in my day job.
Software Zen: delete this;
|
|
|
|
|
Wait, you said the code was identical between the new and old versions of the product.
So how is there a difference that caused it to look in the wrong place?
UNLESS, it was always looking in the wrong place, and changes to the surrounding code put the information into a different place that it was unable to find by accident?
OR, are you saying that the code that just turned the feature on didn't work, and the code of the feature itself was unchanged?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The difference was in a class used throughout the product to access the registry. This component (a Windows service) used that class incorrectly in the old product but still managed to find the values at the appropriate key. When the service was migrated to the new product (which changes the registry key used), its incorrect usage of the registry class caused it to look at the incorrect registry key and not find the required values.
In both cases, the service and the registry class, they looked correct on inspection. It wasn't until I stepped through the service that I discovered it was assuming certain things about the registry class weren't true and never had been. FWIW, I didn't write either of them.
Software Zen: delete this;
|
|
|
|
|
|
Yup .
Software Zen: delete this;
|
|
|
|
|
Maybe I'm being cynical, but this just seems wrong to me.
I've been using the HTML editor library CKeditor since the early days, when it was still known as FCKeditor.
I've stuck with v4 because it does everything we need it to, and it's free so long as you don't use any "premium" add-ons. As far as I can see, v5 has some nice features, but is no longer free unless your entire project is open source. And with no pricing information available, with everything hidden behind a "request a quote" button, you can bet it's not cheap!
Yesterday, every editor instance started displaying a big red warning message, obscuring the content being edited:
Quote: This CKEditor 4.x.x version is not secure.
Consider upgrading to the latest one, 4.24.0-lts.
But is 4.24.0-lts free? No - you have to buy an "extended support model" for your installation.
Sure, there's a new config option[^] you can flip to turn off this check - for now. But that feature wasn't present when we integrated the editor; it has been retrospectively applied to all old versions, and defaulted to "yes, please obscure the editor with a sales pitch on every load".
I don't have a problem with you charging for a new version of your library. Nor with charging for "extended support" on an old version of your library. But actively sabotaging old free versions of your library to try to drive sales of your new version or the "extended support" version? No thank you.
We'll be sticking with the last free version of v4 with the version check disabled, at least until it either stops working or they start sabotaging it even more. Once that happens, we'll be looking to the competition for its replacement.
For those with long memories, this is reminiscent of the Red Gate / .NET Reflector débâcle, where they took a freeware tool and abused its auto-update feature to try to force everyone to upgrade to their new commercial version. Their argument was that continuing to use the free version was like "wanting today's gas at yesterday's prices". They really struggled to understand that it was more like Homer's elephant rides - expecting people to pay today's prices for the gas they already bought yesterday:
Homer: Um, Milhouse saw the elephant twice and rode him once, right?
Louann: Yes, but we paid you four dollars.
Homer: Well, that was under our old price structure. Under our new price structure, your bill comes to a total of $700.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Surely there has to be a suite of VS Code extensions you can use, like Live Server and other things.
There's nothing strictly WYSIWYG though in VS Code to my knowledge. It's all tags.
Oh, this is a web page component?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: Oh, this is a web page component?
Yes.
CKEditor - Wikipedia[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|