|
I have had the exact same trackball for years and love it
last year the standard left click started to be unpredictable, often double clicking which wasn't helpful
Luckily I haven't used the two small insert buttons and when I toook it apart I was able swap the two switches that were on the left side and my main left click is now working reliably again
you can buy replacement switches with similar markings but not necessarily from trusted sources I wanted a quick fix and only need the left click button to work reliably
Something to bear in mind if yours ever gives problems
Edit: if anyone wants to do this, I struggled for a while to get it apart as there is a screw in the middle of the bottom hidden under the label, you need to poke a hole in the label just above the "s" in mouse of the phrase "Marble Mouse USB"
modified 10hrs 15mins ago.
|
|
|
|
|
Very cool that you made that replacement.
Thanks for the info
I can't believe how long those things last.
|
|
|
|
|
When is the last time you've seen a doctor?
"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
|
|
|
|
|
Are you suggesting they should have outlasted me, and I need to see a doctor to find out why I'm still alive?
|
|
|
|
|
If they're supposed to outlast you, maybe they will, be afraid, be very afraid!
"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
|
|
|
|
|
dandy72 wrote: mouse
The lifespan of a mouse 🐀 is generally much lesser than that of a human being.
|
|
|
|
|
With this generation, Microsoft went out of its way to prove you right.
|
|
|
|
|
I moved to Logitech, Logi as they are now known. After various models with more or less successful lives under my ham-fisted use I finally opted for their Signature M650 L - note the "L", this mouse comes in two sizes!
It is quiet, precise and has so far lasted 2 1/2 years with no sign of trouble. Wife & daughter have since got the same ones after using mine (Not the L version, they are not ham-fisted).
Your one with the dodgy scroll wheel might have been fixable by a simple air-blast to clean the optical system.
So old that I did my first coding in octal via switches on a DEC PDP 8
|
|
|
|
|
My Classic Intellimouse has a blue LED that started going bad around the 2 year mark. I thought, hey, I'll just put a new LED in it. Well, I did put a new LED in it, but it was ridiculously difficult, the LED was a surface mount 1206 in a very confined recess in the optical IC itself. I used my hot air to destroy the old LED to get it out, then some solder paste and hot air again to put the new LED in. I was very worried that I had overheated the optical IC, but fortunately everything still worked afterword. If I have to do it again though, I will, the Intellimouse is also my favorite mouse, the ergonomics just fit.
|
|
|
|
|
Like you, I am very partial to certain keyboards and rodents. I fell in love with the Microsoft Trackball Optical when it first came out -- it fit my hand perfectly and it worked as it should. As a side benefit, anyone who tried to use my computer could never figure it out, so they left my machine alone.
When Microsoft discontinued them, I bought a half-dozen (I think on eBay) for dirt. They last a very long time -- I think I've only worn out one, so they'll definitely be with me for as long as computers have Type-A USB ports.
I've never been a huge fan of mice. Another nice feature of a trackball is that it takes little desk space since you don't need to move it around.
|
|
|
|
|
You must be very hard on mice. I have a pile of working mice removed from equipment that no longer runs. I hand 'em out to my kids when they destroy one, but even they can't seem to wreck mise as fast as they accumulate. My current mouse is a very ordinary J-Tech Digital vertical mouse I've had since the pandemic. Must have cost me all of $25.
|
|
|
|
|
Yeah, those older ball-less MS Intellimouse weren't bad. But I am rather "mouse tolerant", though I definitely don't like a lot of those fancy gaming mice or those round "eagle claw" ones.
Right now, here at the two computers I am daily using, I have a cheap Logitech M325 on one, and a M185 (from a wireless keyboard/mouse combo) on the other. Both are working just fine for a couple of years at last, and I have a Logitech M325c in my backpack that I take with me when I am visiting clients, so I do have a mouse to use if I run into a laptop with only touchpad (I am on war path with touchpads! ). That one is probably 7-8 years old now and gets bounced around in that bag a lot. With no ill effects. Each one probably wasn't more than $20....
|
|
|
|
|
Hi,
I have written a bit of Code to talk to bit of hardware. All good I now having to document it for the records,
In the past I have worked on embedded and analogue test rigs which can be covered by a flowchart and a listing.
This will not work for a Windows program there is too much going on compared to a PIC or Atmel. Is there a way of creating the asked for without going mad? It can't be too odd as I think there must be other companies who need this...
|
|
|
|
|
Welcome to a reason I don't do desktop and server development anymore.
The truth is I've only ever done flow diagrams for embedded code.
To verify desktop applications, rather than design a flow diagram, I design a test matrix. My functional requirements basically dictate the tests.
If you really must diagram your software's behavior, you could use UML, but it won't make things easier, just more comprehensible because anyone with a UML background could understand it.
UML - Behavioral Diagram vs Structural Diagram[^]
Adding: To my mind this is the difference between programming realtime systems and programming non-realtime systems - realtime systems are predictable enough to diagram. As a rough rule of thumb anyway.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Well, there's the high level stuff:
1. What does the hardware do, and why?
2. What are the requirements for the code?
Mid-level stuff:
1. How to integrate the code into a project
2. How to test the code and hardware
Low-level stuff:
1. What are the "public" methods to initialize the code & hardware
2. What are the "public" methods to interact with the hardware -- read/write/reset/diagnostics, etc
3. What is a typical use-case scenario
4. What are the best practices for initialization and shutdown of the code/hardware?
5. What parts of the code are thread-safe, what parts are not? (I would assume none of it is thread safe, but who knows.)
Nano-level stuff:
1. Describe the low-level interface between the code and the hardware.
2. Describe signals and timing (or include the specs on the hardware)
3. Describe specific constraints on the code, like, are there timing dependencies
4. Describe interrupts the code uses when interacting with the hardware
My 2c of some ideas, dredging up memories of documentation I've written in the past for software-hardware stuff
|
|
|
|
|
Can a part of the documentation be written within the code itself, aka, self documenting code. In the form of class headers, function headers, etc.
And the remaining part of documentation as a high level document giving the overall architecture, hardware interfaces, assumptions, limitations, errors, etc.
|
|
|
|
|
Mmm, self documenting code, sounds good until you have to figure out how and why!
|
|
|
|
|
"military intelligence" is known as perfect example of oxymoron
allow me to add
"self documented code " into the growing list
corollary:
when "open source code " is NOT documented at all - period
is it still
"open source code " ?
|
|
|
|
|
Doxygen homepage[^]
It's something you have to do as you write but when done it's a flexible doc system.
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
FYI, DoxyPress[^] supports the same features as doxygen but in a far more reliable implementation and fewer limitations.
Software Zen: delete this;
|
|
|
|
|
Thanks for the heads up.
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
You're welcome.
We have a large code base that's a mix of C++ and C# that build into an application and several Windows services. We found that doxygen only handled single executables (one program or DLL). Its C# support wasn't great.
While DoxyPress isn't perfect, it does the job well enough that we include generating source documentation as part of our automated build process.
Software Zen: delete this;
|
|
|
|
|
I downloaded and ran it against a project that I am working on, with minimal settings.
I'll have to RTFM and find out how to fine tune, but all in all it looks pretty nice.
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
My experience with Doxygen (my own direct use and how I have seen numerous co-workers use it) is that it is fine for the bottom level documentation. The reader will know all the details about the third argument to a given method, but without a clue about when, where and why that method is called at all. The protocol, both any line protocol and the protocol of interaction between methods in one module and the interaction between modules.
In principle, you can add information about module and object interaction, line protocol specifications etc. My experience is that developers never get around to it Round Tuit[^]. Documenting the third parameter in a Doxygen comment is easy to do when you are editing the code; the higher level documentation is postponed until the next tuit delivery. (But sending the order has been postponed ... ).
As long as the intermediate levels are documented well, from the top level, the main subsystems and their interactions, and then stepwise down to modules and objects, then the reader might as well dive right into the source code. When you understand the use of some component, you have no need for a Doxygen carbon copy of the details that you will find in the source code anyway. Too often, Doxygen 'documentation' is little more than a rephrasing of method header.
Obviously, this very much depends on how developers use Doxygen. I am referring to what I have observed, not what you in theory can do with Doxygen.
Equally important: This is certainly not Doxygen-specific. Give the same developers another documentation system that they can maintain as part of the code editing, and the result will be very much of the same. You see it everywhere, in almost all software and documentation available on internet: Method headers and parameters are documented; how these are intended to be used is often completely omitted. If there are some traces of it, it is often poorly written. (The best way learn the use of some library, server etc. is to search for some other open source code to see how they are using it!)
So, my advice is: Forget about the source code documentation, at the method header and parameter level (with the exception of APIs exported to users outside your organization). Document it top-down, with focus on component interactions. If there are explicit protocols across a line, describe it, but document the protocol, not the API! E.g. MSCs can be very helpful to understand the component interactions. You can even make MSCs for protocols between modules or objects, even if they are not line protocols.
Document data structures thoroughly, but again: Top down. What kind of information is held in each structure, which components have access to it, which component maintains it. I am so old that I still think of ER as a good data modelling tool; today it is about as non-PC as the riverfall model, but you can have an ER-like approach even if you do not use ER notation. Stick to abstract data types - at this level it doesn't matter if a counter is 16, 32 or 64 bits. It does matter that it is a counter, though!
If it suits the software, state diagrams and/or state tables are great documentation tools. Unfortunately, few young developers have a good grasp on state transitions; it is more like a vague, remote concept in the same class as the OSI 7-layer model .
So how far down should the documentation go? My answer is clear (but lots of people will frown): Write your documentation so that it is independent of programming language. If the system is re-implemented in, say, Fortran or Pascal, all of you documentation should still be valid. It should contain the language independent stuff, all the language independent stuff and nothing but the language independent stuff.
When you need code snippets or declarations to make your point, leave it to the source code itself. Your documentation tells what it should do. How does it can be seen from the code.
There is one big pitfall, though: When you start describing your system as a set of well documented(/defined) protocols, MSCs, a bird's eye on the data structures, state transitions etc., chances are that you will utter a few nasty words about how the system should have been written. You'll discover messy transitions, irregular use of interaction protocols, undisciplined access to data structures, ... There will be a lot of new entries in the ToDo-list! Just make sure to get that tuit order in the mail as soon as possible
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
The real problem is that there is not enough money or time in the budget for documenting and the programmer is usually to lazy to do it.
Definition of a burocrate; Delegate, Take Credit, shift blame.
PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|